There is no practical need to enforce borrow checking on all debug builds: it suffices, for beginners, to know that a production build would fail. Forbidding any sort of testing until after the borrow checker is wholly satisfied generates pointless frustration. Can Rust really afford to drive beginners away? For Rust not to fizzle and die, it needs thousands to adopt it for each who already has. Saying "I persevered, you could too, given some backbone" is a recipe for failure.
Is it strictly worse to (1) let beginners deal with borrow checking a little later in their process, or for (2) the language to fizzle and die? Dying is still a punishingly likely prospect. Network effects matter. I doubt that failing to achieve mainstream adoption would be good for Rust, for current Rust users, or the world.
Everyone considering a language to learn has plenty of choices. A language rarely gets a second try.
Rust isn't targeting the NodeJS crowd at large. It is targeting the systems programming and C++ crowd. And spoken by someone who still has his C++98 hardcover by Stroustrup on his shelf, the alternatives in that space are not one iota easier. The fact that C++ does not mandate the use of smart pointers and requires external tools like Valgrind to find memory access bugs is the problem, not a compiler that tells you where you're wrong.
Security is a pain, but it's not a bug. If you want easier, go for a garbage-collected language—though they rarely help with multithreading faults.
Rust ain't fizzling. It's exactly where it needs to be, solving the kinds of problems it was designed for. There is no need for any one language to solve any and every kind of problem. Different tools for different tasks.
And, if you imagine Rust has already succeeded, or that its future is assured, you have not been paying attention elsewhere, either. Failure is absolutely the norm for programming languages.
The Linux kernel is actively looking at submissions in a language other than C for the first time in 30 years. https://arstechnica.com/gadgets/2021/03/linus-torvalds-weigh...
It is a primary language source for WebAssembly.
That is already MUCH further than either D or Dart ever got in their respective spheres.
Folks (including many with a lot of money) are noticing that Rust instead of C or C++ means 70% fewer CVEs leading to security breaches. https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
I think there's a place for a lot of players: TypeScript, Python, Go, etc.
Rust however is not just an interesting side step like most languages that cannot point to real, measurable gains. When there are a limited number of languages that can fill a niche (systems, highest performance, limits on memory consumption), one of them has demonstrable improvements in ergonomics, stability, and security, and it has funding from an array of deep pockets, it would be a fool's errand to discount it even if it has a steeper learning curve than Python.
I would challenge this. Adoption rate does not mean longevity. There are many flash-in-the-pan technologies that are here one year and gone a few later.
As a concrete example, the adoption rate of Ruby on Rails was nearly vertical in around 2006. PHP was old, boring, adoption was flat if not declining. ROR looked to become become king of the web. Today ROR is largely a legacy technology, a footnote at best. PHP is still here, though. It will likely outlast node, too, despite being an awful language.
Large-scale adoption is a slow march through the decades, and has a lot more with momentum than anything else. A big reason why these antique languages have such sticking power is that they have a mature and well-established ecosystem. If you want a new language to join them, that is where the focus should be.
To get that miracle, you need both. Sticking at low adoption is the same as fizzling. Peaking but not sticking is fizzling. There are millions of ways to fail, a whole selection laid out for every language to choose from. Most languages pick one, and do. Succeeding takes a lot of good choices, and negligibly few bad ones. Failing to ease adoption where possible is a bad one.
I wouldn't worry at all about what the adoption graph looks like. The only thing that matters is whether the language is worth adopting.
1. The compiler has been speeding up a lot, it’s about as fast as C++ on large projects.
2. The borrow checker makes Rust usable by beginners. Imagine writing complex pointer code without it. In rust, a beginner can do that safely.
3. Rust is picking up a lot of steam. It’s getting adopted in a bunch of different industries. Rest assured, it’s not going to fail at this point.
If you imagine the borrow checker does not drive away a large majority of prospective users, you live in a dream world.
If you imagine the still-slow compiler does not drive away users, you live in a dream world.
Wishful thinking is always a poor substitute for corrective action.
Is Ada really good support for your argument? Ada's heyday was well prior to the ubiquity of the Internet, had no focus on ergonomics, etc. Its initial adoption target was far more niche than Rust aims to be. I agree with you that there is a certain window in which to achieve relevancy, and that probably has much to do with why newer Ada versions haven't really achieved critical mass. On the other hand, Rust is being used in places from desktop software utilities (e.g., ripgrep) to large internal SaaS codebases. The field of potential Rust developers is far richer than I think Ada ever had.
I agree with you; the borrow checker is much of Rust's value proposition, and if one wanted to do without it, then Rust isn't the right tool for their particular needs.
