People to write code instead of sitting on their high horse. That and performance as good as c, not c-like, not selective benchmarks, not other nonsense.
Basically I think it boils down to the fact that the c/cpp tooling is actually really sophisticated at this point and developers have already learned how to deal with the pain points of c/c++ so there is little incentive to change. Especially, since it means swapping out a highly advanced ecosystem i.e. UnrealEngine for the chance to spend the next 5 years building your own not-as-good system to then be able to start to program your own game. And its like this in every C/C++ industry I'm aware of (embedded devices / games / desktop apps).
I'm a rust fan, even more so of cargo (wish C/C++ had a cargo). But at the end of the day it almost always boils down to transition costs vs. benefits, and the benefits currently don't outweigh the transition costs IMHO.
You only need a some major players and big names to get behind rust and I would bet it would surpass C/C++ code-base within a couple of years. It wouldn't replace major frameworks or libraries written in C/C++ but I it wouldn't take much work to write the wrappers around them anyway.
While such support might be helpful, the majority of systems in C++ that I've seen are significantly larger than the libraries they are consuming. In other words, such library wrappers are but a scratch on the surface of the system.
I often wonder - how big does a code base have to be before an advocate of these ideas (ie: "rewrite it in X cause X is abstractly better") might be inclined to backpedal and reconsider their advocacy?
I found working with Operation Flashpoint/VBS2/Arma 2 that the code base being so large and so many edge case conditions that it will never re-written.
One example from the VBS2/Armed Assault 1/2 they replaced the way arrays references are handled. Previously array's assignment was a copy. They changed it so array's assignments would mirror java's references and only the pointer to the buffer would be copied eg.. copy on write. They had so many idiotic edge case conditions that they reverted back to the old method.
So when I say they just need some major backers it would be for new system and applications that would take advantage of the new language. Re-writing most game engines today doesn't have a strong business case. Writing new games/software and shipping faster is more important.
I think you are correct in regards to the people who are currently using C/C++. They already have done the hard work to make it usable for their systems. But newer developers will look at the complexity of C/C++ development and choose anything but.
Maybe it is like politics, rather than attacking your opponents you should offer something that they do not. Then you will build your own constituency and gain influence. It will take a long time, but if you keep on providing benefits to users, then attrition might take you to the top. When someone attacks your camp, ignore them. You do not need a better way to attack them, you just need to stick to the knitting and make your offer provide benefits to users. External forces will likely decide whether or not you overwhelm your opponents.
The problem with this approach is that you would really have to offer something groundbreaking to displace C and C++ while also matching portability (only matched by Java variants) and performance (often unmatched).
The about only languages that could compete right now are extended Ada for high assurance environments and Fortran variants for HPC. They are old but not dead and quite usable if you have the dollars to buy proprietary or invest time.
Microcontrollers and constrained environments are another critical niche for C and C++, especially given proprietary compilers.
Rust does not go far enough in safety to displace Ada (or Spark variant) while not offering improved performance and comparable portability with all the pains of a new language. It also does not do build once deploy everywhere stuff Java and JS attempt. Rust is neither here nor there.
A good effort but not a solution.
What is a "more dedicated language" in this respect? Your options are C, C++, or Rust. Same usual comparisons apply, I don't think wasm is particularly different enough of a situation to have any special advantages.
Not in the world. The options depend on a use case. For a website C++ and rust would be far down on the list. For a web server, even, there is a plenty of competition.
Similarly for an embedded scripting language or rapid prototyping.
I'd argue that safety is vital for web software, so Rust is a candidate for "the best language" for web servers. The same is true for security libraries.
Or how about the original purpose of Rust, to rewrite a rendering engine? That's an incredibly widely used platform.
There's an OS being written in Rust that a lot of people are really excited about. There are very few languages other than C/C++ that are actually viable for rewriting an OS and would, in and of themselves, prevent entire classes of bugs.
"Easy" has no objective definition. Does it mean "getting code to run"? Or does it mean "writing bug-free code"?
For me, easy means the latter. It means that human error is harder to introduce into the code. A great language should not rely on the shaky pillars of discipline or expertise, because neither of those are easy to find or enforce, nor are they consistent. A disciplined expert might be too sleepy to write safe code, for example.
Rust is much easier to use than C and C++ because the compiler helps you so much and replaces discipline/expertise. That's the whole point. Rust prevents you from doing something you don't intend to do (or at least it does it better than most languages).
Python, Ruby, and Clojure don't have the same guarantees, and none of them can be used without garbage collection, making them unsuitable for a variety of cases where Rust can be used.
Compiler does not help you. It is not a proof suggestion system like Isabelle/HOL or the like.
In fact error messages rust produces rival the terrible nature of ones in older C++ compilers thus far.
The compiler only prevents you from making mistakes. Intentions do not even enter into it. See, some of the performance critical code in our apps has to work around even the lax C++11 rules. It is completely impossible in rust without using unsafe stuff liberally - specifically gets about 1000x slower and this matters a lot.
Compilers know nothing about intentions, nor can a borrow checker enforce intentions unlike a type system.
Code already written in C/C++. I don't think there's anything stopping Rust from snowballing at this time. It's built some very strong libraries for certain problem domains, and because there's package management, it's possible to reuse it. This has already substantially reduced the friction of "systems" programming since you don't run into a challenging build process. But for the majority of folks the answer for an immediate need is still a tool or framework they already use.
Inertia. You don't rewrite an existing codebase unless the current one is simply not capable of doing what you need it to. And there are a lot of existing codebases in C and C++.
Rust does much more than reducing bugs. It is able to reduce memory consumption, decrease the required amount of CPU cycles, and increase maintainability / adaptability. ADTs aren't a joke, and neither is Cargo, move semantics by default, and the borrow checker / borrowing and ownership mechanics as a whole. Shipping solutions in Rust can be done at record speeds, and integrate with existing software. Rust is wildly successful, and there's no way of stopping it.
Changing languages isn't free. Rust isn't enough better than C++ for most developers (or their management) to switch.
Or, if you're more of the skeptical sort, Rust doesn't seem to be enough better. You could argue that C++ developers don't think they write code that creates memory issues very often. So they underestimate the benefits. (And the borrow checker is a different concept, so they may also overestimate the costs of switching.)
The net result, though, is that they perceive the benefits to not be worth the costs.
More modern styles of C++ just wholesale avoid most problems that are solved by the borrow checker. Smart and owning pointers, dynamic and checked data structures thanks to operator overloading.
There are remaining warts but not bad enough in practice.
That's not really all that relevant for most existing commercial code since legacy code tends to not get rewritten at all unless it's absolutely necessary, and thus remains stuck with the Old Ways.
What's preventing the tree you planted from replacing the old tree next to it? Nothing really, ask again in 30 years.
Software is slow, your OS and browser have taken 20+ years of C/C++ development with top professional development teams to become the nearly tolerable products they are.
I would've started using Rust way sooner if academia hadn't forced me to use c++ or c for anything systems related. Upon graduation I felt like a kid in a candy store with all the languages and platforms I hadn't tried in my four years of fun.
A big difference is that Rust has a zero overhead interop with C, so it it allows mixed projects or gradual porting.
So Scala or Kotlin replacing Java, or F# replacing C# may be a better analogy. What happens there, is that Java and C# are improving just enough that many people are simply not considering the change... And C++ are trying really hard nowadays too - new version with interesting features every few years etc...
(By the way - I'm a Rust fan, and also a functional programming fan, so I would be happy if C++, C#, Java would slow down a little to let the alternatives really catch up popularity;)
I am actually on your side on this one. But the changeover, I think you will agree, will be somewhat slow. So no one should judge Rust too harshly, for not replacing C++ in the Unreal Engine, Microsoft Office Suite, &al. even in the next 5 years.
As a C++ developer, I think Rust's main selling point (memory safety) isn't as big of a problem as it's made out to be. For every unsafe memory access that results in a crash or exploit, there are millions and millions of memory accesses that work just fine and never cause a problem. Tools like Coverity and Valgrind can catch a ton of errors, and its not clear Rust offers any significant advantages over C++ with Coverity.
Parallelism is nice, too, but C++ already has a ton of options there: OpenMP, MPI, TBB, OpenCL, standard library threads, boost/standard library async tools, etc.
On the other hand, as an end user, "written in Rust" or "written in <any language>" isn't something I care about. I don't even remember the last time I had a piece of software crash due to a seg fault, so a vague promise of being "safer" isn't good enough to accept an otherwise inferior product.
I guess to summarize, C and C++ developers are going to keep writing C and C++ and if Rust is going to take over the world, the people advocating for it will have to write better software in it and beat out software written in the other languages.
Coverity is expensive and majority of software people use are open-source which don't make use of it(hence all the CVEs).
As an end user running a server, i very much care about whether my web server has vulnerabilities. And the promise about safety is not vague, it has clearly defined semantics.
To comment on your last point, it's seeing some light already, ripgrep is already beating grep in performance and is purely written in rust. And i agree that this is how rust will beat C++(if ever), by writing "better" tools than those already exist.
See, people don't care about safety, they tend to want the language to get out of the way. C++ does that because it does not get in the way of a C standard library. Or other system specific stuff.
Rust gets in the way enough that the benefit seems not worth it, and it brings few benefit in the server space over, say, Java if performance is not the paramount concern.
> Coverity is expensive and majority of software people use are open-source which don't make use of it(hence all the CVEs).
It's definitely an area where the closed source tools are ahead of the OSS alternatives, but there are open source (and free closed source) alternatives to Coverity. PVS Studio, for example, has a free download: https://www.viva64.com/en/pvs-studio/
> As an end user running a server, i very much care about whether my web server has vulnerabilities. And the promise about safety is not vague, it has clearly defined semantics.
You say that, yet you're still running a ton of software written in C and C++.
> You say that, yet you're still running a ton of software written in C and C++.
Nice assumption. Much of the software I use is actually implemented in Rust. And soon, I'll be using an operating system that's 100% written in Rust, with a 100% Rust Servo-powered web browser. It's only a matter of time.
In addition, I've also implemented my servers (web server included) in Rust, and they have zero dependencies upon C/C++ software, so your entire point is rendered invalid.
It seems you are missing the point of Rusts safety. Yes that safety does prevent things like segfaults, but the real value is in security. As software becomes evermore critical to our lives in pretty much every aspect, having a system that can be derailed by malicious actors is not just unfortunate in the way that a segfault is, no. It is reckless. At this moment what we see is news about company X or Y being hacked,including some infrastructure like electrical grids. Fast forward a half decade and we will have people being hacked and killed from a distance. All made possible because of bugs.
Rust refactor times are significantly faster than C++, and solutions can be implemented and deployed to production at a much faster rate, without the need to wait for Coverity scans to verify PRs. It enforces proper idioms at compile-time; makes it easier to implement and debug issues with threads; enables the capability to enforce correct API usage (See how Vulkano > C++ Vulkan; or Glium > C/C++ OpenGL) with the aid of additional type information and compile-time state machines; encourages developers to push towards zero to minimal-allocation designs due to the move semantics / borrow checker; opens the door to a wide range of compiler optimizations not possible in C/C++; enables rapid software development through automatically pulling Cargo dependencies from Crates.io, and making it simple to push crates of your own to the repos for others to use, resulting in much less reinventing the wheel, and more extensive testing of community solutions; not to mention the ADTs and pattern matching, and a significant number of additional features that C++ just doesn't have.
Basically the net effects are a mix of:
1. Push more computation to compile time rather than runtime
2. Verify a lot more state at compile time, preventing dangerous or nonsensical state from occurring altogether
3. Because of 2,you get hard guarantees about the runtime state e.g there is no chance of encountering undefined behavior in safe Rust
4. Building, testing, and deploying are all quite straightforward in almost every Rust project. If you can get away with simple statistics, benchmarking is very simple too. The ones that don't typically have native non-Rust dependencies
It seems that you have a very misguided view of what Rust offers to the table. The main selling point of Rust is not safety. Safety is just a side effect of lowering the bar to achieving concurrency/parallelism, which has proven time and time again to be a major problem with C/C++. I can tell you right now that, among the top reasons that people choose Rust for, safety isn't even among the top three.
For many, Cargo is the main selling point of Rust. Then there's the ADTs, move semantics and move-semantic-powered features(borrow checker & compile-time-checked state machines), compile-time static code analysis, FP capabilities, traits and trait-based generics, pattern matching, and the miscellaneous tools and communities surrounding Cargo / Rust. None of which you can obtain with C++. Not to mention how much better the syntax of Rust is compared to C++ -- being able to succinctly express complex patterns in simple, human-readable terms with no room for context-based ambiguity.
Its the operating systems libraries. They're in C.
I did a lot of ada programming (radar) and we had a fairly large library of wrappers to the C network/ ipc / process control that the operating system provided. It was a royal pain. So much so that at least a couple subsystems moved to C (mainly to use the math libraries......)
More modern styles of Ada work pretty well. The trouble is in getting the code to run in a restricted environments. MCU compiler authors tend to provide C only.
For me, equivalent support for the MSVC toolchain on Windows. Obviously it won't ever be 100% without support from Microsoft, and a lot of work has been done, but some items on https://github.com/rust-lang/rfcs/issues/1061 feel important enough to give me pause before spending much time with Rust.
Greenfield systems work by startups isn't really done these days. If it's not greenfield, it's probably already in c/c++. If it's not a startup, they probably already have a bunch of expensive c/c++ tooling (static analyzers, IDEs, CI systems, ...) that they aren't going to get in rust.
Rust has made major strides in the cryptocurrency industry. Cryptocurrencies are largely becoming powered by Rust, because with cryptocurrencies, there is no room for error.
1. Rust is not C/C++
2. Lots of software is already written in C/C++
3. Rust follows the same convention as C/C++, that you integrate functionality by writing a library, compiling and linking it into a monolithic binary
4. Systems that rely on a monolithic binary are NP hard to replace with something different
5. Replacing a monolithic binary works best, in practice, when it is done by refactoring into services that are integrated by something other than a link editor. Although the buzz is all about web microservices, the reality is that message queuing to tie together microservice, macroservices and monolithic binaries, provides better performance more consistent with the linker/monolithic model.
6. Go with its channels and packages may be a more advanced model, and is also competing with Rust. In other words, it is not just a question of comparing Rust to C/C++
7. The JVM with its JIT has in many cases equaled or exceeded the performance of C/C++ monoliths, but languages like Clojure and Scala take it well beyond mere Java.
8. It may be that replacement of systems is driven more by economics than by technology. In other words it is not Rust that will determine the fate of Rust, but the economic sucess of companies using Rust for mission critical systems. In 20 to 30 years, the businesses that have succeeded will determine which technology is better.
Java Achilles foot has always been memory use and really compute constrained environments. Things like high end video game engines are not being written in Java, Closure or Scala for these very reason.
I would be very careful about JIT performance being even close. See, the language does not even expose SIMD well. Doing anything hard realtime (heck, even more complex UI) with a JVM in the way is a big pain.
Just one data point, but: I'm currently learning about embedded microcontrollers. The standard starting point for this is arduino, which is C/C++ based, so there is a strong pull towards C++ already. But I really wanted to avoid C/C++, and I spent a long time researching alternatives. Rust was one of the most mature for MCUs, but a) it's not very mature and b) you have to pick an MCU with a lot of flash memory as even the smallest rust binary is >100kb. For reference, one of the chips I've been testing out for this project has 127kb of flash. This evening I loaded on a medium-sized C++ project and it took just 24kb.
So that's what's preventing ME from using rust instead of C++
I was using the standard rust compiler, plus a bunch of articles on thinning rust binaries. Best I managed was about 80kb after three or four layers of thinning. That link is pretty interesting! The Rev3 uno has 32kb flash, so someone has found a way to thin the binaries enough to fit on an MCU. Cool.. now if only I knew how they did it!
EDIT: Zinc seems to not have been updated in awhile I'm not sure what the current status is of other mcu efforts. I bet some of the other rust folks can elaborate.
The size of a binary statically-linking libstd and targeting a desktop OS has nothing to do with the size of a binary targeting a bare-metal microcontroller where you use only libcore. If you compile for a MCU target with MCU-style code, your code size will be in the same ballpark as the equivalent C++.
How about a smallest real application that doors something useful? Say, basic networking on the level of static pages like uhttpd. (Used in many routers.)
Or a busybox ash equivalent at least.
Another reason that I don't see given its fair chance might be politics. The human race has a wide variety of values that are often counteracting. Forcing a specific set of values participants must adhere to in order to interact with the community will undoubtedly alienate adopters.
That's why most projects, companies, and even governments tend to strip down the rules that govern them to what is necessary for them to function (e.g. separation of religion from state for governments).
The common reason given by the rust community to justify their behavior is that technology does not exist in a vacuum, and that technology can not be separated from politics. I completely agree. However, politics should be tackled on a layer incompletely independent from technology. Mixing the two only causes instability and uncertainty for rust. Here are two risks that arise from this mixing. I'm sure there are many, far more serious, risks besides these two:
- What happens when (not if) a significant shift in values occurs in the community? Will it collapse?
- What about technical or legal changes to the project that were driven by community values rather than technical or legal merits? This is not far fetched when technology and politics are made inseparable in the way it was done in Rust.
I use rust in a professional context, and I appreciate what it brings in terms of technical benefits. but I would be lying if a said this aspect of it didn't worry me. I can not recommend its adoption to colleagues from other companies if asked for this very reason (I was asked once so far).
Community instability or the mere perception of such is a big barrier to adoption, at least for companies.
Using a programming language does not force you to join a community; and what is the Rust community, anyway? Which Rust community? The Code of Conduct pertains to the official venues of communication, not the language itself. All communities have rules. And the rules are quite normal of any community that wants something resembling civility.
While your use cases are definitely valid for you, this is not a Rust issue, but something that's 100% decided by your distro. They decide if, when and how they integrate Rust into it.
As for the multiple copies issue with Cargo:
I generally agree with you that this definitely feels like 1 source of major blow up in project compile times, and it would be nice and useful if that were reduced as much as possible.
But there is a reason that this system is in place: each crate defines how it compiles and consumes its dependency crates, so if crates A and B both depend on crate C, then A might compile and consume C differently than B does. This results in effectively different libraries once compiled, and ATM there is no way to predict in advance what the effect of any given compile flag will be since any flag can switch on/off arbitrary code. Hence Cargo keeps A's C dependency separate from B's.
Then there's the not doubting whether an application uses the latest patches. Up to a point, this can be automated through exploitation of SemVer: if Cargo could figure out that a new library version is API and ABI compatible with the previous version then I'd argue that Cargo should perhaps just auto-update it.
A bigger issue is what happens when a new major version of the library is released, as those tend to break APIs in order to perform maintenance. That is something that as of yet has not been automated.
> While your use cases are definitely valid for you, this is not a Rust issue, but something that's 100% decided by your distro. They decide if, when and how they integrate Rust into it.
It's a rust issue because it's up to the rust compiler to generate ABI compatible binaries, at the moment there is no ABI so there isn't much distros can do. It seems they have no intention of adding one any time soon: https://github.com/rust-lang/rfcs/issues/600
This is why system libraries are nearly always in c and not c++. The ones that aren't (Qt) have a long history of broken language bindings.
This is not as much as a problem as you believe. Rust is perfectly capable of making objects that have a C API and ABI precisely for this reason, and the most popular distros only work with supported compile targets anyway.
That said, a distro like Debian might indeed encounter some issues at this time for the less prominent platforms eg MIPS or PowerPC based chips.
That shouldn't prevent Debian from including Rust altogether though, they merely should exclude it on those less or even unsupported platforms.
It doesn't need to replace it (it's not like c++ is being deprecated), and there has to be real reasons to port over existing code, because there are real costs.
The technically best format doesn't always win. Just look at Betamax vs VHS.
This question is both a leading and also ill-posed. What is preventing Rust from replacing C/C++ _where_? In existing applications? For new code development? In some particular application (e.g. game engines)?
There are lots of good answers in the comments here. I think Rust has a good story for why you might choose it over C/C++ for some uses today, but it's still early days. If Rust is going to take share from C/C++, it will do so over the period of decades, not years.
90 comments
[ 3.5 ms ] story [ 144 ms ] threadI'm a rust fan, even more so of cargo (wish C/C++ had a cargo). But at the end of the day it almost always boils down to transition costs vs. benefits, and the benefits currently don't outweigh the transition costs IMHO.
I often wonder - how big does a code base have to be before an advocate of these ideas (ie: "rewrite it in X cause X is abstractly better") might be inclined to backpedal and reconsider their advocacy?
One example from the VBS2/Armed Assault 1/2 they replaced the way arrays references are handled. Previously array's assignment was a copy. They changed it so array's assignments would mirror java's references and only the pointer to the buffer would be copied eg.. copy on write. They had so many idiotic edge case conditions that they reverted back to the old method.
So when I say they just need some major backers it would be for new system and applications that would take advantage of the new language. Re-writing most game engines today doesn't have a strong business case. Writing new games/software and shipping faster is more important.
Maybe it is like politics, rather than attacking your opponents you should offer something that they do not. Then you will build your own constituency and gain influence. It will take a long time, but if you keep on providing benefits to users, then attrition might take you to the top. When someone attacks your camp, ignore them. You do not need a better way to attack them, you just need to stick to the knitting and make your offer provide benefits to users. External forces will likely decide whether or not you overwhelm your opponents.
The about only languages that could compete right now are extended Ada for high assurance environments and Fortran variants for HPC. They are old but not dead and quite usable if you have the dollars to buy proprietary or invest time.
Microcontrollers and constrained environments are another critical niche for C and C++, especially given proprietary compilers.
Rust does not go far enough in safety to displace Ada (or Spark variant) while not offering improved performance and comparable portability with all the pains of a new language. It also does not do build once deploy everywhere stuff Java and JS attempt. Rust is neither here nor there. A good effort but not a solution.
If you offer something groundbreaking, you don't need to match portability. Many people will be willing to make the tradeoff.
> Microcontrollers and constrained environments are another critical niche for C and C++
Why do you assume Rust can't be used for these niches? I understand the potential issues with old environments, but what about modern/future ones?
> It also does not do build once deploy everywhere stuff Java and JS attempt.
Rust compiles to JS today. It will eventually compile to WebAssembly.
If not, then again, Rust has no clear selling point. It really has to be better at something. Matching is not good enough.
It definitely is not easier to use nor embed. (To compete with the likes of Python, Ruby or Clojure.)
Similarly for an embedded scripting language or rapid prototyping.
Or how about the original purpose of Rust, to rewrite a rendering engine? That's an incredibly widely used platform.
There's an OS being written in Rust that a lot of people are really excited about. There are very few languages other than C/C++ that are actually viable for rewriting an OS and would, in and of themselves, prevent entire classes of bugs.
This thread is about WebAssembly. For that, those are your only options currently.
"Easy" has no objective definition. Does it mean "getting code to run"? Or does it mean "writing bug-free code"?
For me, easy means the latter. It means that human error is harder to introduce into the code. A great language should not rely on the shaky pillars of discipline or expertise, because neither of those are easy to find or enforce, nor are they consistent. A disciplined expert might be too sleepy to write safe code, for example.
Rust is much easier to use than C and C++ because the compiler helps you so much and replaces discipline/expertise. That's the whole point. Rust prevents you from doing something you don't intend to do (or at least it does it better than most languages).
Python, Ruby, and Clojure don't have the same guarantees, and none of them can be used without garbage collection, making them unsuitable for a variety of cases where Rust can be used.
In fact error messages rust produces rival the terrible nature of ones in older C++ compilers thus far.
The compiler only prevents you from making mistakes. Intentions do not even enter into it. See, some of the performance critical code in our apps has to work around even the lax C++11 rules. It is completely impossible in rust without using unsafe stuff liberally - specifically gets about 1000x slower and this matters a lot. Compilers know nothing about intentions, nor can a borrow checker enforce intentions unlike a type system.
This seems like a gratuitous misrepresentation. A compiler does not need a proof suggestion system to help you.
> In fact error messages rust produces rival the terrible nature of ones in older C++ compilers thus far.
No, it doesn't. The error messages are wonderful and constantly improving.
> It is completely impossible in rust without using unsafe stuff liberally - specifically gets about 1000x slower and this matters a lot.
Can you give specific concrete examples?
(No, reducing amount of bugs does not do anything when pitted against well tested mature software that already exists.)
Or, if you're more of the skeptical sort, Rust doesn't seem to be enough better. You could argue that C++ developers don't think they write code that creates memory issues very often. So they underestimate the benefits. (And the borrow checker is a different concept, so they may also overestimate the costs of switching.)
The net result, though, is that they perceive the benefits to not be worth the costs.
Plus the argument was mostly pertaining to new code.
Software is slow, your OS and browser have taken 20+ years of C/C++ development with top professional development teams to become the nearly tolerable products they are.
That's... actually one of the best descriptions I've ever heard about these tradeoffs. :)
So Scala or Kotlin replacing Java, or F# replacing C# may be a better analogy. What happens there, is that Java and C# are improving just enough that many people are simply not considering the change... And C++ are trying really hard nowadays too - new version with interesting features every few years etc...
(By the way - I'm a Rust fan, and also a functional programming fan, so I would be happy if C++, C#, Java would slow down a little to let the alternatives really catch up popularity;)
As a C++ developer, I think Rust's main selling point (memory safety) isn't as big of a problem as it's made out to be. For every unsafe memory access that results in a crash or exploit, there are millions and millions of memory accesses that work just fine and never cause a problem. Tools like Coverity and Valgrind can catch a ton of errors, and its not clear Rust offers any significant advantages over C++ with Coverity.
Parallelism is nice, too, but C++ already has a ton of options there: OpenMP, MPI, TBB, OpenCL, standard library threads, boost/standard library async tools, etc.
On the other hand, as an end user, "written in Rust" or "written in <any language>" isn't something I care about. I don't even remember the last time I had a piece of software crash due to a seg fault, so a vague promise of being "safer" isn't good enough to accept an otherwise inferior product.
I guess to summarize, C and C++ developers are going to keep writing C and C++ and if Rust is going to take over the world, the people advocating for it will have to write better software in it and beat out software written in the other languages.
As an end user running a server, i very much care about whether my web server has vulnerabilities. And the promise about safety is not vague, it has clearly defined semantics.
To comment on your last point, it's seeing some light already, ripgrep is already beating grep in performance and is purely written in rust. And i agree that this is how rust will beat C++(if ever), by writing "better" tools than those already exist.
See, people don't care about safety, they tend to want the language to get out of the way. C++ does that because it does not get in the way of a C standard library. Or other system specific stuff.
Rust gets in the way enough that the benefit seems not worth it, and it brings few benefit in the server space over, say, Java if performance is not the paramount concern.
It's definitely an area where the closed source tools are ahead of the OSS alternatives, but there are open source (and free closed source) alternatives to Coverity. PVS Studio, for example, has a free download: https://www.viva64.com/en/pvs-studio/
> As an end user running a server, i very much care about whether my web server has vulnerabilities. And the promise about safety is not vague, it has clearly defined semantics.
You say that, yet you're still running a ton of software written in C and C++.
Nice assumption. Much of the software I use is actually implemented in Rust. And soon, I'll be using an operating system that's 100% written in Rust, with a 100% Rust Servo-powered web browser. It's only a matter of time.
In addition, I've also implemented my servers (web server included) in Rust, and they have zero dependencies upon C/C++ software, so your entire point is rendered invalid.
How does Rust compare against C++ with Coverity? Because that's the real baseline Rust should compare to.
Basically the net effects are a mix of: 1. Push more computation to compile time rather than runtime 2. Verify a lot more state at compile time, preventing dangerous or nonsensical state from occurring altogether 3. Because of 2,you get hard guarantees about the runtime state e.g there is no chance of encountering undefined behavior in safe Rust 4. Building, testing, and deploying are all quite straightforward in almost every Rust project. If you can get away with simple statistics, benchmarking is very simple too. The ones that don't typically have native non-Rust dependencies
For many, Cargo is the main selling point of Rust. Then there's the ADTs, move semantics and move-semantic-powered features(borrow checker & compile-time-checked state machines), compile-time static code analysis, FP capabilities, traits and trait-based generics, pattern matching, and the miscellaneous tools and communities surrounding Cargo / Rust. None of which you can obtain with C++. Not to mention how much better the syntax of Rust is compared to C++ -- being able to succinctly express complex patterns in simple, human-readable terms with no room for context-based ambiguity.
I did a lot of ada programming (radar) and we had a fairly large library of wrappers to the C network/ ipc / process control that the operating system provided. It was a royal pain. So much so that at least a couple subsystems moved to C (mainly to use the math libraries......)
Perhaps a transpiler would be better.
I would be very careful about JIT performance being even close. See, the language does not even expose SIMD well. Doing anything hard realtime (heck, even more complex UI) with a JVM in the way is a big pain.
So that's what's preventing ME from using rust instead of C++
Were you using zinc or some other project as the base? I figure it is an arm cortex * in your case.
EDIT: Zinc seems to not have been updated in awhile I'm not sure what the current status is of other mcu efforts. I bet some of the other rust folks can elaborate.
See your post sounds like a say so story without data behind it.
So my question is: when can I use Rust on the Cortex M0 (or on a 32 bits RISC-V), with an interactive debugger, preferentially from a simple IDE?
If you have megabytes of flash to spare, it could probably be fine...
Most of Rust's "safeties" are only compile-time, and so have no effect on binary size.
That's why most projects, companies, and even governments tend to strip down the rules that govern them to what is necessary for them to function (e.g. separation of religion from state for governments).
The common reason given by the rust community to justify their behavior is that technology does not exist in a vacuum, and that technology can not be separated from politics. I completely agree. However, politics should be tackled on a layer incompletely independent from technology. Mixing the two only causes instability and uncertainty for rust. Here are two risks that arise from this mixing. I'm sure there are many, far more serious, risks besides these two:
- What happens when (not if) a significant shift in values occurs in the community? Will it collapse?
- What about technical or legal changes to the project that were driven by community values rather than technical or legal merits? This is not far fetched when technology and politics are made inseparable in the way it was done in Rust.
I use rust in a professional context, and I appreciate what it brings in terms of technical benefits. but I would be lying if a said this aspect of it didn't worry me. I can not recommend its adoption to colleagues from other companies if asked for this very reason (I was asked once so far).
Community instability or the mere perception of such is a big barrier to adoption, at least for companies.
1. Write an app in rust.
2. Use a rust library in that app, via the native rust interface (using c interfaces negates a lot of the pros of rust).
3. Dynamically link that app to the distro repository version.
4. Have the distro apply security updates to that library without recompiling my app.
5. Ignore cargo completely.
As a user I want to:
1. Not download and install multiple copies of common rust libraries (as is the cargo norm).
2. Not be in doubt whether a particular application is using the latest patched libraries.
It seems that rust community has learned from the mistakes of c, c++, and java. But they failed to learn the successes as well.
As for the multiple copies issue with Cargo: I generally agree with you that this definitely feels like 1 source of major blow up in project compile times, and it would be nice and useful if that were reduced as much as possible. But there is a reason that this system is in place: each crate defines how it compiles and consumes its dependency crates, so if crates A and B both depend on crate C, then A might compile and consume C differently than B does. This results in effectively different libraries once compiled, and ATM there is no way to predict in advance what the effect of any given compile flag will be since any flag can switch on/off arbitrary code. Hence Cargo keeps A's C dependency separate from B's.
Then there's the not doubting whether an application uses the latest patches. Up to a point, this can be automated through exploitation of SemVer: if Cargo could figure out that a new library version is API and ABI compatible with the previous version then I'd argue that Cargo should perhaps just auto-update it. A bigger issue is what happens when a new major version of the library is released, as those tend to break APIs in order to perform maintenance. That is something that as of yet has not been automated.
It's a rust issue because it's up to the rust compiler to generate ABI compatible binaries, at the moment there is no ABI so there isn't much distros can do. It seems they have no intention of adding one any time soon: https://github.com/rust-lang/rfcs/issues/600
This is why system libraries are nearly always in c and not c++. The ones that aren't (Qt) have a long history of broken language bindings.
The technically best format doesn't always win. Just look at Betamax vs VHS.
There are lots of good answers in the comments here. I think Rust has a good story for why you might choose it over C/C++ for some uses today, but it's still early days. If Rust is going to take share from C/C++, it will do so over the period of decades, not years.
That alone makes me want to crack open some STL code just to spite them, and I hate C++!