jhillyerd

Location: Redmond, WA

Remote: Yes

Willing to relocate: No

Technologies: Primarily Go; also have experience with Rust, Python, Java, JavaScript, Elm, Nix

LinkedIn: https://www.linkedin.com/in/jhillyerd/

CV: Upon request

Email: james at hillyerd dot com

My recent experience is in back-end development, but I am a generalist software engineer. I love working with platform technologies; Linux, containers, automation, orchestration (nomad & k8s), CI/CD, NixOS, etc. At Google I worked on a distributed application that handled a million requests per second, but I've also worked at startups with no customers.

I think this is true for Nix in the deployment/ops space, where debugging a broken build can be very frustrating. Language improvements are going to be less useful for app developers, the Flake learning curve is not going to get better with a type system.

Perhaps something like heroku buildpaks (https://github.com/railwayapp/nixpacks ?) would help devs get on the Nix train.

I've started running Nomad in my homelab, and it is a great piece of software. Although I feel like the question is sort of flawed, if you want to learn Kubernetes, you are going to need to run Kubernetes - or one of the downsized versions of it.

If you want to learn about containers, distributed workloads, etc, then Nomad is a great option that is easy to learn/adopt piecemeal.

If you end up not liking (or not wanting to learn) k8s, check out Hashicorp's Nomad. I set it up recently, it's great for a homelab, and a bit more flexible than k8s because it can also run raw executables and VMs.

Yes, please. The first couple paragraphs of this PR I thought I was reading about Riot Games renaming themselves.

Not true, Sonos works in a mesh, so all Sonos devices need to talk to each other, and to the controller app on phone or PC.

+1. It's been years since I used Gentoo, but I felt like it broke me, or required some sort of intervention once a month. Arch was much better, more like once every few months. So far Nix has not broken anything for me in a year of use.

If you are alright with running a single piece app that provides webmail, SMTP, POP, and REST, you might be interested in my project: http://www.inbucket.org/

It's really targeted for intranet use though, I wouldn't recommend exposing anything other than the SMTP port to the internet.

I found the headings a bit weird to read, and apparently my brain thought the GIFs were ads, because I didn't notice them at all.

I'd say yes; there are many times I've ssh'd into a server and wanted to do a quick edit where I don't have my vimrc; not going to bother to install it.

Complexity increases when you want one vimrc with many plugins to work on Windows, Linux and OS X, and both in your work and home environments.

I'm not arguing that Amp is the answer. I don't think I'd stick with vim as my daily driver if I couldn't customize it, and have the plugins I do.

Google is also a very good learning opportunity; there is lots of training available to employees, you will be working with very talented people, and will get to see how the planet-scale dogfood is made first hand.

Author/maintainer here. I see someone else posted Inbucket four years ago, but it's changed a lot since then.

Website: https://www.inbucket.org/ GitHub: https://github.com/jhillyerd/inbucket

Inbucket was my first project in Go, and I have been slowly adding to it ever since.

The module spec lets you put the minimum version in it; so the scenario you raise in your second paragraph would not happen. The import paths are just there to allow you to have both v1 and v2 in the same project (ideally during a migration period).

You would have to raise the minimum version in your module spec to get a newer version of the dependency.

Boiler plate in my example would be everything that needs to be written for a class in Java, not specific to sorting: new file, imports, getters, setters etc. compared to a few lines in an existing file for a struct in Go.

I think this article is a great illustration of the things a Java developer will struggle with while they are learning Go. I no longer write Java, and I now view many of these as strengths.

1. Capitalization rules vary by language, I remember struggling with camel cased naming in Java in some scenarios. I also thing the example given is bad, User.user is a poor name in any language.

2. Structs w/ implicit interfaces. I like this feature of Go, and it's never bitten me in the way the author describes. I never liked having to declare them in Java. And there is an easy way to ensure your particular type implements an interface in Go.

3. I prefer not having exceptions, and linters will tell you when you are not checking returned errs. I do wish Go would offer tools to reduce the amount of if err != nil {} blocks, particularly in IO heavy code.

4. Go's build system is very easy to understand compared to something like Makefiles or Maven. I don't consider a few conventions "magic." I have mixed feelings about init(), but I think it's much better than trying to come up with thread-safe alternatives to compile regexp, etc.

5. Naming. Writing unit tests from an outside perspective (package xyz_test) will help you pick better names, and you will run into less conflicts. In Java you see hideous combinations of Abstract, Singleton, Factory, etc. I much prefer Go's concise/pragmatic naming style.

6. I don't do much code generation, can't comment.

7. I do miss ternary sometimes, but I have seen it abused with very long statements in other languages. I would note that "else" has become a code smell in Go, it's more normal to assign a value and then change it.

8. Sorting. I like that not everything needs to be an object in Go. Having to add a few extra lines of code the rare occasion I need to make something sortable is much better than a project full of Java class/getter/setter boiler plate for what should have been a struct.

9. Yes, dependency management is a mess. No argument. Looking forward to dep becoming official.

10. I do sometimes miss generics, but I started writing Java before it had generics so I can live without them :P. I think they can lead to readability problems when overused.

11. append is a bit confusing, but hiding how it works should be considered "magic." linters will help you here.

After using fish for 3 years, I'm finding there is very little reason to have my login shell maintain backwards compatibility with bash.

The only time I run into issues is when a command expects manipulate environment variables via bash syntax.

I think the fish documentation WRT to scripting could be much better, but the language is more elegant than bash or PowerShell IMHO.