> The issue of whether or not to use Go instead of Rust seems inevitable in any organization.
This assumes Go is even evaluated as an option, let alone Rust. There are many programming languages any organisation can pick from. The right choice is usually "the language most programmers are most productive in".
I don't think "let's teach an entire team this novel programming language" is something you'll see in many companies. It makes sense for new companies, startups, and divisions, I suppose. A company with 200 employees is hardly still a startup, though, that's just a regular old company, even if it relies solely on new investors not to go bankrupt.
> The right choice is usually "the language most programmers are most productive in".
As someone who picked the primary BE programming language for a software org in the last year, our considerations were:
1. What's a language that's reasonably easy to hire for
2. What's the language where we feel that the community attracts high quality SWE's
3. What's the language that's easy to teach and easy to pick up, so that if we find a quality SWE who's not experienced, we can still consider them as part of our hiring pool
4. What's the language that's productive, easy to read and easy to maintain so that if we have turnover it's reasonably easy for someone new to pick up where others have left off
For us, Go scored very highly on all of these metrics, and imo it's almost purpose built to avoid the types of problems a software organization can typically run into. That's at the tradeoff of not being the most expressive or conceptually exciting programming language out there.
Imo Rust is at the opposite end of the spectrum. I have a lot of fun programming with Rust on hobby projects, but to be honest it would be hard to recommend it to an organization as a primary programming language unless the problem domain really can benefit from Rust's value prop in terms of performance, safety, and low-level control. Because you're paying a lot for it in terms of steep learning curve, potentially complex and difficult to maintain codebase, and small talent pool.
> Because you're paying a lot for it in terms of steep learning curve
It's a hill at this point and people are calling it Everest.
There are a few incredibly uncommon things that are still difficult (the ones you see "Rust is hard!" blog posts about), but you're most likely never going to hit those corners. Especially if you're writing CRUD web apps with a few threads here and there. That path is boring and vanilla at this point.
Would you say async is uncommon in writing web apps? For instance in interacting with a database or other services?
I think most people would agree async is much more demanding in Rust than other languages.
And I think you can find Rust intuitive in hindsight once you have picked it up, but I don’t understand how you can seriously argue that Rust doesn’t have entire categories of topics that just don’t exist in other languages which make it harder to learn.
You could say you are just going to stay away from the more esoteric bits, but the problem is if just one of your colleagues decides to incorporate them in their code, now everyone has to be able to deal with them.
That’s a risk you don’t have with a language which is designed for simplicity.
This assumes Go is even evaluated as an option, let alone Rust. There are many programming languages any organisation can pick from. The right choice is usually "the language most programmers are most productive in".
I don't think "let's teach an entire team this novel programming language" is something you'll see in many companies. It makes sense for new companies, startups, and divisions, I suppose. A company with 200 employees is hardly still a startup, though, that's just a regular old company, even if it relies solely on new investors not to go bankrupt.