Has the market spoken? Time to pick up Golang and Rust?
So it's been a decade-long round-trip from IC to management to senior manager back to IC.
And in the time you see some skills develop while others atrophy. And some new skills appear on the market that I'm shallow in.
In this case that could be Golang and Rust. (Lets not talk about how I feel about the Javascript ecosystem)
But, man, it is hard to let go of the cozy warm and lazy blanket Django and the python ecosystem gives us, isn't it?
The irony here is that I'm incredibly productive in the Django stack, but relative to the many jobs out there -- it seems many Rust and Golang positions go unfilled.
So, what is a guy to do? Daddy has to eat, and I am mercenary at heart.
So here we are -- back on the learning curve and ramping up on Golang and Rust.
64 comments
[ 3.1 ms ] story [ 140 ms ] thread1. React is 11 years old. Even "modern" React with hooks and such is more than 5 years old.
2. Express has been the backend server for Node for over a decade and it hasn't had a breaking semver change in 7 or 8 years.
The front end bundler ecosystem has been a hot mess forever though.
Compare this to Android which somehow manages to break its build system ~every few hours~ at least once per year.
The bundler situation wasn't ideal for a few years, but I've been really happy with esbuild lately. It's incredibly fast, has zero dependencies (besides the Golang sys module which is a de facto part of Go's extended standard library), and is much easier to configure than Webpack. I even heard DHH praise esbuild on The Changelog podcast recently, and he's a notable anti-build evangelist.
The situation with React Native back when I was doing RN was horrible. I ended up with 2 major breaking changes to the main router package, and I burned so many weeks of time trying to keep up to date with routing changes. It is super annoying that such a simple thing has so much churn. The solution doesn't have to be perfect, it just has to be good enough, with well documented warts and workarounds, and lots of sample code!
Rust is a beast though, I tried picking it up several times, but lose interest quickly. The language is interesting, but the learning curve is a problem.
I do want to do Rust in production too. I'm dreaming of moving data engineers to a staticly typed language (crazy to transform data with dynamic typing) and Rust with Polars seems like a great match. The learning curve is steep though.
I don't write 'clever' code, just sticking stuff into Postgres/PostGIS/Neo4J/Clickhouse, some basic business logic and math, returning JSON etc.
I have found Rust to be super-productive and a joy to use compared with Go. I don't use the complex parts of Rust; no messing with lifetimes, a little cloning and using Arc<> to share things across threads/tasks.
GitHub Copilot in Jetbrains RustRover is very effective at generating accurate Rust CRUD code, handler methods etc. I don't bother with an ORM because it is so fast to write the SQL queries. Having said that, Copilot sucks at anything even slightly complicated and you take a risk asking it to generate code you can't validate quickly.
The whole of Rust might be a beast, but I have had a very productive couple of years just using the 'boring' bits and it took a week or two for me to be more productive than in Go writing bog-standard web backend code.
am i understanding that correctly? you started learning/writing rust and it took 2 weeks to be MORE productive? if so, i'm just in awe at your ability to pick it up so fast.
I'm an jr dev so it's understandable that it's going to take me a lot longer but damn, i've been at it for over a half a year and I wouldn't say I'm anywhere near more comfortable/productive than my previous languages. Whatever you're doing, keep doing it. much respect.
I was under the impression that everyone wanted a job writing Rust, but had to settle for making React components. Point me to these unfulfilled Go jobs please. :)
Edit: you know, I don't think you're being merely pedantic, as this precise difference is the exact crux of the issue, isn't it?
examples: SRE, devrel, management, front-end/design, support, sales support, ...
Most of these are pretty good Python or Javascript or sh programmers. None of them are good at C, C++, assembly or Rust.
Go has the quality, like Python, of being passable even if you're indifferent.
Go is a "less spicy Java", and Java isn't even spicy.
(Also, I code Rust for a living, and I absolutely love it, but I understand why others might not.)
That kinda sold me on Go.
It's basically C if it were repackaged for writing http-aware services.
Even though I’m already very productive in Rust for typical microservice backend scenarios, none of those jobs are close to my areas of expertise.
So I wonder if Rust jobs go unfulfilled not because of lack of rust developers but because the job market doesn’t match the reasons why some developers learn Rust in the first instance.
Only in the same way that a cook that has spent his career in an Italian restaurant doesn't have expertise in cooking Chinese food. An employer on the hunt isn't going to care about such trivial differences (HR box tickers might, but crypto startups probably don't have that).
Granted, I can understand why you'd be leery about working at such places.
Are you looking for the programming language with the greatest number of available jobs?
Are you looking for employment at a language-fluent organization like FANNG?
Are you trying to prematurely optimize for future relevance?
Are you looking for the highest paid programming roles with niche specialization in a specific language?
Are you trying to develop for a particular platform (iOS/Desktop/Browser/Server)?
From Go I only saw a promotion in Google ? now is finally abandoned?
IEEE puts out an incredible report on this stuff every year: https://spectrum.ieee.org/top-programming-languages-2024
The boring answer based on current demand is that the old languages are still dominant. Of the new languages Rust and Go are indeed at the top, but they’re still ~below C++/C, Java, and C#. OTOH, they are definitely near the top of growing languages, which is probably where your sense of them being “chosen” comes from; if you’re cynically trying to maximize long term career earnings, IMO either would be worth some investment.
The elephant in the room is, as you briefly mentioned, Python and its relation to the AI boom. There’s lots of fantastic shovels being made in other languages (eg llama-cpp), but the huge majority of new libraries are written with python APIs in mind (eg VLLM, Langchain, BentoML, and ofc the classics like PyTorch/Keras, SciKit, and numpy/pandas). Again, speaking cynically, I think there’s a lot of money flying around the python space right now.
Finally, I think it’s worth mentioning my take on the old refrain: languages aren’t really that different so don’t stress about it, but it can be worth it to invest in new paradigms/spaces/application types. It sounds like you’re not a fan of webdev, but instead of hyper focusing on picking a language, maybe consider picking new spaces to explore! I mentioned LLM shovels (aka quantizers, inference platforms) above, but there’s also some other booming spaces such as CRDTs/LocalFirst and spatial computing, to name my two faves.
Best of luck! Exciting time to be a member of the puzzle-solving class :)
likewise for embedded and backend Rust and Kotlin are objectively better languages and communities than Go
For jobs, ecosystem and general productivity my go-to is always Java/C#/Go, if you learn one of those I think you'll be set, so Go in your case. The learning curve for Rust is similar to C++, much steeper.
So that means it's very hard to introduce in a company where the focus is on getting code out there as cheap as possible. Especially when the majority of work is done by contractors which in general aren't hired to learn new stuff, but more to execute work with existing skills.
Personally, once I became proficient enough in Rust my way of programming changed, and this actually became an issue when having to write other languages. Learning to write Rust actually increased my cognitive load when writing other languages, as I am constantly worried about not having my safety net.
My experience as well. The lack of experienced Rust developers on staff, plus the need for build systems that compile to all target architectures, represents a real cost. That often doesn't surpass the benefits. Cheaper overall to just run the same old interpreted Python code, even if it's slower and uses more resources.
I'd recommend to maybe start with something fun, like doing some game development maybe with wasm...
Maybe you have a good problem of your own to solve, but in my experience the most interesting problems are usually those that other people have.
Solving someone else's problem is what a job is.
I meant it should not be a pain to learn a new language just because you are desperately trying to get a job with it. Do something fun, regardless whose problem you are solving and the learning experience will probably be much better.
Edit: I realize it’s an example, just babbling here
But the first followup question is: For each choice, what are your risks if you were to find out you chose wrong?
If you choose Rust, and it turns out to be the wrong choice, how will the customer be impacted?
If you choose Go, and it turns out to be the wrong choice, how will the customer be impacted?
Realistically, there is no such thing as a wrong choice, only different tradeoffs. I assume "wrong" here means wishing you made different tradeoffs later on. But will you feel real consequences if that happens, or just a casual feeling of "I wish I'd have done it differently, but oh well" in passing?
> What limitations do either of them have when scaling?
What, specifically, are you trying to scale? What scale-related problems do your customers have?
Do you even have a product yet? If no, perhaps the best tradeoff you can make right now is the one that compels you to get started instead of worrying about it? Ask yourself: Will you be more apt to actually build it if you choose Go, Rust, or perhaps with another tool entirely? It doesn't matter if X is the unquestionably best choice if you never get around to using it.
You might still want to be mindful of what risk there may be. I expect you can tell me what risks there are if you chose Brainfuck, and I expect you would tell me that is a risk too great. But, without understanding your problem in depth to know what nuance needs to be considered, there is probably no meaningful risk difference between Rust and Go.
Still demand.