Money quote: "Rust benefits here that very few people are being forced to use Rust."
Probably more people pick up C++ for the first time, in any given week, than the total who use Rust in production today.
Rust also benefits from the limited historical baggage that comes with being new and incompatible. Unlike Java, which was in the same position, Rust adopted very few old mistakes, and especially unlike Java made few new ones. But as the language approaches industrial maturity (possibly within 10 years) early mistakes will become evident, and cruft will be seen to accumulate.
Rust designers have consciously chosen to keep the language's abstraction capacity limited, which makes it more approachable, but reduces what is possible to express in libraries. Libraries possible, even easy in C++ cannot be coded in Rust. The language will adopt more new, powerful features as it matures, losing some of its approachability and coherence. But Rust has already passed a key milestone: there is little risk, anymore, that it could "jump the shark".
The language is gunning for C++'s seat. Whether it becomes a viable alternative, industrially, is purely a numbers game: can it pick up users and uses fast enough? The libraries being coded in C++ today will never be callable from Rust.
Go proved that the world will make room for a less capable language (in Go's case, than Java) if it is simpler. Rust is much more capable than C, Go, or Java, and the world would certainly be a better place if everybody coding those switched to Rust. So, my prediction is that Rust and C++ will coexist for decades. The most ambitious work will continue to be done in C++, but a growing number will have their first industrial coding experience in Rust instead of C, and many will find no reason to graduate to C++.
> and the world would certainly be a better place if everybody coding C or Go switched to Rust
Perhaps. Let's engage in a thought experiment. Sorry for moving slightly off-topic, but the line I quoted made me think about this.
Someone fashions a magic wand, which you can wave over C, C++, and Go programs / libraries to instantly re-materialize them as idiomatic Rust, while preserving all of the "good" output they produce, and simultaneously removing the "bad": all memory safety and data race related bugs they exhibit.
You get to use this magic wand on any program you like, instantaneously. You do so, creating linux-rs, glibc-rs, chromium-rs, etc. in the process. You cargo build all of this new software and replace the old C / C++ versions with it, in-place.
In the brave new Rust-powered software world, does your day-to-day computing experience change? It is materially better?
Speaking for myself, the answer is "no", unfortunately. Perhaps this message is coming from a place of frustration with my own day-to-day computing experience. Most software I use is much more fundamentally broken, in a way in which doesn't seem to be dictated the programming language of choice. The brokenness has to do with poor design, way too many layers of absolutely incomprehensible complexity, incompatibility, and so forth. I don't remember the last time I saw a Linux kernel oops or data corruption on my machine, but I am waiting _seconds_ to type a character into Slack sometimes.
I like most of the ideas behind Rust (I don't like the language itself and some of the choices the authors made, but that is another discussion). However, I think there is only so much you can fix with the shiny and sharp new tools, because it seems to me that most issues have little to do with low level matters of programming language or technology, but with higher level matters of design, taste, tolerance for slowness / brokenness / incompatibility, etc.
Part of the reason your Slack is so slow is that a lot of stuff is built to protect from problems that Rust might eventually solve.
Slack builds the UI on web technology that got widespread in part because it solves awkward problems with deployment (self-contained and consistent graphic libraries, so you don’t have to worry about how your DE compiled this or that other toolkit) and safety (web tech is heavily sandboxed so that crashes and executions won’t open doors to bad actor). In the long run, Rust will definitely make the latter less cumbersome (less worrying about crashes -> simpler, lighter, faster sandboxes) and possibly help with the former a bit (desktop environments and their libraries could shed some complexity when moving to Rust and make it easier for programs to access them safely).
I think it’s a noticeable step forward. Will it solve everything? No, some of the problems with Slack-like situations are due to economic factors (browsers sticking to JS will forever continue to make JS programmers cheaper and more plentiful than basically any other type of programmer) that Rust is unlikely to affect. But perfect is the enemy of good in this sort of thing: incremental progress is better than no progress.
But I think Rust is also quite vulnerable to the layering problem the previous commenter is speaking about. One of the best things about Rust is how easy Cargo makes it to include 3rd party code in a project, but this is also one of Rust's biggest risks. It's already common for Rust projects to have massive lists of dependency, and that's something which generally gets worse as time goes on rather than better.
Rust as a language may have favorable properties with respect to speed and safety, but programs which run on top of a massive tree of third party code which has been written by god-knows-who tend not to be very fast or very secure.
NPM has already shown that dependencies can be used as an attack vector, and unless Rust can solve this problem, I don't think it's going to bring us some brave new world where we don't have to sandbox anymore.
> programs which run on top of a massive tree of third party code which has been written by god-knows-who tend not to be very fast or very secure.
You have a point about security, but not about the speed. I can probably link 5 "we rewrote in Rust and it was much faster" articles. All of these used third party libraries. ripgrep for example, is faster than grep, despite having more dependencies. In reality, it just promotes better code reuse without impacting run time speed. If anything, separating your code into crates improves incremental compilation times.
It's possible that you might pull in a large dependency with many features. Compiling all of this and removing the unused code will cause a compile time penalty and no run time penalty. In practice, Rust crates that expose multiple features have a way to opt-out/opt-in to exactly what you need. No penalty at all. In any case, most rust crates err towards being small and doing one thing well.
I agree that Rust has very favorable characteristics when it comes to performance. My argument would be that language choice is not a panacea. It's certainly possible to write performant code which leans on dependencies, but the style of development which relies heavily on piecing together 3rd party libraries and frameworks without knowledge of their implementation details is not a recipe for optimal performance.
I see this as sort of saying "Imagine you could cure Ebola, is the world a better place? Well, for me, no, I'm much more likely to get hit by a car".
While I am unlikely to be attacked through a memory safety exploit, I also:
* Have been attacked through one in the past, when the internet was a different place
* Wonder how much time and money could be better spent if we just eliminated that entire class of problems - perhaps solving some of those poor design issues?
I think the reason such a magic wand can't exist is actually why it would be a material improvement if it did - it would fix swathes of bugs that rustc would refuse to compile, and that require understanding the application semantics to fix.
I don't know when I last saw a kernel oops or data corruption either, but iu certainly routinely experience bugs that could be manifestations of memory mismanagement.
And if everything written in Java would be transpiled, with no `panic`s, bells, or tracebacks :vom:'ed into the GUI, oh how I'd celebrate.
Would Rust actually solve heartbleed? Most memory safe languages wouldn't have, because it wasn't using regular memory management, it was using a custom memory pool with custom array types that would refernce that pool.
Maybe in many other languages they would have had better alternatives than that implementation, but I'm pretty sure that their implementation could have compiled to valid Rust that would have had the same heartbleed bug.
>Rust designers have consciously chosen to keep the language's abstraction capacity limited, which makes it more approachable, but reduces what is possible to express in libraries. That means libraries possible, even easy in C++ cannot be coded in Rust.
Like what? I can think of many examples where I can't express the abstraction from Rust nicely in C++. proc_macros, strong typing, macros that are part of the AST, enums with data, safe passing by reference, nice iterators (none of this begin() and end() line noise), less noisy lambda syntax, and of course memory safety.
It's especially nice abstractions where Rust shines, compared to C++.
Both C++ and Rust have nice abstractions. Since you asked for an example of a C++ one, consider a bignum library.
In C++ you can write a natural-feeling library that provides familiar arithmetic. In Rust, you will be constantly smacked in the face with lifetimes, borrowing, etc. because there's no way to do implicit clones or borrows.
`Copy` implies that an object can be bitwise copied while preserving desired semantics; Rust has no exact equivalent to copy construction or move semantics in C++, which can be entirely implicit while involving custom code. (There's a 3rd-party `transfer` crate that enables a `Clone`-like marker for custom moves, however. It's used together with the Pin feature, so these moves are also explicit.)
Plenty of those can be better expressed in C++20, alongside clang tidy and VC++ analysers.
Compile time reflection and metaclasses already exist as VC++ prototype, demoed at Visual C++ 2020 virtual conference.
While I enjoy using Rust, what I care about are the libraries and IDE tooling, specially for .NET and Java integrations, so for better or worse, C++ keeps being the tool to pick.
Also I have big hopes for Rust/WinRT, but it is still very early for it to eventually reach C++/CX tooling, which even C++/WinRT is currently playing catch up and where WinUI team is placing their resources.
>Plenty of those can be better expressed in C++20, alongside clang tidy and VC++ analysers.
Aside from lack of C++20 support on many targets, Clang tidy and extra analyzers require other people to take the same care as you do, an assumption that, as somebody mentioned in that article, is unreasonable to make in a non-solo project.
>Compile time reflection and metaclasses already exist as VC++ prototype, demoed at Visual C++ 2020 virtual conference.
A prototype in a Microsoft dialect of C++? That's apples and oranges.
>While I enjoy using Rust, what I care about are the libraries and IDE tooling
IDE tooling has gotten better, but of course that does still lag behind. While C++ build systems IMHO lag behind cargo, so for me that's a tie.
You are the one missing the point, either you embrace corporations support or not. There is no pick and choose here.
Plus what makes Microsoft bad, and Oracle, Apple and Google contributions good then?
I am astonished that FOSS religion keeps being a thing, while it has been proven in the last 25 years where most projects without corporate love end up.
Nobody but you has mentioned rejecting Microsoft contributions to the Rust compiler and library suite. Nobody but you has mentioned there being anything wrong with MS, GOOG, AAPL, ORCL or anybody else contributing to projects.
The topic is people who are not otherwise beholden to Microsoft (and, thus, not employed by Microsoft) writing code that works only in Microsoft execution environments.
I have explained this three times in this one thread. I don't know a way to make it any clearer. What is so hard to grasp about this distinction?
> That means libraries possible, even easy in C++ cannot be coded in Rust.
Can you give some examples of libraries that can be made in C++ that can't in Rust and why they can't? Having never used Rust yet I'm curious what the issue is.
Imagine something like SwiftUI, including support for dragging components out of a toolbox, and having an eco-system of companies selling such components.
> Go proved that the world will make room for a less capable language (in Go's case, than Java) if it is simpler.
Is this a fact, is there consensus on this? Didn't it just prove that if you are a corporation the size of Google, you can push your libraries or languages that far and make them that popular, just by virtue of forcing some people to use them and spend a lot of resources on guides and development and marketing?
If you are a platform vendor like Apple or Microsoft you can be dictatorial and only support your language of choice; In fact Apple's infamous "section 3.3.1" was going to limit iPhone apps to only use approved languages.
But I don't see how Google uses their ecosystem to push Golang. Sure, they use their resources to develop the language and people probably feel better adopting a new language that comes from an established tech company with a lot of resources than one that is purely unfunded open source.
I'm pretty sure most people using Go choose it for the simplicity and low overhead of the runtime, not the language itself. Perhaps the simplicity of the stdlib as well.
Though I would say that Go's tools are anything but simple from my point of view, once you get past the very simplest things. It is much easier to understand how to configure a Maven-based project with multiple modules, where it will get those modules from, and what version numbers everything has, for example, than it is with `go mod`, which has far too much magic and barely documented behaviors still. Also, there's still no good IDE, no good language server, no good refactoring tools, and no good debuggers for Go.
Go tooling is still way behind Java, C#, and Node, to name just the ecosystems I've worked with. It's better on the deployment side than C or C++, but worse on the debugging side.
> The libraries being coded in C++ today will never be callable from Rust.
This is not true. The FFI story for Rust <=> C++ [1]is good enough that people are experimenting with it. Where I work at, most internal infra client libraries are written in C++ and now they're all available in Rust.
Your prediction that Rust and C++ will coexist for decades is almost certainly true. But I foresee that they'll coexist in many of those codebases. Code that operates on untrusted input will be written in Rust for security reasons while the rest of it is in C++ or Rust. That's the approach that Chronium [2] is experimenting with.
The language features that make C++ libraries powerful are wholly inaccessible from Rust, and will remain so. Rust will only ever be able to use parts of C++ libraries specifically cut down or bowdlerized for access by foreign languages.
Much of the power of C++ libraries is in their ability to direct the compiler's treatment of the calling code.
You cannot write an equivalent of std::tie in Rust, or call it.
I'm of the opinion that Rust copy-pasted a number of C++'s mistakes, although mostly the trivial ones.
To name a few, required semicolons just feel dated and unnecessary when compared to the many modern programming languages where they're not required.
Also the use of vector to name dynamic-length arrays is something which has been an annoyance in C++ for decades for anyone who deals with linear algebra and would really like to have that name reserved for its precise mathematical meaning.
These are quibbles, and they don't really matter, but it's frustrating that the opportunity was missed to put these kinds of issues to rest and not carry them forward into a brand-new programming language.
Probably more people pick up C++ for the first time, in any given week, than the total who use Rust in production today.
Rust also benefits from the limited historical baggage that comes with being new and incompatible. Unlike Java, which was in the same position, Rust adopted very few old mistakes, and especially unlike Java made few new ones. But as the language approaches industrial maturity (possibly within 10 years) early mistakes will become evident, and cruft will be seen to accumulate.
Rust designers have consciously chosen to keep the language's abstraction capacity limited, which makes it more approachable, but reduces what is possible to express in libraries. Libraries possible, even easy in C++ cannot be coded in Rust. The language will adopt more new, powerful features as it matures, losing some of its approachability and coherence. But Rust has already passed a key milestone: there is little risk, anymore, that it could "jump the shark".
The language is gunning for C++'s seat. Whether it becomes a viable alternative, industrially, is purely a numbers game: can it pick up users and uses fast enough? The libraries being coded in C++ today will never be callable from Rust.
Go proved that the world will make room for a less capable language (in Go's case, than Java) if it is simpler. Rust is much more capable than C, Go, or Java, and the world would certainly be a better place if everybody coding those switched to Rust. So, my prediction is that Rust and C++ will coexist for decades. The most ambitious work will continue to be done in C++, but a growing number will have their first industrial coding experience in Rust instead of C, and many will find no reason to graduate to C++.