I've been spending a fair bit of time learning new programming languages recently, and I'm quite happy to have the progression be Python to Go to Rust. When learning something new, your motivation gets a boost when you can do lots of things and do it fast. From this perspective, it's hard to beat an interpreted language like Python.
Python is the main language at my previous role, and this choice makes sense given how key ML models were to the business model. Having the data science and engineering share the same language helped reduce maintenance and tooling overheads, as well as provide better context in handoffs.
The drawbacks were speed and lack of types. For speed, we had bindings to C++ on the hot path - the need for speed in an auction setting is clear. For types, we gradually introduced type comments with mypy. Why types? It's easy to introduce bugs when refactoring a codebase with limited guard rails; types are like tests that you get for free.
I had the chance to learn a bit of Go just before RC, motivated partly because it's the main language for Bradfield's CS Intensive course. I was pleasantly surprised to find a lot of tooling we used for Python comes built-in in Go (brief discussion here). Go also has first class support for concurrency; the language is a popular choice for servers given the need to support multiple clients simultaneously. The syntax was surprisingly easy to pick up coming from Python.
I wanted to know more about the front end at RC, but curiously got into WebAssembly in the first week. I then found out from Tom how Rust has the best from-scratch support for compiling to WebAssembly. Another reason Rust works better is the smaller runtime - the smallest achievable binary size uncompressed from Go is ~2 MB vs ~2 KB for Rust. I'm not as familiar with the finer details, perhaps a sizeable part of that can be attributed to garbage collection in Go.
In summary, Python for fast prototyping and 'glue code', Go for concurrency and Rust for the low level stuff. Next comes lots and lots of practice.
Content: Disruptive innovation
If you've come across the theory of disruptive innovation, Jill Lepore offers an interesting and persuasive take in the New Yorker.
Love how there's a reference to HBO's Silicon Valley.