There are still areas where C++ is more expressive than both rust and go. AFAIK rust just recently got the capability to work with const generics and compile time evaluation.
Lack of overloading (besides operators) in Rust is a double edged sword. Overloading allows for very expressive C++ code in the expense of awful error messages when it doesn't work out.
C++'s concurrency story is continuously improving, but I'm not qualified to compare here. C++20's coroutines will be quite powerful.
And there is one area where Rust and go can't compete: interacting with existing C++ code, including templates. There is a lot of that already.
Having said that I keep a close eye on rust, it can certainly replace C++ in certain areas, possibly all areas in the future. But it can't replace it overnight, considering that there are millions of lines of _maintained_ C++ code out there.
Not go though, that's like comparing apples to oranges.
I wonder if we could ever get direct Rust to C++ FFI. There are ways around it of course, by dropping down to C FFI in both languages.
https://github.com/dtolnay/cxx/ exists and works well AFAIK. That's what Chromium (https://chromium-review.googlesource.com/q/project:experimen...) and others use.
The question is the opposite: you have to prove to managers the benefit overcomes the risk of using a new language. Rust is still not nearly stable nor popular enough for many fields.
Go is a very different language with different goals and constraints, so the question does not really fit.
> Rust and Go are much simpler to learn
Go is a simple language, yes. Rust is a different beast with the same intrinsic complexity as C++.
> can do everything that C++
Not exactly true (for the moment). Rust is lacking on const generics, HKTs and other details.
> sane, simple and clean build systems/package managers
That is not a big argument for the kind of projects is used for.
And it is not true either, since nowadays there are several competing, modern package managers for C++ too (build2, Meson, Conan, modern CMake...).
> not to mention async/await concurrency
The async IO model has been available in many languages for many years, including C++. In the recent years several languages (including Rust and C++) are bringing syntax sugar to let the compiler create the state machines. But it is not the only way of doing async.
I'm not sure what you're saying. Rust 1.0 code compiles just fine in the most recent rust compiler. It's been stable since that 1.0 point and promises to continue being stable. C++ doesn't have a a stable ABI either.
https://news.ycombinator.com/item?id=24032305
Tl;dr: C++ is now and will remain the near-exclusive choice for essentially all of the highest-paid, most demanding work in medtech, fintech, CAE, HPC, telecom, and aerospace, for decades to come. Rust code will never be able to call into the very powerful libraries these applications depend on, because they are based on language features Rust will never have. No language other than C++ and Rust targets these applications.
Very noisy Rust advocates here are inaudible elsewhere; many more people start using C++ in every week than the total who touch Rust in that week. That will not change soon.
Rust is a much better language than C, Go, Java, C#, Visual Basic, Delphi, COBOL, Nim, and Dart, and much faster than Python, Ruby, and Perl. Advocates would better focus recruiting there than tilting at C++.
* Compiler support
* Availability of suitable engineers
Context - I work for the Wireless Division of Cambridge Consultants (Cambridge, UK). We build comms technology for our clients for basically anything you can think of - satphone, telecomms infrastructure, bluetooth headphones etc. This means that a lot of the software we right runs on an embedded target - that might be a microcontroller or it might be Linux. And importantly - often when we've designed something, our clients will carry on the maintenance and ongoing development.
We have to take the long view - if we choose C/C++ we can guarantee that a compiler will exist for whatever hardware target they choose for the next generation of the product (or even the current generation - architecture swaps often happen at the cost reduction stage). Rust support is improving but can I guarantee that there will be a compiler available for some niche processor, or even the Xilinx Zynq target I'm using at the moment?
And then when we hand over the code, we have to explain to the client that it's written in a language that none of their existing software engineers know, and if they advertise for people they may or may not be able to find them.
All that said, we are pushing to use more suitable languages for our work. Using C/C++ for anything where security is important is beginning to look irresponsible, the above issues don't always apply and that combined with improved embedded support, more name recognition for Rust and ever more enlightened clients means that it's going to be an easier sell for more and more projects. But not all of them, not now.
Actually it turns out that it's easier to sell Elixir as an alternative to some of our C development. My current project is a Linux target, microprocessor support is not important and the challenges it has are exactly what Erlang is designed to solve. I'd also suggest it's easier to incrementally teach the client Elixir than Rust. We'll keep pushing Rust though, and we'll get there eventually.
When you turn code over to someone else it matters because who you turn it over to needs to learn the language fast and they won't have a few weeks or someone else to teach them.
Although it is a polyglot target environment, CUDA hardware is designed for optimal support of C++ semantics.
C++ is used for device drivers on Apple and Google's OSes.
Swift and Rust depend on LLVM, written in C++.
Unreal, Unity, CryEngine, Godot have C++ at their core.
AUTOSAR safety standard for cars is based on C++14.
UWP and DirectX are heavily based in C++.
Tensorflow and PyTorch depend on C++.
And plenty of other endless examples.
Sure you can try to make do with Rust or Go, but be prepared to code like we used to program in C++ 30 years ago in regards of eco-system, IDE support and wealth of existing libraries.
Additionally, if you work at one of the FAANGs (or many other large established companies) there's good chance you are working on an existing C++ base, with existing C++ build tools, with a good C++ style guide, and with plenty of other competent C++ engineers. Rust is not of the endorsed/established languages at Google. (And no, Go isn't frankly used as much at Google as people seem to think it is, though its use is increasing).
That's a bit of an extreme statement that needs some significant qualifications. This might be true if you are pushing for Rust or Go in one of the domains you mentioned, like professional game development. It would be fairly absurd for a studio to seriously try to switch to Rust in some of these areas.
That said, if you're largely working on greenfield projects that don't rely on an existing C++ ecosystem, the situation almost gets inverted. For instance, C++ still doesn't have any kind of standardized package manager in 2020. There are a thousand little paper cuts in C++ that are hard to justify if you don't have to interface with an existing ecosystem or target a specialized environment that only it is well-suited for.
That said, I do think that for a certain category of greenfield projects that can avoid needing certain types of dependencies on and interactions with other existing software or codebases, Rust and Go will completely dominate C++ going forward. For new work that doesn't need the C++ ecosystem and doesn't rely on dependencies not available for Go/Rust, it really is hard to imagine how one of Go/Rust would not be a significantly better choice in 2020 and beyond.
Some companies will be entirely based on such greenfield projects. Others will be entirely based on problems that rely on some of that existing C++ ecosystem. Yet others will be mixed and may be able to use C++, Go, and Rust as it makes sense. So I think it's going to be a complicated situation where some folks will be able to completely move ahead of C++ and others will be tied to it for a long time yet.
There are 2 levels of comparisons:
- (1) language syntax : the "they're both Turing Complete" so whatever one can do, the other can do and because Rust is newer, it has nicer syntax. E.g. plain Rust syntax already has "ownership pointers" by default so doesn't require typing ugly verbose syntax such as "unique_ptr<T>".
- (2) ecosystem and dependencies : In 2020, C++ and not Rust is still the primary API for things like NVIDIA CUDA, Unreal game engine, Qt GUI, and the ARM Allinea developer tools[1] for compiling code for the new Neoverse chips (e.g. latest AWS Graviton2 ARM servers). Sure, one could write wrappers in Rust for all those things but doing so will be going against the grain and now you're yak shaving your tools instead of building business value.
If I had a brand new startup today, I'd use Rust as much as I could but there'd still be 25% to 50% new C++ code because deep learning (e.g. CUDA) is C++ not Rust.
[1] https://www.arm.com/products/development-tools/server-and-hp...
I don't think this is true. I say that even though I would be deliriously happy if Rust replaced C++ in most situations it's currently used.
Yes, learning the whole of Rust, including any/all dark corners (no doubt it has a few) is easier than learning the whole of C++ including all its dark corners (it certainly has many!). But getting a basic working knowledge of both is not too different... except for Rust's ownership system. I realise that the ownership system is one of Rust's main benefits, but that doesn't change the reality that it's a significant obstacle for many decent developers.
I actually wish it were possible to use Rust in an "unsafe everywhere" mode where you could ignore the ownership stuff. (Maybe this is already possible with liberal use of the "unsafe" keyword, but it is at least socially unacceptable.) Of course it wouldn't be right for every project but it would still be a huge improvement over C++ while being much more accessible than fully safe Rust.
As for the rest, there is vcpkg and conan nowadays.
Needed some high performance code last year, wrote it all in c++. This year migrated to Rust, will never look back.
C++ is going to need to break things if they want to fit into the modern landscape.
Speaking of modern landscape where is a Rust IDE comparable with VS, C++ Builder, QtCreator?
I use VScode with rust-analyzer and its been a great experience, had an easier time with it than the c++ vscode extension.
So does any of the main package managers for C++.
> had an easier time with it
That is an empty argument. Not to mention Rust is only now in 2020 starting to get actual IDE support.
For C++ there are at least 8 major production GUI IDEs available, plus a few TUI ones too, plus dozens and dozens of specialized tools around it.
> That is an empty argument. Not to mention Rust is only now in 2020 starting to get actual IDE support.
Actually thats an empty argument, I'm responding to someone saying rust doesn't have IDE support.
It does, I use it every day and it works great. Not saying c++ doesn't just saying it worked better for me than the MS c++ vscode extension.
rust-analyzer is great and we have waiting for it a long, long time. But it is not an IDE. Neither is the MS C++ extension.
I've been using vscode for the last 5 years for all kinds of languages and have never though to myself "I wish I had an IDE"
The Rust and C++ extensions are very far from what an IDE offers. They only handle basic debugging and code completion/browsing. With a few more extensions you can a bit better, but again, you are doing the job that an IDE is supposed to solve for you.
There is an eco-system out there for C and C++ developers where companies only sell binary only libraries.
VSCode is not an IDE, just an text editor with a couple of plugins.
C++ Builder, Visual Studio, XCode, Android Studio, QtCreator, KDevelop, those are proper IDEs.
vscode is one of the most used editors on the market and I seem to be able to produce quality software in a number of languages with it.
As for binary dependencies, I'm certain Rust will have that in the future. I'm fine without it for now, and what I'm not certain of is whether C++ will ever actually fix their problems because they seem to think they don't have any!
So not an IDE, see.
> (Try to contain your horror! :-) )
Ha! Nah, no horror there. It is interesting to think about, for sure.
(Obviously I'm not a Rust expert, which is why my comments are in the form of questions.)
You can cast them to a reference. The issue is, the tricky UB happens at this exact boundary. If you're only using references, then the compiler has your back. If you're only using raw pointers, then there are no aliasing issues, so you're good. The hardest part is exactly the boundary between the two. Staying in one world or the other is much easier than going back and forth.
I think one make a good argument for Rust, but you will also have a harder time sourcing developers and ramping up to speed. It's still novel, despite maturing rapidly.
There are many many many high quality C++ libraries out there, and the modern C++ language is, for me, decently pleasant to work with, once you pick your style and set of constraints.
Also, I really don't want to go around on this argument _again_, but I don't think Go is a serious competitor for C++ for the systems level programming where C++ dominates. Go is not the language for writing OS kernels, drivers, embedded code, etc. Nor do I think a garbage collected system is appropriate for hard real time systems of most kinds.
I think what we have here in this discussion is another classic case of HN having a bit of a blindspot for anything that isn't web / web services or mobile app development. For many embedded systems developers for example it's a challenge just to get them to consider C++ over C, let alone something like Rust.
The issue for you might be ease of configuration, but that's not the issue I was talking about. It's availability of libraries and toolkits, which C++ still dominates in the realms of mathematics, graphics & video, GPU programming, gaming, embedded, networking, etc. And if there's something not available for C++ chances are it's there for C and easily used or wrapped.
Configuration management has indeed been C and C++'s weak point, but in the last 5-10 years things have definitely improved since the world of autotools and the like, and while I appreciate Rust's module and package system for what it is... I can get by with CMake + Hunter or similar systems.
And besides, for my day job (Google) it's either C++ with GN/Ninja or C++ with Blaze/Bazel. And that is also quite excellent for what it is.
At this point my career being able to quickly try out a package or rapidly add a new dependency isn't my measure of quality engineering. In my past life I was a Java developer and a big Maven advocate (when it was pretty new); and the world of bottomless dependency trees that spawned is not something I'm eager to repeat. These days I try to keep my external dependencies ... strategic.
and community is the most important aspect of a language.
Yes c++ still dominates in accelerated computing but it won't for long. All these conversations I've had with c++ devs have just assured me of its demise.
Why would the next generation of developers ever use c++ over Rust?
Don't have a library? Great thats my chance to make my mark.
Except that now there is vcpkg, conan, prefab (on Android) and contrary to cargo,they support binary libraries, meaning I don't have to build the world every time I start a new project.
Doesn't support binary libraries? I don't really care considering everything else I get, I'm sure they'll support that in the future.
Speaking of modern landscape where is a Rust IDE comparable with VS, C++ Builder, QtCreator?
You got a similar response in another thread: https://news.ycombinator.com/item?id=24038376
C++ doesn't conform to this model.
Even without a package manager adding dependencies manually is quite easy for the vast majority of popular libraries. With a manager it is the same as cargo.
I assume you are talking about old, broken, unsupported, closed source, binary only libraries, but then it is not a meaningful comparison.
This is exemplary of why Rust will win out in the end. The c++ crowd can't acknowledge its shortcomings and fix them in a meaningful way
Usually a single line does it in all of them, either in the shell or in a config file.
I call FUD.
Rust is going to make the C++ community actually look in the mirror for the first time in who knows how long.
Looking at some of the solutions for both Go and Rust, its either immature bindings to wrap around C or C++ for the same thing (the best you would get is GTK+) which are unmaintained and less stable / usable to what you would get with Qt5 with C++.
I still keep seeing lots of cross-platform closed and open-source GUI apps still taking the Qt route.
ISO C++ also does not define how std::thread should be mapped into the host platform.
If you are working in an embedded environment Rust is still very capable, but the tooling for Rust does not seem at the level of the embedded tooling for C and C++.
You can still use Rust for embedded, and there are success stories to be found in the links below.
[1] https://www.rust-lang.org/what/embedded [2] https://rust-embedded.github.io/book/ [3] https://github.com/rust-embedded/awesome-embedded-rust [4] https://github.com/rust-embedded/cortex-m-quickstart
But these are huge reasons. It is the difference between theory and practice. In theory you can just replace C++ with Rust. In practice, it can be difficult because of those reasons.
Choosing a language isn't just about the language, but about the entire ecosystem and community.
Rust requires references to memory to be visible at compile time. If you use direct DMA for I/O then the silicon holds mutable memory references at runtime that are not visible in code at compile time. In C++ you can make ownership objects (in the vein of unique_ptr) that automagically track the lifetime of DMA references. Exposing most of your address space to DMA is not optional in databases if you care about performance. DMA has other nuances as well e.g. it can modify memory that is not part of the object you care about and which might be "owned" by someone else.
There are safety models wherein it is provably safe, and optimal code-wise, for multiple mutable references to the same object to coexist at runtime. Modern databases often use schedule-based safety, which dynamically reorders operations on references at a fine-grained level, for performance reasons, and which guarantee correctness of the aggregate execution graph without using locks. This wasn't common a decade ago but it is today. A developer can grab all the mutable references they need to objects, knowing that the execution scheduler can see through and arbitrate any potential conflicts. (This is a sophisticated reimagining of the old "deadlock-free" locking structures in databases without the locks, which didn't prevent deadlocks per se but transparently detect and resolve them.)
You can make all of this work in Rust by using a lot of "unsafe" and inelegant data structure workarounds but it voids most of the safety benefits of Rust and requires more complex code.
[1] https://blog.japaric.io/safe-dma/#:~:text=DMA%20stands%20for...
> In C++ you can make ownership objects (in the vein of unique_ptr) that automagically track the lifetime of DMA references.
does that require os support to make it work? i assume the tracking is handled by some specific inturrupts?
> You can make all of this work in Rust by using a lot of "unsafe" and inelegant data structure workarounds but it voids most of the safety benefits of Rust and requires more complex code.
i see... so i guess rust would have to take one small step out of static, and into dynamic territory with a smart pointer "trait"?
There is a lot of implementation detail, but you need object references that are aware when a DMA operation is outstanding on address space they “own”, the type of DMA operation, and rules about when new DMA operations can be scheduled with respect to object reference lifecycles. There are no fixed set of rules but there are a common set of design patterns. The scheduler design does a lot of the heavy lifting.
If you find Visual Studio and CLion to be your desired work environments, both of them have support for Rust code via extensions. No it won't be as perfect as what you're used to, but it will be more than sufficient for most people.
I've also used QtCreator, and hated it because for me it was a resource hog, you had to do things its way, and the Qt APIs were horribly designed.
Don't know about Rust, but for go:
. can't match C++ on speed
. doesn't (yet, AFAIK) have generics.https://github.com/f-secure-foundry/tamago
Go was at least originally touted as a C++ replacement, but to be honest, that story hasn’t really panned out in practice.
But TBH, I really don't want to use C++ if the circumstance allows. The language spec is just so overtly complex that feels self-defeating, it is harder and harder to justify use it in the first place.
If you are not on a green field, stuff gets complicated. If you have a really good Rust programmer on the team, that is willing to take care of the language interop it can work well, if you have a bunch of Rust learners, you might blow up.
Are there C libraries you want to remain (nearly) source-compatible with while using classes, templates, and other more modern programming features?
Even if exist, is better to let it die. C/C++ is a costly mistake. VERY costly.
Apart of interact with legacy code, both C/C++ have much better replacements (like pascal).
Is only the stubborn "but what if I need to replace my heavily bug-ridding, unsafe, crash-prone, hard-to-mantain, harder-to-prove is good; source code, and need to retrain my developers that spend a lot of mental energy in workaround them in something, better?????"
Our industry is weird.
In any other, if the "engineers" insist in use a well-know unsafe tooling and refuse to learn safer tooling/practiques you will fire them as incompetents.
By the way, I learn mechanical engineering (at trade level).
Not sure what you are basing this on but it's probably not an exaggeration to say that C/C++ has generated hundreds of billions of dollars in revenue over decades, not mentioning employment, advancement in programming language theory, learning lessons, etc...
I am really not a fan of C++ overall but its achievements cannot be understated. Saying it's a "VERY costly mistake" is baffling.
And PHP, Cobol, Perl, etc. Just because a tool is useful is not a reason to avoid point their problems.
And C/C++ have very well know problems, since decades ago.
> Saying it's a "VERY costly mistake" is baffling.
Maybe if MS say it?
https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
https://www.zdnet.com/article/microsoft-heres-why-we-love-pr...
Just to point a recent one...