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.
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.
+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'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.
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.
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.