If Rust is not to fizzle like Ada (which got overwhelmingly more investment than Rust has had) it needs a radically faster adoption rate. While several traps imperil Rust's wider adoption -- pathetic compile speed is another: consider JIT in the compiler! -- the borrow checker is an important roadblock for beginners.
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.
You really think things will improve by essentially wrapping entire Rust programs in a huge unsafe block?
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.
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.
Your choice to compare Rust to D and Dart reveals all.
If you imagine that Amazon could not rewrite firecracker in a week, you are not paying attention. If you imagine that the Linux kernel has any Rust code in it, you are not paying attention.
Python, JavaScript, Java, C++, C, and Fortran got miracles. Myriad others did not. Miracles are not awarded for merit, but are reliably denied for failure to act to seize them. (C++ very nearly lost its, before 2011.) Rust has not got one. Rust still, just barely conceivably, could find one. Failing to take steps in that direction is a binding choice.
Where was Python in 2002 when it was only 11 years old?
Not every language can piggyback on the first scriptable web browsers or on IBM mainframes.
I see Rust's miracle as industry adoption in cloud infrastructure even though every software engineer in that sphere already has (typically decades of) experience in C and/or C++.
Its miracle is that after all these apps were (re)written, it was not followed by the typical tidal wave (or even a steady stream) of severe CVEs that have always accompanied systems-level languages.
Most folks don't need Rust, will probably never need Rust. That's okay. A huge proportion of developers never need C, C++, or any of the myriad assembly languages.
But folks in that sphere know how fraught the systems-level languages are both from a security perspective and a packaging perspective (where's the cargo equivalent in C++ in 2022?). They are looking at their colleagues and watching the list of CVEs.
Their choices:
• Zig: better than C, simpler than Rust, but very immature, and not as memory safe or thread safe as Rust
• Ada: established, used by DoD, not as memory safe or thread safe as Rust (see: severe CVE causes)
• Go: much shallower learning curve than Rust, but garbage collector makes it unsuitable for systems-level. Much less flexible than Rust.
• Fortran: no intrinsic standard support for Unicode-aware I/O, memory safety is lower than Rust. Fortran is a muscle car with great straight line performance for scientific processing but has always struggled with general app space due to its design.
• Nim: interesting alternative to C, but nowhere near mature or stable enough for general deployment in the real world.
• C: dead simple with plenty of foot guns. In fairness, C taught us where a lot of the foot guns were in programming. 50+ years later, it's obvious from the CVEs that humans need some guardrails.
• C++: More complex than Rust, a back history that preclude solving its worst design issues, and coupled with subtle firearms that blow your whole leg off. No standard packaging or module repositories available. Severe CVEs galore. Has spawned entire swaths of new languages just to avoid using it. (See: Java)
Rust is arguably the first popular language outside the DoD that can reliably take jobs from C++ with tremendously and measurably better reliability without compromise on resource usage.
There's a reason Linus Torvalds and the other core kernel developers never wanted C++ anywhere near the Linux kernel but are cautiously optimistic about and open to Rust development in that space.
It's not about hype; it's about the necessity of reducing the security-related blast radius even at the lowest levels of hardware and the embedded space. Everything above that level is just gravy.
I would NEVER consider writing web server software or cloud functions in C or C++ in 2022. I would consider it irresponsible. I'd write them in Rust in a heartbeat though if performance demanded it. Many others feel the same way.
All together, that's what I see as Rust's miracle.
> If Rust is not to fizzle like Ada [...] it needs a radically faster adoption rate
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.
The number of lines of code in use has to be high, but there is a great deal of COBOL code. Who is coding new COBOL, or PHP? Ruby looked promising, but fizzled. Sticking power is necessary, but not sufficient. Rapid increase is necessary, but not sufficient.
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.
It's not enough to merely be better than the previous languages, but you must be so much better that it outweighs the cost of adopting a new language (which is steep).
It's why we are still on QWERTY despite DVORAK being a tiny bit better. For most typists it doesn't matter, they will never make up the time spent learning DVORAK with the time saved typing DVORAK.
The same with programming languages. Most new programming languages aren't that much better than the old ones. Maybe they fix one or two problems, but at the same time, they're less mature and critically, who knows if they will be around in 20-30 years. C will be around in 30 years, C++ too, PHP will, Java certainly. Rust, honestly, I dunno. Could go either way, and it's not because people aren't adopting it fast enough that I'm hesitating. When Rust has been around longer, I will be more confident that it will stay around, and then I may consider using it.
Absolutely, being better on one or more axes is only table stakes. An essential prerequisite to the miracle, besides, is wide adoption, because without, why would anybody put in the time to get proficient? You have only a short time to get there. With too-slow adoption, you miss the window.
But we are already off in the weeds. Why argue that slow adoption might suffice, instead of doing everything needed to drive up adoption? Would it be so bad to do a thing that might turn out not to have been obviously necessary? Hype only goes so far, and has gone there already.
To me the clearest indication that any language will fizzle is when its boosters insist it doesn't need to do anything not to.
> Everyone was way more confident about the future of Ada, and with better reasons.
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.
Ada had literally billions of dollars in contracts backing it, a detailed specification, multiple industrial-grade implementations, tooling companies betting livelihoods on it, and university engineering programs teaching it. How many of those does Rust have? Any? Ada fizzled.
I have not needed to know of any important programs coded in Rust in general use. Ripgrep does not qualify. Alacritty does not qualify. (Haskell has, anyway, Pandoc and Git-annex.) I guess fragments of Firefox are coded in it. I like that Firefox is less crashy than a decade ago, but I doubt Rust is responsible: I think sandboxing gets that credit.
It is possible that Rust could become important someday, but only if things are done to make it so, most particularly acting not to drive away, for readily fixable reasons, a large majority of people who try it out for the first time.
Maybe you misunderstood. Rust is already used widely in certain industries and quickly growing in many others. It’s not a question of if rust will succeed at this point. It already has. It’s soon to be allowed in upstream Linux kernel drivers, for example.
Certainly you misunderstood: more people pick up C++ for production use every week than the total employed today coding Rust. That will be true next year, too. More are employed coding Ada than Rust. More code Erlang than Rust. More code Forth than Rust. Rust is not "used widely" by any defensible definition.
It still seems possible that Rust could, someday, come to be used widely, beyond the HN echo chamber, but only with serious action. Wishful thinking has always reliably failed to drive mainstream language adoption.
ngl the borrow chicker is miles better than it used to be in terms of implants cit behavior and just dealing with more "natural" scoping patterns. It sure isn't perfect, but at the end of the day, I trust the borrow checker more than my logic to make sure that multi threaded applications do not have threading issues...
Why would you want to turn it off? I've been writing Rust code for a while and only struggled with this for the first few weeks. The borrow checker is useful and, while I don't mind some unsafe Rust here and there, I wouldn't want to have a Rust dependency that completely disabled it.
This is a curiosity which explicitly asks you not to use it for production. Just an exercise in hacking on the language and making it behave in ways it's not supposed to.
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.
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.