The first three paragraphs: experienced engineer, knows a few languages, still finds Rust daunting after two years, has tried to and stopped learning multiple times.
All of that for the upside of being able to look under the hood, being forced to think about data first, and the great tooling.
The effort vs. reward here is why most companies will stick to something much simpler and why Rust, for almost any given problem, there is most likely a "better" language for the job, and even where Rust shines, there will remain a more popular language for the job for some time to come.
You really have to smoke whatever quality herb they're smoking to get into it, because the rewards will take a while, if ever.
Have you used Rust Enums? They are absolutely beautiful compared to C’s unions and “I hope I cast this right” behaviors. Uninitialized data is also an impossibility.
I never liked async programming. But after wrangling threads and processes for a 20 years, it’s pretty good in Rust (though underutilized). At least nice to have native language support.
That being said, I still prefer Python for build/test automation. But for shipping code that I want to work, Rust is it.
I’ve even written complex bare metal code from scratch (similar to an OS kernel) in Rust. Much nicer than C!
If you look at the history of languages and impact they made, Rust doesn't really fit into any one.
C was influential because it had very concise grammar which made it fairly easy to adapt to any architecture. C++ on the other hand never really gained as much traction despite its apparent advantages.
Java, being fairly poorly designed in early days (unpredictable GC, needing a class wrapper for main) got huge adoption because it was cross platform and programmers didn't have to manage memory manually.
Javascript won over PHP because of its flexibility, despite of all its shortcomings.
Python won over Ruby and others for scientific computing because of its great standard library, that made development super easy, dependency management (especially with venv) and very easy integration with native code. Even now, for companies, its actually cheaper to spend more on extra infra to run slower python code than pay programmers to write it in a higher performance language.
What does Rust have? Primarily memory safety, and then slightly better code structure compared to C, and cargo package manager. Memory safety doesn't really map onto a real world result. The task of exploiting binaries is EXTREMELY difficult these days with so many layers of protection just to get to the binary over the internet with your structure shellcode, never mind exfiling data. Cargo package manager is fairly good for what it is. Code structure can be clearer to read compared to C (you can get fairly close if you know how to write C macros well).
So overall, its still very niche, and the reference tracking acts as a disadvantage to slow development down. Sure it forces you to think about structure, but the future is looking like that computers are going to do all that thinking for you (or rather apply known memory safe patterns to your code automatically).
Yes, I agree that it will take time. C / C++ / Go will still be there, leaving niche spaces for a difficult to learn / master language that takes longer to compile. It's as if the "most loved" is a "tough love" kind of love.
my impression is that rust already has lots of 3p libs, but they may be in experimental or not actively supported state (someone created something for fun and abandoned). So the question is about well established libraries.
I think it really depends on the context. There are a few things that one should consider when thinking about "how quickly a developer can become proficient in Rust":
1. Exposure into lower level languages. If Rust is your first language with pointers it will be probably harder to grasp than for a C++ programmer. Notice the author mentions he mainly worked with Python, PHP and JavaScript/Typescript.
2. The context of learning. When I was learning Rust I didn't have a lot of free time and I was dealing with burnout and other personal problems, so my story was kind of similar: "used it on and off for a year or two". I would write something one week and leave it for a month or a few months. You don't exactly know how the post author was learning. I was working on a Rust project with a dev that hasn't written a single line of Rust before and they were productive after 2-3 weeks of full time work.
3. When the learning was taking place. Rust now is much easier to learn than it was a few years ago. It doesn't mean that the language changed significantly, cause after async/await I don't think there were any major changes, but it's been gradually improved to make it easier to write Rust code by removing cases where you need to explicitly handle lifetimes and improving error messaging and the ecosystem.
A lot of well known companies (Amazon, Microsoft, Cloudflare, Dropbox, Figma, Discord) are adopting Rust and if what you're saying was true, it wouldn't be the case.
Also, take a look at similar threads about C++. Lots of people would tell you it also takes years to become proficient in C++. I guess C++ has to be a dead language no one uses then.
Your argument reminds me of one about forefoot running vs heel strike. Forefoot running is supposedly the natural way to run and some people are really enthusiastic about it, but you say it's really hard to switch, since you're already used to the heel strike you learned in school - and there are plenty of highly engineered shoes to make it comfortable, anyway. And then you conclude: Forefoot runner are delusional, people will never switch and throw away their fancy shoes.
Rust requires you to think differently quite a bit, so of course "experienced" programmers gonna struggle disproportionately. Going from Java to Python is hardly a fair comparison. Rust is increasingly taught at universities, which means people are not as shaped by their experience and habits as much and grow into Rust's way of thinking.
I don't think that the forefoot running analogy works here. As you put it, forefoot running is the natural way to run. I don't think you can say that about Rust even if Rust is your first programming language.
I do agree that teaching it when people are young will make it easier for them to grasp. I hope that this will turn out a few people who don't consider Rust challenging even after years of programming in Rust.
I recently started programming in Python after not having done it since college. Along the way I've written code in Ruby, PHP, Objective C, Elixir, JavaScript, and I think even some C. I've even spent time learning Rust. I learned Python in half a day. I bet a derivative of Python that forced memory management onto users would be easier to learn than Rust because, generally speaking, in Python there is one good way to do most things. Nice and simple.
The difference is that forefoot running is harder, but _simpler_. You dont even need highly engineering shoes to run using it, especially barefoot. You can run on bare metal.
You should learn Rust if you want to write fast code.
There’s a discussion on lobsters “C++ or Rust?” (https://lobste.rs/s/0akqy7/are_there_any_good_reasons_use_c_...) and the general consensus is that Rust is better except for legacy reasons. I disagree, I believe there are niche cases C++ is better even on new projects with new teams (maximum performance, no care about safety, most on the team don’t care about “functional programming”, something like UI or game dev), but they are niche and the benefit is marginal. Which means Rust has a good chance to become the future.
Even if you end up writing C++, Rust teaches concepts which translate to C++ specifically and writing fast code in general. Including concepts related to the “functional” aspect which will help you write better, safer C++.
Also learn Rust if you want to learn more about low-level abstractions and functional programming, primarily for writing fast code.
However, I still believe you shouldn’t learn and use Rust for writing general-purpose code, unless you care about learning performance. Because languages with garbage collectors (JVM languages) and weaker memory models (Swift) are “fast enough” in most cases. And I’m very skeptical that most people would implement something faster in Rust than they would in Kotlin, TypeScript, OCaml, even C# or Java; because the borrow checker does create overhead. Unless they need to go back and optimize for performance (or they are writing idiomatic code in Rust but not in the other languages; most of the functional paradigms from Rust, like small structures, typed wrappers, polymorphism, composition, even ad-hoc multiple inheritance (extensions or default methods) and pattern-matching can be applied to all the languages mentioned above).
I don't love Rust because of "fast code", I love it because it leaves me less stressed and less frustrated, IOW, happier.
There's so much emphasis on the memory safety of Rust that it overshadows everything else that is awesome about it. Rust (largely) gives me the power of Haskell strong types, but with fantastic tooling and a much much richer library (if you include crates.io).
I find the difficulty of Rust overstated; much of the borrowing challenges can be avoided by cloning/copying wherever required and limiting borrowing to where that approach becomes an actual performance problem. As Python's success proves, developer productivity trumps runtime efficiency.
1. Safe Rust disallows data races at compile time, see for example: https://msrc.microsoft.com/blog/2020/04/the-safety-boat-kube...
2. WASM is getting more and more usage (also on the server side) and Rust is one of the best languages to compile to WASM at the moment
3. If you need to support multiple programming languages with one library it might make sense to write a Rust core and wrappers in other languages
4. Rust has explicit error handling, so it might make sense to write a Rust application in critical applications where you need to be sure you handled as much error conditions as possible
5. Sometimes an application doesn't necessarily need to be ultra fast, but needs to have predictable performance. In some situations Java or Go won't be much slower (or could be even faster) than Rust, but in Rust it might be easier to get lower latency variance.
There is probably more, but I choose Rust for many projects that do not need Rust's speed and I believe this is also the case for many people writing Rust.
All of that for the upside of being able to look under the hood, being forced to think about data first, and the great tooling.
The effort vs. reward here is why most companies will stick to something much simpler and why Rust, for almost any given problem, there is most likely a "better" language for the job, and even where Rust shines, there will remain a more popular language for the job for some time to come.
You really have to smoke whatever quality herb they're smoking to get into it, because the rewards will take a while, if ever.