Ask HN: Should I learn C/C++ or Rust as my first systems programming language?
I work as a data scientist in telecommunications. Mainly, I used python and matlab, but I want to extend my programming range to include a compiled, systems language because lots of digital signal processing is written on embedded devices.
To me, it seems Rust is so much better than C/C++ in many ways: lots of Python-like abstractions, rigid compile time safety checks... A modern language designed from scratch without a hodge podge of welded on features.
Rust could also turn into something big, by the looks of it, in the next 10 years.
So I have two questions: how much does it make sense for me, in my circumstance, to learn Rust as my first systems language, and the second question is how much, in general ignoring my circumstances, does it make sense to learn Rust first?
82 comments
[ 3.9 ms ] story [ 192 ms ] threadExample, all the answers that tell you to import jquery.
Most people pick up the new features a little at a time by reading blog posts or watching conference presentation videos. An hour or two a week, over as many weeks as you need, gets you up to speed fast enough.
Learning just C/C++ is also completely fine, so don't think it is a waste of time or anything like that, both are not going to go anywhere and having them on your toolbelt will help even if you do decide to go with Rust in the future.
Spend some time with C and learn the basics, do some experiments, and then learn Rust concurrently. It's not like you have to pick one or the other. You can be proficient with C while still becoming more fluent with Rust over time.
So, either choice is not wrong.
C and C++ are clearly different programming languages, so you are actually looking at three languages.
> Rust could also turn into something big, by the looks of it, in the next 10 years.
I wouldn't bet on that. 20 years ago, I heard Haskell and or Java is going to be huge. They are, C and C++ still are. Learn Rust by all means, probably you will be more quickly productive, and it gives you a wide range of choice of targets. That should be sufficient reasons to go that way.
> To me, it seems Rust is so much better than C/C++ in many ways: lots of Python-like abstractions, ...
Yes, but that is also an argument to go for either C or C++. You'll have to learn more. The active code-base in C and C++ is huge, and I don't see everything being rewritten in Go and Rust. Maybe you'll be less productive in churning out code, but it'll give you expertise to look and modify the existing code-base when necessary.
Not that you cannot do that when learning Rust.
In summary, I would go, with Rust, if you want to be quickly able to do your own stuff, C or C++ if you want to be able to work through existing code build "with a hodge podge of welded on features". The deciding factor between C and C++ again should be then, in what language is the code written you'll be looking at. I would say, (and others might disagree) kernel-code (OS kernel, that is), Microcontroller, low level stuff more likely C. C++ you'll find more likely in application code, numeric libraries, etc..
[0] https://github.com/rust-lang/rust-bindgen
[1] https://github.com/dtolnay/cxx
You certainly will also gain that proficiency simply by learning Rust to some degree, but I think it helps to have written both C and C++ to be more fluent.
If that is necessary greatly depends on your needs. I rarely had to modify or read the actual code of libraries I used, but when I had to, I am not sure how I could have solved the problem otherwise. For me it is sometimes quicker to read the code, than treating it like a black-box and trying to figure out what is supposed to happen by often outdated documentation and examples.
If you have memory safety issues in Rust, it just won't compile (with extremely to-the-point compile errors). In C/C++, you might have to debug for a while (especially if you're new) as to why your app is inexplicably misbehaving.
Especially if you're interested in embedded applications (and probably otherwise as well), I would suggest learning C to start with. Whether to go for Rust or C++ after that is up to you.
I agree with this, but the poster didn't explicitly want to learn C++ or Rust, they wanted to get into systems programming (specifically mentioning "embedded").
I've read my fair share of "C in C++", but in my experience these issues come from people who started out programming in C (or Fortran) for a long time before trying other languages. I don't think it's going to be a major issue for someone with a background in Python.
EDIT: and to add... I would love to trade all the "Java in C++" I've had to deal with for additional "C in C++".
The easiest way to spot Java Disease nowadays is seeing shared_ptr. Good C++ code will have very few uses of shared_ptr, usually none.
C and C++ are really different languages these days. They share some syntax, but the ABIs and underpinnings of each are radically different. Their relationship these days is that of an estranged cousin: you are familiar with how it looks, but it is really not at all what it looks like anymore. Once the two languages shared dressing styles, but now, C++ has all these rebel < and > in places it should'nt. :)
You will pick up bad habits that many people have never managed to shake, and that make for bad C++ and even bad Rust.
If you come from Python you'll have a shock when you see how little one line of C will get you. C++ and Rust don't suffer from this problem. You can go really low level, but you can also build abstractions and perhaps more importantly use existing ones.
I have only dabbled with Rust (I use C++ professionally), so I don't have a strong opinion about it. However, a lot of the positive reviews you hear about Rust are from amateurs who aren't using it in real products and a lot of the criticism you hear of C++ is from people who don't use it. Hopefully that helps you adjust some of what you hear to be a bit more grounded.
Rust isn't just a redo of C++. Rust introduces some important new concepts that I think will stand the test of time, even if rust itself fades for whatever reason.
In Rust's case, it's usually very easy to separate the amateur reviews from production users. The latter will follow up the praise with the same set of "devils in the details" shortcomings like the compile times, community maturity and rapidly developing best practices like the error handling story, compile times, steep learning curve when bringing team members onto the project, growing complexity of the language, and compile times.
I'm working on a Rust realtime (streaming updates, not embedded) service thats going into production soon and it's a breath of fresh air after decades of C/Python/JS but man, bringing up junior devs is harder and those compile times don't help (especially with async/await).
I feel like I'd prefer Rust, due to being simpler and more straightforward. It doesn't have decades of history, so there's less of a situation of having a bunch of legacy ways to do things with various footguns. Cargo makes it easy to pull in crates and build things with them. Some of it's parts, like Serde, are really slick. Others, like async support, are still a little tricky.
On the other hand, there's no denying that C++ has a massive library of integrations with all sorts of things, and supports way more hardware, due to it's immensely long history. It's the preferred way to interact with most of the native GUI libraries out there. There's a zillion libraries you can connect to your C++ code. It's probably a little more complex than the best Rust integrations, but better a well-tested natively supported integration than trying to build a new Rust integration around it, or rely on a half-finished open-source project that nobody cares enough about to support.
If any of those C++ reasons sound like something important to you or that you might want to work with in the future, then go with C++.
Java is an obligate-OO language, whose OO mechanisms must be subverted to code other designs.
C++ is a language that has constructs you can use for OO if you really want to.
Coding with an inheritance hierarchy and pointers where it does not fit is actually called "Java Disease".
You should really start with C as it gives you a solid foundation both of how things work under the hood, and you'll be likely to have to dive into C from time to time. Apart from K&R, Hacking: The art of Exploitation 2e[0] is a really great book to grok C.
But you can safely skip C++. Rust is a C++ killer IMO.
[0]: https://en.wikipedia.org/wiki/Hacking:_The_Art_of_Exploitati...
I'm learning Rust now after several false starts. Here's what I find challenging and interesting about Rust: most languages exist on a spectrum between faithfulness and abstraction, where they either represent the underlying hardware in an accurate way (like C), or they provide high level abstractions that allow you to simplify your mental model of how a computer works (like python).
Rust is interesting in that it uses abstractions which don't lead to a simpler mental model. There's no such thing as 'lifetimes' from the computer's perspective. And yet these abstractions, though somewhat artificial, can still shape your code in beneficial ways.
I think that learning Rust without having exposure to C would make it difficult to recognize which constraints that Rust imposes are based on actual limitations of the machine vs Rust's particular paradigm. So I say learn them both.
You should also include C in the mix (very different from C++(!!) that's why "C/C++" is a bit shunned upon by some people), because Rust or C++ are often overkill. If you're tackling Rust and C++ anyway (which is essentially a lifetime task), learning C on the side is literally a "weekend project" ;)
Just remember that C and C++ are not as similar as many people believe, they are different languages with different goals and a different philosophy.
Similarly, if you decide to go with C++ now, it's not a commitment if you later read about an awesome Rust DSP library or something.
It only becomes a commitment once you start writing real, production code in it.
It is also perfectly sensible to just set aside a week's spare time for each language and give them a try. You'll learn more real stuff from that than any amount of questions asked online about which is better.
Very good point. Projects must be maintained, and that's when mastery matters.
You can do the same thing in Rust, but it's a bit more work.
https://www.miasap.se/obnc/oberon-report.html
I'd suggest learning C. It's the simplest language of the three, and it's the lingua franca of systems programming. You will have tons of resources and examples to work from. And you won't get stuck/frustrated over type system or lifetime issues. You'll always be making progress with C even if it's buggy.
While learning C, I highly recommend that you dabble in Rust. Rust has introduced important concepts to programming that will not go away, and just does a lot of things really well, including C integration. You also might appreciate the really easy cross compilation system for embedded development.
What you want to learn (especially in embedded world) is how various Linux/POSIX APIs work, not language features.
So either choice is good as long as you learn to use them, but I personally recommend C because C is the first class language for Linux APIs e.g. they are exposed directly via #include <sys/> or #include <linux/>.
As others recommend, you can learn C and Rust at the same time though.
That said, the elephant in the room is the toolchain. With Rust you use cargo. With C you use ... a hodgepodge of technologies glued together with duct tape. While learning C, you'll also learn about make, cmake, autotools, ninja, bash scripting, etc.
C is easy. It's all that other crap that makes it more challenging.
[0] https://www.oreilly.com/library/view/21st-century-c/97814919...
If you use cmake (or meson) for your project and conan for the dependencies then you don't need to know autotools, ninja, etc. Especially if you hew close to "well-known" libraries (SDL, Boost, Cereal, nlohmann json, etc.) which have good support in conan.
Would you consider yourself an early adopter type who's more happy working on the bleeding edge? Rust is great but it's not a mainstream language yet and working with late adopters will be difficult. There are fewer project and job opportunities in Rust. You may have to be comfortable with writing your own libraries and tooling.
If you're more of a late-adopter type you probably value stability and maturity of the tools you rely on and perhaps put more emphasis on solving your domain problems rather than language tooling and tech problems.
The other factor to consider is what your goals are. If the incumbents in telecommunications have built a large ecosystem of libraries and tooling in C/C++ you're going to be working in a small niche writing things in Rust. Do you want to carve your own ecosystem in the space or would you rather spend time improving the status quo and moving ahead with the rest of the pack?
There are no wrong answers! It all depends on what you value more. They're all fine languages and tools. If you lean towards Rust simply because you're happier working in it then go for it. If you're not being paid to work on these projects then happiness is definitely a strong indicator you should be using Rust.
Happy hacking!