Ask HN: Why would you ever use C++ for a new project over Rust?
Was having this debate with a coworker recently who’s a Rust fanatic and prior C++ eng; he said the tooling and support has gotten so good you would just be shooting yourself in the foot if you ever started something new on C++. I wasn’t convinced but is this really the case? Like if you had equal skill in both, is there ever a case for doing a project in C++ (outside of being forced by the platform you’re working on or anything outside your control)?
41 comments
If you want to create any real-time graphics application (video games, game engines, CAD software, visualization, etc.), or do any sort of scientific computing / HPC. The graphics ecosystem in Rust is still too undeveloped to see adoption (for the graphics API people are converging towards WebGPU, but it's still no match to Vulkan / DX12 / Metal), same goes for any GPGPU computing. Rust is also currently lacking in desktop GUI development (though nowadays Slint is trying to catch up with Qt!)
And in the case of apps where objects can have very dynamic lifetimes (like game engines or CAD), the borrow checker wouldn't really help with you that much since you would have to manage these with reference counting or some other way anyway (ex. arena allocation + generational indices).
What Rust excels over C++ at this point is just sane defaults / less footguns (no uninitialized memory, bounds checking even in release mode) as well as some language niceties, but Rust has its own issues for pragmatic usage (slow compilation, lackluster libraries, cumbersome to interface with C APIs, ...)
And in the case of apps where objects can have very dynamic lifetimes (like game engines or CAD), the borrow checker wouldn't really help with you that much since you would have to manage these with reference counting or some other way anyway (ex. arena allocation + generational indices).
What Rust excels over C++ at this point is just sane defaults / less footguns (no uninitialized memory, bounds checking even in release mode) as well as some language niceties, but Rust has its own issues for pragmatic usage (slow compilation, lackluster libraries, cumbersome to interface with C APIs, ...)
A note: EGUI is nice for GUI dev in Rust. I agree on WGPU being limiting for 3D graphics. For GPGPU, you can use a CUDA binding, where you write the shaders in C++, and call that from Rust.
There are BGFX crates for Rust, by the way.
It boils down to a few key points:
Mature Libraries: C++ has a treasure trove of well-established libraries. For niche or legacy needs, C++ might be your only option. Performance Control: When you need to micro-manage performance, C++ gives you the nitty-gritty control that can make all the difference. Industry Norms: In some fields like game development, C++ isn't just preferred, it's expected. Sticking to industry norms can sometimes outweigh the benefits of newer tech. So, while Rust has its perks, especially around safety and concurrency, C++ still holds its ground where its deep-rooted ecosystem and granular performance control come into play.
Mature Libraries: C++ has a treasure trove of well-established libraries. For niche or legacy needs, C++ might be your only option. Performance Control: When you need to micro-manage performance, C++ gives you the nitty-gritty control that can make all the difference. Industry Norms: In some fields like game development, C++ isn't just preferred, it's expected. Sticking to industry norms can sometimes outweigh the benefits of newer tech. So, while Rust has its perks, especially around safety and concurrency, C++ still holds its ground where its deep-rooted ecosystem and granular performance control come into play.
>> is there ever a case for doing a project in C++ (outside of being forced by the platform you’re working on or anything outside your control)?
No.
That is part of the reason why so many big companies (Google, Microsoft, Amazon, etc.)[1][3][4] are pushing ahead on Rust adoption and large government agencies[5][6] are recommending memory safe languages over C and C++.
Google did a study and found that their Rust developers were twice as productive as their C++ developers [2].
Rust should be preferred over C++ unless you have no other choice.
[1] https://thenewstack.io/google-spends-1-million-to-make-rust-...
[2] https://www.theregister.com/2024/03/31/rust_google_c/?td=kee...
[3] https://www.theregister.com/2024/01/31/microsoft_seeks_rust_...
[4] https://blog.qwasar.io/blog/why-is-rust-growing-and-why-do-c...
[5] https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...
[6] https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-...
No.
That is part of the reason why so many big companies (Google, Microsoft, Amazon, etc.)[1][3][4] are pushing ahead on Rust adoption and large government agencies[5][6] are recommending memory safe languages over C and C++.
Google did a study and found that their Rust developers were twice as productive as their C++ developers [2].
Rust should be preferred over C++ unless you have no other choice.
[1] https://thenewstack.io/google-spends-1-million-to-make-rust-...
[2] https://www.theregister.com/2024/03/31/rust_google_c/?td=kee...
[3] https://www.theregister.com/2024/01/31/microsoft_seeks_rust_...
[4] https://blog.qwasar.io/blog/why-is-rust-growing-and-why-do-c...
[5] https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...
[6] https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-...
Yes, this is all very interesting, I've found golang is significantly simpler to get up to speed on from a c-family based education (c/c++/java) so I'm curious if these teams were both proficient before starting the projects. (And 3rd party package comparisons come into play). Either way enough to keep an ear out as I'm sure with the wealth of python & js developers the language of choice will be promoted by their experiences/evolution (so suspect mojo will also be something to keep an eye on)
(Notably I've gone through this evaluation recently and landed on implementing my personal project in c++23 (using cosmopolitan if possible) mostly for the value of updating my c++ knowledge (and perhaps look into cuda))
(Notably I've gone through this evaluation recently and landed on implementing my personal project in c++23 (using cosmopolitan if possible) mostly for the value of updating my c++ knowledge (and perhaps look into cuda))
>> I've found golang is significantly simpler to get up to speed on from a c-family based education (c/c++/java) so I'm curious if these teams were both proficient before starting the projects.
Coming from a similar background, I have found Golang to be a nice, more efficient replacement for Java because it works great for backend web services, middleware, etc. Go is easy to learn and brings most of what is needed in its standard library (similar to Java).
Rust's sweet spot is where C and C++ shine: performance critical, maximum efficency required software such as operating system components, device drivers, media applications, etc.
Rust does have a learning curve, but most of what it enforces are best practices: 1) multiple readers or one writer resource usage, 2) organizing code hierarchy into trees, 3) sane patterns for concurrency, etc.
Coming from a similar background, I have found Golang to be a nice, more efficient replacement for Java because it works great for backend web services, middleware, etc. Go is easy to learn and brings most of what is needed in its standard library (similar to Java).
Rust's sweet spot is where C and C++ shine: performance critical, maximum efficency required software such as operating system components, device drivers, media applications, etc.
Rust does have a learning curve, but most of what it enforces are best practices: 1) multiple readers or one writer resource usage, 2) organizing code hierarchy into trees, 3) sane patterns for concurrency, etc.
Go is great, but it has garbage collection (you don't manage memory directly) whereas c++ and rust do not.
It is apples and oranges, in that regard. Some node guy isn't going to just go and pick up rust/c++ because they're used for quite different purposes.
As a general purpose language, Go is amazing. In fact, it is what I use day to day for all my needs. For my current business needs it is what all our services are written in. They are fast, and the go concurrency model honestly makes it pretty easy for me to forego a lot of extra add-on technologies that are not yet required at my stage and KISS.
For anything like super high perf, systems programming, embedded, etc. you will want to use c++ or rust.
It is apples and oranges, in that regard. Some node guy isn't going to just go and pick up rust/c++ because they're used for quite different purposes.
As a general purpose language, Go is amazing. In fact, it is what I use day to day for all my needs. For my current business needs it is what all our services are written in. They are fast, and the go concurrency model honestly makes it pretty easy for me to forego a lot of extra add-on technologies that are not yet required at my stage and KISS.
For anything like super high perf, systems programming, embedded, etc. you will want to use c++ or rust.
Thanks for all the sources! Especially surprised on the Google one, used to work there and remember hearing that considerable parts of Fuchsia (https://en.m.wikipedia.org/wiki/Fuchsia_(operating_system)) were written in Rust but didn’t know they were also conducting studies across the org about how much more productive eng were with it. Pretty cool
If your project depends heavily on general purpose GPU programming, you might start one in C++.
This was the case for a project I am working on that was started in the last year. The interop features in rust (and other languages) are simply not as reliable as writing kernels directly in CUDA or HIP or even DPC++. You _can_ attempt to write the GPU code in C++ and call to this from $LANG via ffi, but if you want to preserve data structures and methods to work on both the host and device, its still easier to write it once in C++.
This was the case for a project I am working on that was started in the last year. The interop features in rust (and other languages) are simply not as reliable as writing kernels directly in CUDA or HIP or even DPC++. You _can_ attempt to write the GPU code in C++ and call to this from $LANG via ffi, but if you want to preserve data structures and methods to work on both the host and device, its still easier to write it once in C++.
I concur re not being able to share data structures. I've been using `cudarc` for FFI (Shaders in C++; CPU code in rust), but that would be a nice perk.
Rust doesn’t even have a real GUI library yet, let alone support from common game libraries. C++ supports a hundred times as many compilation targets and platforms.
>> C++ supports a hundred times as many compilation targets and platforms.
I would not want to be the one writing that CMakeLists.txt
I would not want to be the one writing that CMakeLists.txt
If you are hardcoding anything platform related into your CML, you are doing that wrong. The default path must not be anything other than build and usage requirements. To support more usecases with CMake, you have to write less of it.
Games would probably be the biggest, most common scenario where C++ isn't going anywhere any time soon.
More generally, if you need to use existing C++ or even C libraries, Rust is at best an awkward fit unless someone else has already built and is actively maintaining the necessary bindings.
More generally, if you need to use existing C++ or even C libraries, Rust is at best an awkward fit unless someone else has already built and is actively maintaining the necessary bindings.
https://tauri.app seems to be fine.
I agree that the gaming industry is a place where starting a C++ project still makes sense.
I agree that the gaming industry is a place where starting a C++ project still makes sense.
EGUI. (I agree with you on lack of games libs)
You do not think Iced counts yet?
I've personally stumbled upon two - obscure hardware and GUIs.
It's really difficult to evaluate a hardware product with only a C(++) SDK using only Rust. There are of course ways around this but those are a significant amount of effort.
In terms of GUIs - there's simply no "Qt-Rust" that would work in a Rust-y way without causing massive headaches. Handling all that state is incredibly difficult in Rust, at least for me (but I recall others describing why as well).
It's really difficult to evaluate a hardware product with only a C(++) SDK using only Rust. There are of course ways around this but those are a significant amount of effort.
In terms of GUIs - there's simply no "Qt-Rust" that would work in a Rust-y way without causing massive headaches. Handling all that state is incredibly difficult in Rust, at least for me (but I recall others describing why as well).
Did you get a chance to check https://slint.dev?
Disclaimer: I work for Slint
Disclaimer: I work for Slint
I like it in theory but the small demos I've played with lack a lot of the details that GUI toolkits have converged upon. Small behavioural things ingrained in usage patterns that have to be reimplemented.
First two that come to mind are tab/shift-tab navigation and being able to adjust sliders roughly with arrow keys.
First two that come to mind are tab/shift-tab navigation and being able to adjust sliders roughly with arrow keys.
[deleted]
From Chandler Carruth who leads the C++, Clang, and LLVM teams at Google:
https://github.com/carbon-language/carbon-lang/blob/f9ce0b19...
https://github.com/carbon-language/carbon-lang/blob/f9ce0b19...
“Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should. Unfortunately, the designs of these languages present significant barriers to adoption and migration from C++.”
Hadn’t heard of Carbon, very cool. Super telling line with the “Developers that can use one of these existing languages should.” Thanks for sharing!
Hadn’t heard of Carbon, very cool. Super telling line with the “Developers that can use one of these existing languages should.” Thanks for sharing!
Existing base of experienced developers
If you spent 10-20 years writing C++ and all of the code you interact with is written in C++ and all the libraries you are calling are C++, why would you write in Rust?
Haven't really dived into Rust yet because its syntax looks a bit ugly to me. But yeah if I have to choose between Rust and C++, I would be happy to try Rust if there is a library/framework in Rust that does a better job.
[deleted]
If I had complete freedom to choose, I'd choose C++ simply because I find programming in Rust to be very unpleasant.
I would use it for cross platform native ui development with wxWidgets
Because for a particular rust file, you need a particular conpiler version ? /s
Does Firefox compile with the shipped rust compiler ?
Does Firefox compile with the shipped rust compiler ?
The best way to think of Rust as essentially the new Java, which sort of "won" over C++ due to its more strict syntax with mandatory OOP and code patterns. Rust enhances this by running most of the checks in the compiler so you get native code, with very few runtime additions for type safety.
But just like Java, its almost useless to code in it for personal or smaller projects.
For almost all of my projects where I needed performant code, the way I would do this is write it in C, and then just call the code from Python or Node. Its much easier to just focus on low level performant C code that can be written in usually one file, and then just write all the interface to it through higher level languages, especially for web frameworks.
But just like Java, its almost useless to code in it for personal or smaller projects.
For almost all of my projects where I needed performant code, the way I would do this is write it in C, and then just call the code from Python or Node. Its much easier to just focus on low level performant C code that can be written in usually one file, and then just write all the interface to it through higher level languages, especially for web frameworks.
> But just like Java, its almost useless to code in it for personal or smaller projects.
That's entirely the opposite from my experience. Rust is a pleasure to code in for personal projects once you're familiar with the language, especially compared to C/C++. Managing dependencies is more straightforward, and there are a lot of crates out there to make writing your project easier.
That's entirely the opposite from my experience. Rust is a pleasure to code in for personal projects once you're familiar with the language, especially compared to C/C++. Managing dependencies is more straightforward, and there are a lot of crates out there to make writing your project easier.
You and I must have different ideas of "pleasure to code." The appeal of Computer Science for me is learning how things work at a deeper level, tracking every bit and byte, and pushing performance to its limits. The pleasure is in writing the interesting libraries, not gluing them together. Any technology that restricts me has zero appeal.
It honestly depends on what you work on for your argument.
In general, think about the general use case for all types of development. For example, I have a bunch of finance code. I host it on a Jupyter Lab server in notebooks, so I can run/edit it from anywhere.
If I want something that is fast (which in this case is rare to see outside of using pytorch), I can write a C extension quite easily - the amount of effort that it takes me to set up boilerplate code is the same amount of effort as it takes thinking about Rust memory semantics. The code will be quite isolated from the rest of the system (unless you purposefully try to break Python), and you don't really have to even do dynamic memory if you are trying to do processing. I did this at work with fast json parsing and data extraction, and it was super easy to do.
Then there is the whole ML aspect, which is first and foremost python before anything else. Especially in the whole data sets, with the fact that you can easily generate training data in Python, whereas other languages require a lot of custom code.
In general, think about the general use case for all types of development. For example, I have a bunch of finance code. I host it on a Jupyter Lab server in notebooks, so I can run/edit it from anywhere.
If I want something that is fast (which in this case is rare to see outside of using pytorch), I can write a C extension quite easily - the amount of effort that it takes me to set up boilerplate code is the same amount of effort as it takes thinking about Rust memory semantics. The code will be quite isolated from the rest of the system (unless you purposefully try to break Python), and you don't really have to even do dynamic memory if you are trying to do processing. I did this at work with fast json parsing and data extraction, and it was super easy to do.
Then there is the whole ML aspect, which is first and foremost python before anything else. Especially in the whole data sets, with the fact that you can easily generate training data in Python, whereas other languages require a lot of custom code.
Interesting, haven’t heard this viewpoint before of Rust being a drop in replacement for Java. From my limited experience with Rust it felt like the learning curve was way steeper than when I was learning Java for my previous job. Good point on C though, one of my old CS instructors would always call C his swiss army knife since its so small he had practically the entire syntax in his head.
Rust is not a drop in replacement right now in the sense that it does require more learning curve, but for example if colleges switched to teaching everything in Rust, then you would see its use on the same level as Java.
OP never said rust was a drop in replacement for java
I think the notion of that comment is Rust is the new "new C++".
This reads like having no more than passing familiarity, and no real experience with rust.
It (just like so many other languages) is fantastic for personal projects. Especially because you can target cross platform easily and get native performance.
Proclaiming any non-estoteric language is "almost useless to code in for personal or smaller projects" speaks volumes.
It (just like so many other languages) is fantastic for personal projects. Especially because you can target cross platform easily and get native performance.
Proclaiming any non-estoteric language is "almost useless to code in for personal or smaller projects" speaks volumes.
> But just like Java, its almost useless to code in it for personal or smaller projects.
I seem to be writing an OS with it just fine.
I seem to be writing an OS with it just fine.