6 ms·
When it comes to Rust, there's no stable version of the language at this point. There's no stable version of the standard libraries. There's no reliable product
by Pacabel 12y ago
When it comes to Rust, there's no stable version of the language at this point. There's no stable version of the standard libraries. There's no reliable production-grade compiler available. As the Rust home page itself states, "Rust is a work-in-progress and may do anything it likes up to and including eating your laundry."
Maybe Rust will offer such stability in the future. But that's of no use to people and organizations who need to develop software today, and who need to be able to trust that the code they write now will compile and work tomorrow, a month from now, a year from now, and perhaps even decades from now.
C++ does offer stable, standardized, well-supported versions of the language. C++ does offer stable, standardized, well-supported standard libraries. There are numerous high-quality free and commercial C++ implementations available, for just about every platform imaginable. It provides a robust and predictable platform that serious and massive software systems can be built upon.
The theoretical benefits that Rust may bring are pretty much irrelevant as long as it isn't a production-ready language in the way that C++ is.
- zxcdw 12y agoBut now you aren't talking about Rust the Language but Rust the Ecosystem. Not that I am disagreeing with your points, I am not. However, when people talk about C++'s problems, I immediately assume they talk about C++'s problems as a language rather than it's ecosysem. Rust isn't out there to tackle C++'s ecosystem, tooling, legacy code or professional workforce, but rather Rust aims somewhere near C++ and fixes many of the language flaws which are inherent in C and C++, while still being competitive in performance and low-level control.
- CountSessine 12y agoEcosystem really is the whole problem, though. You can never make it big without having lots of friends. Rust is a pretty cool language, but I can't help being reminded about another very well-designed but ultimately unsuccessful C++ challenger, D. The parallels are really hard to ignore. D, like Rust, had great syntax and was a breath of fresh air after coding with C++98. Neither Rust not D has a sponsor with really deep pockets to encourage adoption. Neither came out of a standards process. Both have had compiler and standard library issues. The big difference between the two at this point seems to be momentum and where the two are in their parabolic trajectories.
- danieldk 12y agoThere are important differences: D threw away one of the most important features of C/C++ (for the target audience): usability of the language without a garbage collector. Also, Mozilla has much deeper pockets than Digital Mars. Still I agree with you that it is very likely that Rust will follow a parabolic trajectory. The advantages as perceived by the industry compared with C++11/14 will be too few. At the same time it does not have the ecosystem. Go succeeded because of Google's deep pockets and, perhaps more importantly, because it filled a large niche that even the authors did not anticipate: a faster language for Python and Ruby aficionados.
- pjmlp 12y agoGiven the Mesa/Cedar system a Xerox PARC, Oberon at Swiss Federal Institute of Technology and Modula-3/SPIN at Olivetti, doing OS work in GC enabled systems programming languages is quite possible. The problem is how to move OS vendors away from C's influence.
- fithisux 12y agoUse micro-kernels.
- loup-vaillant 12y agoExo-kernels might be a better alternative. https://en.wikipedia.org/wiki/Exokernel https://en.wikipedia.org/wiki/Exokernel
- pjmlp 12y agoIt is a matter of willingness, not technology.
- pcwalton 12y ago> Still I agree with you that it is very likely that Rust will follow a parabolic trajectory. The advantages as perceived by the industry compared with C++11/14 will be too few. Rust is memory- and type-safe (as in: the compiler will not let you write a dangling reference, invalidate an iterator, or write exception-unsafe code without opting into an unsafe dialect). The security benefits alone of that are enough to justify the language for our use cases, and, from what we've seen, for many others. Safe zero-cost abstractions are a niche to its own.
- EpicEng 12y agoI don't think that the two can be separated in any meaningful way. Of course they're different things, and we can discuss each on their own, but when it comes to which language to use as a business decision then the line becomes blurred if not completely transparent.