Rust sucks because it takes several weeks to become proficient in its use.
That's a huge expense for any person or company that wants to use it. It may be worth it long term to switch to Rust, but if you fail in the short term there may be no long term to worry about.
I do not intend this to be advocacy for or against Rust, but your observation is true and also indicative of a profound, self-defeating issue with this industry: Intelligent, educated developers often chose the option that gives the quickest gratification, even if it causes significant long term problems. PHP is an example. So is MongoDB (and indeed many document stores). A lot of shops ended up becoming "Microsoft shops" only because it was easy to install things from the MSDN discs. Etc.
Most projects of significance encompass tens to hundreds of thousands of hours of work. A small cost upfront is usually insignificant.
It really is about tradeoffs. If developers have infinite time and money, I am pretty sure that everyone would ditch those 'ugly' languages. But we are not living in this utopia. There are time and money constraints that developers have little or no control over.
> Most projects of significance encompass tens to hundreds of thousands of hours of work. A small cost upfront is usually insignificant.
Unfortunately, not all those who mandate what stack to use know this
That's the thing though, if spending two or three weeks right now to learn Rust will save you months of technical debt and futzing around with crappy standard libraries and language weaknesses in the future, then the prudent move would be to ditch the weak language in favor of Rust, regardless of its learning curve, since the end result will be a significant net-positive.
I also think this is a copout. Take Java, for instance. It was new and different when it came out in the 90s, but companies all over the map were willing not only to spend weeks learning it, but also months (or years) re-writing all their crap in Java, even though it was a dismal failure in almost every instance (e.g. Java-Netware, Java-WordPerfect, Java-VisualStudio, etc.)
This. There's a really good point on tradeoffs in Rich Hickey's talk on "hammock driven development":
"Most developers use the word 'tradeoff' to describe parts of their software that suck."
If you haven't evaluated the alternatives, it's not a tradeoff. And if you are sacrificing long term maintainability for two weeks of productivity, you most certainly haven't thought it through.
Huh? It takes years before developer starts writing C++ code that does not blow up in production. Even with JavaScript or Go it takes months to start writing reasonable code (as opposed to something that just seems to work). What are you comparing it to?
This probably explains the popularity of interpreted languages.
It doesn't take months to teach oneself JavaScript or Go and actually write code with it. If it did these 2 languages would not be as successful as they are. Rust on the other hand won't compile until the learner respects Rust memory model. These aren't syntax errors or even type errors, these are "ownership errors" which are a whole new level of errors most people don't want to put up with.
Something like Go is much easier and faster to become productive in—but then its ruthlessly constrained design paints it into a corner for some things. (My own experience with it is that Go can be fairly nice for writing applications in, but it’s often quite painful to write libraries in.)
Really, the conclusion of the matter is that Rust isn’t for everyone, and it’s not perfect yet and will take longer to get to a given level of quality than something like Go. (If as much effort was expended on Rust and rustc performance as has been expended on JavaScript performance, whoa, that would be breathtaking.)
The tools used in most other industries change on a time scale of decades, not months. Some of them don't change for centuries.
Pencils, hammers, and frying pans don't become obsolete, while the language/framework/magic thingie of the day is almost guaranteed to do so.
Maybe Rust will take over the world and last as long as C, Lisp, or FORTRAN, but that's certainly not the way to bet.
I would guess the answer is yes. After all the new tool needs to be much better than existing tools to justify weeks of retraining.
In fact, I suspect programmers are willing to put up with a lot more compared to other professionals since we do a lot of our learning in our spare time.
They are probably evaluating: 'So, what do I feel about learning Rust stuff for the next 10 years?'
Weeks? That's nothing. It takes months, if not years, to become proficient in C++, for example.
(I understand that you are talking about the training of the existing employees, but still.)
Also they think knowing to write the code is the same as knowing to code in that language. It's not true at all. It's quick to be able to write C code. Being able to produce something worth being on prod however, takes month.
If I was building applications where performance is key (such as networking, Kernel, OS libraries etc), Rust would be great for me. But currently Go gives me enough speed and is far easier to make progress in (with the time I have available).
Rust has a great community, that was a key take I tool from my time there as a newcomer.
A few weeks seems like a good trade to me for the safety rust provides for a lot of applications.
People claim that they are quickly productive in Golang, one can also be productive in Rust in a similar amount of time. Satisfy the borrow checker with .clone and .copy. The end result will be the same. Using something doesn't mean that you are required to explore the full depth and breadth of it.