Ask HN: Learn C++11 or Rust in 2022?
Python/Golang/C (ye, C) day-to-day job here.
I am interested in either updating myself on (C++11>) or going the Rust way. I see a lot of criticism/hate of C++ lately (mostly due to the comittee), but the tooling and libraries are there for multiple areas.
Rust is also interesting to me from a security standpoint.
So I don't really have time to invest in both languages; any directions?
160 comments
[ 3.7 ms ] story [ 257 ms ] threadBut—also learn Zig in addition to Rust.
Having seen first-hand how so many threat vectors these days are now supply chain attacks, having reported CVEs and earned P1 bounties in memory safe languages, and having worked on static analysis systems to detect zero day exploits—I'm also impressed by Zig's overall approach towards safety, as being more than only memory safety.
For example, this comes through in Zig's extreme simplicity and explicitness, and also how Zig enables checked arithmetic by default for safe builds. For people who haven't worked in security, integer overflow and wraparound may seem like small things, but they increase the probability of exploits such as buffer bleeds, i.e. attacks like OpenSSL's Heartbleed, which are often remotely accessible and easier to pull off than a UAF.
In fact, no language is 100% memory safe, i.e. able to prevent a memory buffer bleed, because these are logic errors with respect to the protocol. However, explicit control flow and checked arithmetic do help to close semantic gaps and minimize ambiguity, which is what good security comes down to.
Of course, Zig only offers spatial memory safety, and not temporal memory safety like Rust. So Zig is more memory safe than C, and less memory safe than Rust or JavaScript. Nevertheless, Zig is safer than Rust when it comes to being able to handle memory allocation failure.
Again, Rust's borrow checker is also valuable for concurrency safety, i.e. for multithreaded systems, but if you're using io_uring for fast I/O, then multithreading is less of the necessary evil that it used to be a few years ago.
Zig is something you can pick up in a week, with state of the art tooling, and fantastic C-ABI interop for libraries.
So... learn both!
> For example, this comes through in little things like Zig's extreme simplicity and explicitness
"Simplicity" does not mean safety. In fact simplicity means you can't describe hard problems easily without being overly verbose, which means more code and more attack surfaces. Problems are what can be simple or complex. If your language advertises "simplicity" it just means it can't solve complex problems in straight forward ways. Zig is just repeating the mistakes of C++ as well as all the mistakes of Go.
> or people who haven't worked in security, integer overflow and wraparound may seem like a small thing, but they increase the probability of buffer bleeds, i.e. attacks like OpenSSL's Heartbleed, which are often remotely accessible and easier to pull off than a UAF.
Zig does exactly what Rust does in this case.
> In fact, no language is 100% memory safe, i.e. able to prevent a memory buffer bleed, because these are logic errors with respect to the file or protocol format.
What are you trying to argue here? Buffer bleeds can't happen in safe rust.
> The borrow checker is obviously great for multithreaded systems, but if you're using io_uring for fast I/O, then multithreading is less of the necessary evil that it used to be a few years ago.
Syncronization is a problem in any kind of multitasking. Whether that happens inside or outside the language is the only question. The OS can have all the same problems your code can have. https://mobile.twitter.com/axboe/status/1505335772706091011 Also io_uring assumes you're only ever writing for Linux.
> Nevertheless, Zig is safer than Rust when it comes to checked arithmetic or being able to handle memory allocation failure.
This is simply incorrect. Most of the problem with unchecked overflow is for buffer overflows, which are fully caught. Rust gives options to handle memory allocation failure if you want to handle it. Generally though for most applications simply crashing is completely fine.
Thanks, I've tried to clarify that Zig provides spatial memory safety but not temporal memory safety, so hopefully it's less confusing.
> "Simplicity" does not mean safety.
Ceteris parabus, complexity breeds bugs and simplicity improves the probability of safety. For example, if I were auditing a piece of code for security, I would prefer the simplest correct program to the most complex correct program. Reduced surface area means reduced area for attack.
When I say that Zig pursues simplicity, I also mean this as high praise, that Zig is highly "orthogonal". In other words, able to solve difficult problems with a minimum of overlapping features. For example, Zig's comptime gives you generics, but also gives you so much more, plus there is also type safety throughout Zig's comptime, yet it eliminates the need for macros, and is more versatile, powerful and flexible at the same time. It's incredibly elegant. Nothing left to add, nothing left to take away.
> Zig does exactly what Rust does in this case.
Things like checked arithmetic matter and should be enabled by default in safe builds, yet Rust does not actually do this in safe release builds. Zig does and I hope that Rust one day will.
> What are you trying to argue here? Buffer bleeds can't happen in safe rust.
By definition, buffer bleeds can in fact happen in safe Rust. The borrow checker can protect against UAF and overflow, but the borrow checker can't protect against all kinds of underflow, which is what a buffer bleed is. You can even pull them off in JavaScript.
No language is actually 100% memory safe, not with respect to buffer bleeds.
First of all, that's security, not safety. Lots of software exists in an environment where it isn't going to be attacked.
> Things like checked arithmetic matter and should be enabled by default in safe builds.
Rust offers actual checked arithmetic - for example, suppose I have a 32-bit signed integer (i32) and I want to add something to it, in Rust I can choose the most appropriate of:
add - also presented as the + operator, in debug this will panic on overflow, but in production I can choose, either panic or just have it wrap silently
checked_add - at runtime check for overflow and get either None or Some(i32)
overflowing_add - this time instead of Option we get a pair back, with our (wrapped if necessary) numeric answer and a boolean saying if we overflowed
saturating_add - addition saturates at the minimum and maximum thresholds
unchecked_add - even in debug builds this is not checked (yes it's unsafe)
wrapping_add - this performs the most likely native hardware behaviour, wrapping numbers around at the limits
You might also realise your variable should inherently have certain arithmetic, for example a 16-bit PCM sample should always have saturating arithmetic (getting this wrong is one reason badly written older audio software can sound bad) so you can make them Saturating<i16> or maybe you actually want wrapping arithmetic on the simulated 32-bit CPU registers in your Motorola 68000 simulator, so you use Wrapping<u32> for them.
The debug behaviour for the trivial + operator is not intended to be your best defence, if you're sure you want wrapping, write that down, if you're sure you want to check, write the check. But sure, if you somehow want your release code to panic, but don't want to write the panics out by hand, you can tell the compiler you want this in release builds.
> By definition, buffer bleeds can happen in safe Rust.
Nope.
> The borrow checker can protect against UAF and overflow, but it can't protect against all kinds of underflow
And it doesn't, in safe Rust the actual bounds checks are emitted, and they only get elided in most cases because in idiomatic Rust it's clear to the compiler that the checks are unnecessary (e.g. iterating over items in a vector, the compiler knows how long the vector is, and it can see we're starting at the beginning and stopping at the end, so, we don't need the bounds check and it won't actually be emitted in the machine code). thing[index] is bounds checked in safe Rust.
> No language is actually 100% memory safe, not with respect to buffer bleeds.
Many languages are 100% memory safe. Most fascinating here is WUFFS which - in exchange for its restricted purpose - gets to be both entirely safe and faster than the C (or C++, or Rust) you'd actually write.
You literally can't write a "buffer bleed" type goof in WUFFS. I don't mean "You won't because it's so easy to get it right" or even "It will warn you about the problem at runtime so you can fix it". I mean code which can exhibit that bug does not compile.
I use the terms interchangeably on purpose, because safety and security are really two sides of the same coin. In the past, I've worked in security and I now work in a domain where safety is critical. It's my experience that the two fields have considerable overlap.
We can always get better at interdisciplinary sharing of knowledge.
The entire origin of unchecked arithmetic being a problem originates from their use as indexes to buffers. If you solve the indexing buffer issue you don't need to completely expand every single mathematical operation to a checked one which slows down the code. If people want checked artihmetic for some reason in the rare case that it matters in a non-buffer case, then they can used things like checked_add.
Hence simplicity is not a desirable goal. We need to create complex languages so that fewer people can understand and use it in a few projects and write very less code. Less code means less bugs. ‘Complex’ is the way to go. /s
Zig enforces correctness much more than C or C++ does (e.g. no implicit 'lossy' conversions, much stricter and enforced error handling, no implicit null, etc.), so it's completely fine to say that Zig is much safer than C or C++.
The main difference between Zig and Rust is the borrow checker, but a lot of memory corruption issues in C and C++ are "second order effects" of sloppy code which would be caught in Zig either at compile or runtime.
The General Purpose Allocator can optionally catch use-after-free by not recycling virtual memory addresses, not very efficient for small high-frequency allocations of course, but then Zig isn't an OOP language either (where it would be common to create and destroy massive amounts of tiny objects).
Exactly, which begs the question why bother with Zig at all.
Maybe someone proves me wrong with some killer application that makes Zig unavoidable for the rest of us.
Stick to C++ or Rust, which I won’t weigh in on here. But both are much more mature.
That said, there are at least three stealth-mode SaaS companies I know of betting on Zig for their performance sensitive / low-latency software. Where I work, we're tracking Zig's nightly build and follow/contribute to Zig progress and stability roadmap.
Zig hits a sweet spot between C and C++. It feels really nice to work in -- in a way that many people describe Go. I think Zig is a very attractive option for allocation sensitive programs like games, audio, or purpose-built data stores. Give it a look and decide for yourself.
From a practical perspective, if you're short on time and want a return on your investment, C++ will open up more opportunities on the job front.
Yes, you can get that last cycle of power from a piece of hardware by going with C or C++, but on the other hand finding people who can do that is time-consuming and expensive. And in many cases eventually not worth it.
"C++" is such a big concept toi grasp fully, that I don't see the point of studying it unless you're getting paid for it.
Programming languages are like actual languages, after you know the first two or three, the fourth one isn't that much of a hassle (there are exceptions of course).
I didn't know crap about C# when I started my current job, but I did have a decade of Java under my belt. Took me about a day to figure out the basics. Ifs and switches and functions and classes are the same everywhere.
If I would've had to study something like Haskell or Scheme, it would've taken a bit longer.
So e.g. you hire a bunch of fresh graduates who've learned some programming maybe Java and Python, and maybe have other expertise you value (e.g. maybe they're aerospace engineers and you write control software for jet engines) and you spend money hiring somebody capable to stand at the front and teach them how to write C++. It's their job to learn this, so you can do it pretty intensively, e.g. lecture slot / exercises / break / repeat.
C++ is a big sprawling language, but you can make a good start on them in two weeks.
You've presumably worked somewhere with at least some onboarding or spin-up time. Somewhere you weren't employee #1 and responsible for buying your own stationery and cleaning the toilet ? What did you do on day one? Fire training? How to use the CI system? Anti-bribery? Getting your photo taken for an ID badge? Maybe some "easy" first tasks just to learn your way around the systems?
If you have a job where you turn up on day one and are just as productive as a long haul employee, I have terrible news for you - you are the most replaceable person in your organisation and you are going to get fired.
This is simply not true. Examples of major software that is being actively developed:
- Lots of compilers/runtimes (gcc, LLVM (which Rust builds upon), Java/JDK/JVM, Swift, node.js) - All major browsers and browser engines (Chrome/Chromium, Firefox, WebKit) and thus Electorn - Lots of rich client applications using either some Windows API, or something like Qt, or Electron (JS + C++) - Major game engines such as Unreal, Frostbite, CryEngine - Major OS'es graphics API build upon C++: Microsoft's Direct3D, Apple's Metal
And this is completely ignoring the embedded world, where C++ competes at least at some higher level with C.
All of this requires C++ engineers.
The amount of people actually _making_ compilers and runtimes is multiple orders of magnitude smaller than the people using them.
Same with browser engines and game engines. For every coder doing the actual engine, there are a hundred others just using the engine, not touching C++.
You did list a pretty substantial portion of the segments where C++ is a valid choice and in many cases (along with C) the only option.
In any case, the point was that those that know how to repair the gearbox must come from somewhere.
Not really necessary to grasp the entirety of the language to use it effectively, I dabble in C++ here and there and usually treat it as a fancy C just using stuff like smart pointers, strings and vectors. Even learned some C++17 stuff which made what I was trying to do a lot simpler though I can’t remember what I was up to, think it was some boost lib I was already using that got promoted or std::variant shenanigans with my asdl generator — definitely yaks were being shorn I can say for sure.
If you have a long time horizon, Rust is the safer bet, if you want a job fast, C++ has probably more job offers.
At the moment I just write bits in C whenever I need it but when it scales in a decent size I would just write the whole thing in C++/Rust
Honest question as I'm not a C++ developer: Even with all the new C++17/20 stuff?
All the things Rust advocates insist cannot be done safely in C++ are now trivial. Use-after-free, leaks, buffer overruns, what-have-you, no longer need any attention to avoid if you stick to modern C++. Some people insist on coding as if it were C, and bring along all of C's failings. Leave them behind.
Those people that insist on coding as if it were C are still a very big group across the industry.
C++'s problem is that most people never learn it properly and think "C/C++" is a thing because most courses/tutorials are stuck in the 90s and effectively teach shitty C with classes and iostream. Rust is great and has really nice features which I'd like to have in C++ too (like pattern matching) but memory safety is really not an issue in proper modern C++. I'm aware that this is a bit of a "you're just holding it wrong" but pretty much all languages have things you shouldn't do anymore once they evolve, it's just more obvious in the one with strong backwards compatibility requirements to the ancient language created before all the modern research into language design.
I mean, maybe. Or maybe it gets replaced by something else.
So first learn Rust, later learn C++11+ (by the time there will be a successor of C++11 that may look even less like the C++ you know).
Learning Rust will develop your thinking and taste, and this will then help you judge the flavour of C++ that you will be learning later (and because you'd update your C++ skills later, you may skip another C++ legacy flavour in the process).
C++ I find can get a little unwieldy quite fast, but is generally easier to keep simple. It maps to higher-level concepts in easy and intuitive ways. Rust, I hate to say it, but unless you know best practices / idiomatic Rust from the start, you'll have to do a lot of refactoring as you learn the language. Some constructs simply aren't possible using safe Rust. Many embrace the limitations, many else frustrate themselves again and again until 'the Rust way' drills into their heads. But, of course, once you get a feel for it, it's pleasant to write in.
How much difficulty you'll have with Rust or C++ depends on what problems you try to solve, and what your approach to programming is generally. If you're more of a pragmatic "I write simple programs that actually do things" I don't think you'll have any problems with Rust. It's very straightforward. And the tooling is second-to-none. If you like to partake in exploratory programming, trying out different theoretical models and different abstractions, C++ caters to that by allowing you to write more elegant designs than in Rust, with the downside that it also lets you make worse mistakes.
The wider cross-language library ecosystem is mostly C-based I've found, so, in C++ you can just use those libraries directly with no hassle (the only hassle being the build system, or lack thereof). Rust can use those libraries as well (as long as you don't have a gut-reaction "ew" to using `unsafe` everywhere) but unfortunately the safe and idiomatic Rust library ecosystem is kind of on the bleeding edge at the moment. Hopefully things will stable out soon, and all these hip new technologies will come to fruition, but that day is not today.
I know this isn't really nudging in one way or another but really it comes down to what you value in a language and what projects you want to see through using these technologies that will determine which one you like better. Have fun!
This seems like a weird statement. Yes, C++ has a load of features you can't express in a C API. But so does Rust! Yes, Rust can produce and consume libraries with a C API. But so can C++! They're in pretty much identical positions here, aren't they?
It's true that serde is great, and C++ doesn't have an equivalent (AFAIK). But C++ does typically have excellent piecemeal support for popular serialisation formats.
I’m actually surprised that the general consensus isn’t rust as that’s the new shiny plus the people saying C++ are giving very valid reasons beyond the usual language dogma arguments that these discussions usually devolve into.
As you say I wanted to know how's the scene at the moment; I am very disconnected from how they have both evolved and their future (mostly because what I see is hate to C++)
Rust is less expressive than C, but likewise it does give less chances to shoot yourself in the foot.
C++ is often derided for its complexity, arising from its long development. While it's true that C++ allows many wrong ways to do something, I don't think that should really be a problem. The language's main problem is societal: C++ (and C) is often used by people who haven't bothered to learn the language. E.g. one can't rely on random unknown C++ code handling integer overflow and type punning correctly, so in such cases it's wise to compile with
A part of the problem is that C/C++ is so traditionally established, it's taught as as an introductory language at universities, for example. But it's usually taught wrong, because there's no incentive to teaching it right, and trying to teach it right could in fact be counterproductive, if the goal is merely to introduce someone to programming. This is why I think it would be best to teach Python or Julia as the introductory programming language, and (modern) C++ only afterwards.Rust's advantage in this regard is that it's more centralized, it's lead by a foundation instead of being standardized, so everyone who learns Rust, learns the one, correct way to do things.
My idea is to either C++20 (not sure if there is a resource to learn directly from C++20 or if there are compilers supporting it) or Rust, personally I would go for C++ seeing as there's a wider ecosystem and tools out there, lots of libraries (which are a bit of a pain to use sometimes) and it is almost anywhere.
But to be fair, I am out of the loop of C++/Rust and what I see in my internet circles is Rust > C++ mostly because of the memory safety; which makes me wonder if it is worth or not; also lots of C++ hate which reminds me of PHP.
I just have a hard time making decisions.
EDIT: Ah yes, the "crawww C is unsafe, use rust crawww!" downvote crowd is out in full force today.
P.S. I haven't downvoted you.
Is C++20 support in compilers already? MSVC/GCC/Clang
Unlearning bad C habits is hard because the language accommodates them for as long as you continue to cling to them. You need to consciously decide you will use the new, better way. Once you have done each once, there will be no temptation to backslide.
Heap allocated data is one special case of OS resources that can be managed by constructor/destructor pairs.
Learning C first is a very bad way to learn C++. One can pick up pointers later, and asm blocks after that.
It's like the "I know React but not JavaScript" crowd all over again.
RAII is about resource management, regardless of where those resources live on.
Heap allocated, OS handles, indexes on a fixed sized buffer, network sockets, ...
Again, what did being pedantic prove here? You clearly understood what I meant.
For Cloud Native stuff, Rust might be a better option, specially due to the security focus.
With C++ you'll have more offers, but you are more likely to be unsatisfied with your job: in large corps you'll usually have to untangle lots of messy legacy codes; while in start-ups things are more likely to be done quick and dirty and the flexibility C++ provides doesn't make it any better.
With Rust unless you are in the US, it's gonna be extremely difficult for you to find an opportunity; even in the US I gather there are not many chances and I _guess_ recruiters would expect higher proficiency as Rust is known for its steep learning curve.
In the future, those codebases will only be the legacy ones and you will end up doing more maintenance with C++.
With Rust your investment of today will pay off in a few years.
Deciding what to learn today is an investment decision and you should look into what you think the future will look like. To me it looks Rusty. :-)
Going to rust directly has been a very frustrating experience and made me give up.
Instead I spent time learning C++, I found out I could more easily transfer my knowledge/skills there. Once you become more proficient with the basics you learn about move, copy, smart punters, ownership, etc.
After some point you start to notice that you are basically doing in your mind exactly what a borrow checker enforce. So that made me curious and I tried rust again, and this time everything made complete sense and the language has been incredibly refreshing to work with.
This intermediate state was very useful for me to build my mental model and develop a better intuition, C++ made it simpler to do it in a more progressive way. And Rust is a fantastic langage if you can wrap your mind around it’s semantic and learn to work with the borrow checker.
IMHO, you could learn Rust as a first PL by treating it as a functional programming language with a focus on purity, like a twist on ML or F#. The borrow checker rules and things like the String/&str distinction follow naturally from that POV. Then learn how "interior mutability" is used to enable more C-like procedural programming with shared mutable state.
I like C++ and my main caveat is that you don't just write C++. You also have to get good at tools like Valgrind and develop a deep intuition and understanding of what the language does under the hood. That's going to require a significant time investment and some people just don't have the right energy for it.
Nowadays the only reason I would learn C++ instead of Rust would be if I wanted to benefit from the much bigger C++ ecosystem, for example to build a game engine from scratch.
soo... tooling ? how is that different from using valgrind ? it's literally one click in my IDE to use it and it will show e.g. the time spent at each line of code directly in it.
> If you use Python and JS chances are you do some form of web development, where most performance issues have to do with I/O, and most of those I/O issues are caused by bad queries.
I don't know about this, what I know is that multiple times in my career I had people come at me with python software that was slow, and transliterating them almost line by line to C++ made them much, much, much faster.
Also I have all these apps on my system which apparently depend on python, none of them being a web app:
incidentally, my day to day experience definitely does not classify any of the software I actually use in the "fast and enjoyable" category, except zim and tellico. Like, just launched a couple that I had forgotten about: solaar, a GUI for configuring logitech mice, and thonny, a minimalistic IDE for arduinos, etc. and they take actually observable time to start, on a 1k€ CPU, which I really find to be entirely ridiculous (and made me remember why I don't use them more).Rust is probably a better bet for web-related things. There is not much C++ there, and Rust seems to get some popularity. After all, Rust was originally made for Firefox.
For more industrial applications, or game dev, C++ is likely the way to go. Where I work, we do a lot of industrial applications and we have a lot of C++ projects, including new ones. Rust is not even on the radar. [Edit: C++ here is mostly C++11 now, with some C++98 and not much C++14 and later, I expect that we will get to C++17 soon enough but C++20 probably has a long way to go]
Forget about the criticism/hate of C++ and hype of Rust, it has little to do with practical applications.
Also, if you're already fluent in another imperative programming language, it shouldn't take more than one or two weeks of a few hours after work to get an initial grip on both languages and decide whether you like them or not.
Personally, I find both languages equally frustrating for 'spare time stuff' (for different reasons though) and prefer simpler languages like C, Zig, Go, Python or Typescript (depending on the problem at hand).