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.
1. 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.
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 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 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.
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.)
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 :)
That kinda sold me on Go.
It's basically C if it were repackaged for writing http-aware services.
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.