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 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!

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 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.)

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?

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.

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.

That being said, it’s very easy to get into Go if you know Python. Especially coming from an opinionated framework like Django. In my experience the people who have the hardest time getting into go are Java/C# developers who don’t appreciate the core Go focus on simplicity and having absolutely no “magic”. Which is understandable. Getting into Go from Python is different because Python is terrible, so a lot of the opinionated simplicity will most likely make you wish Python had parts of it.

We did some PoCs with Rust to see if it was worth adopting instead of C. We found it wasn’t for us. I mentioned Zig, that is because of the interoperability with C, it’s not something we plan on fully adopting any time soon.

As far as “future proofing” goes, does it really matter? If you’ve been a developer for years you’ll easily be capable of picking up Go and Rust. Of the two I personally found Go a little more challenging to be effective with. It’s easier to get into, but getting concurrency right (not being a memory hog) wasn’t trivial for us in the beginning. You should also look at your local job market. I think PHP would be the best fit for a “mercenary” in my city. By comparison I don’t think there has been a single Rust job posting for a couple of years.

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)?

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. :)

I'd recommend to maybe start with something fun, like doing some game development maybe with wasm...

Edit: I realize it’s an example, just babbling here

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.

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.

likewise for embedded and backend Rust and Kotlin are objectively better languages and communities than Go

From Go I only saw a promotion in Google ? now is finally abandoned?