Ask HN: Should I learn C/C++ or Rust as my first systems programming language? | Hacker News Reader

Ask HN: Should I learn C/C++ or Rust as my first systems programming language?

40 pointsabnry79 comments

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?

View on HN

I say learn Rust and C in parallel.

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.

Don't lump C in with C++. They're very different languages. If anything, I'd lump C++ in with Rust. They're both big, complicated languages. If you're just looking to understand the C model of computing that underlies any Unix-like system, spend some time with C. Learn to write a linked list, experience a few segfaults, and then decide what kind of safety and abstraction you'd like in your systems language.

I figured I'd get one of these types of comments. =) Yes, I know it is dangerous to lump C and C++ together. But truly, I appreciate your comment. Unix systems are important to me, and it seems C is probably a good idea to master first.

It's not dangerous -- it's a mistake. It's like putting strawberries in with salmon on a salad: ostensibly it's good, but it's wrong. :D

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. :)

Learning C first would be a huge mistake.

You will pick up bad habits that many people have never managed to shake, and that make for bad C++ and even bad Rust.

Learning C first would help you understand low level code, that much is true. But it's also probably the absolutely least productive programming language currently in use. Anything which doesn't involve twiddling bits or calling a function is tedious to write and hard to use.

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.

You got about a dozen :) Don't be swayed by the naysayers who tell you not to learn C no matter what. You already know it's a dangerous language. Approach it from the perspective that this is your opportunity to learn what kind of headaches you want to avoid. Understand that the defensiveness and paranoia that come with writing C are not fundamental to systems programming, but that the problems that engender them are at the root of a lot of the complexity you'll see in other languages.

C is closer in syntax and how the language compiles to C++ than C++ is to Rust. People need to stop making this comparison (almost always made by people who have never written any Rust).

I think every developer should learn enough C to "get by" and at least to be able to read and reason about C code given there's so much of it out there, especially in the embedded world. But do you have to spend 5 years grinding out only C code? No.

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.

Hey there! Rust core team member and long-time C programmer here.

The short of it is, this is complicated, and it really depends on individual circumstance. You have given your circumstances, so I can help answer on that basis, but doesn't mean I agree it's the same for everyone.

There are two major ways of thinking here: Rust first, or C first. The advocates for Rust first will point to an easier onboarding story, a supportive community, a helpful compiler, and that you'll start off with good habits. The advocates for C first will point out that C is the latin of software development, and that you may not appreciate what Rust does for you without first experiencing the wild west of C.

Both of these have merits. I personally prefer Rust first. I of course, have a lot of bias.

I work in embedded Rust, and the thing is, the industry is still C based. Depending on which embedded devices, it may be your only option. So, I don't think there is any world in which you cannot learn C. Even though my codebases have no C in them at all, data sheets refer to C concepts, example code from vendors is all in C, blog posts and other helpful documents are generally in C.

So, absolutely, learn C to some degree.

Personally, what I would do in your situation is this: pick up a copy of K&R. Pick up a copy, either online for free, or in paper, "The Rust Programming Language." (I am a co-author. I don't make any money from the book; I recommend these two because they are generally considered the go-to book for each language.) Read them. See what speaks to you. Go from there. There is no reason you have to make a big choice up front and commit to it to all time. Try things. See what makes you go "I want to do more of that." And then move forward. Maybe you'll love C and never learn any more Rust. Maybe you'll like Rust and stick with it primarily. No way to tell until you give them both a shot.

(I actually strongly disagree with many of the ways that people characterize C, and even in this thread. C is not actually a small language, it is not super simple... but that doesn't mean it's not worth learning.)

"C is not actually a small language, it is not super simple."

Can you expand on that? Clearly C moves a lot of complexity to other areas, or hides complexity by using subtle semantics. But in the context of learning/hacking that isn't necessarily bad.

> Clearly C moves a lot of complexity to other areas, or hides complexity by using subtle semantics.

This is what I mean. I do think it's tough in the context of learning, because many resources will teach you things that are actually technically incorrect, but work enough of the time that you won't always notice it. And it's really really tough to know if what you've done is even correct, because you don't have a ton of help. This is before you even get into the bevy of flags which can change language semantics, and are actually used by real projects.

You also have to deal with different social groups of people who have different beliefs about what the language even is. https://raphlinus.github.io/programming/rust/2018/08/17/unde... This is what leads to a lot of those conflicts about semantics too.

None of this means C is not worth learning, or that you shouldn't do it. But I think suggesting that it's simple in the way that, say, Go is a simple language to learn, just isn't really true. YMMV.

Thank you, I appreciate your comment!

Please, learn C. It's very fast to learn (it's harder to write good code in it, though) and it's pretty much the lowest common denominator that all languages and platforms try to interface well with. It's also much more popular than Rust is on embedded devices.

Yeah, learning C then Rust seems good to me. There's no reason to learn the complex beast of C++ if you aren't interested.

C is easy to learn, but very, very hard to unlearn.

I'd rather work on a Go, ocaml, haskell or clojure project with a C dec than a C++/Java dev. OO programmation is hard to unlearn and add basically no value for system/network projects. Yes C can give you bad habits, especially if you're not rigorous, but people trying to add inheritance and classes everywhere are a disease. I remember most JS code pre-ECMA6, it was cancerous, that when my OO hatred started.

There is no such language as C++/Java.

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".

I think you can go with your gut and learn Rust, because even if you discover that's a mistake and you need to switch to C or C++, there's probably going to be more transference than you think. Switching isn't free, but the knowledge gained on the "wrong" path will be valuable on its own, so it's not that big a deal.

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.

> It only becomes a commitment once you start writing real, production code in it.

Very good point. Projects must be maintained, and that's when mastery matters.

Rust is awesome. Lifetimes and ownership are amazing abstractions over memory management. However, Rust causes you to become dependent on the borrow checker, and often lazy. It might be very hard to switch to C or C++ after.

C++ is used far more in industry and will continue to be used for a long time to come. Learning C++ will not hinder you at all and the newer C++ features make it fairly easy to use for someone coming from higher level languages.

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.

Hmm, I've used both Rust and C++ professionally (and prefer Rust). But it's fair that most positive or negative things about programming languages are from people who haven't used them professionally.

I agree that you should calibrate the excitement for a new language like rust appropriately. But I think it goes to far to say that rust advocates are amateurs. Many are professionals that have a hobby project or three in rust, and like what they see so far. Surely some of these hobby projects will grow up.

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.

I agree. I didn't mean it pejoratively, or that the people using Rust aren't professional developers.

> 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.

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).

Depends on what you want to do. Either way, exposing yourself to more programming languages ideally with different styles and background should make it easier to familiarise yourself with others.

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..

One upside of learning Rust first is that it will provide guidance on how to write C++ code afterwards, so that might be valuable.

Also, isn't it easy to make FFI calls to C/C++ libs from Rust when you need to interface with an already existent codebase?

Making FFI calls to C is pretty easy and writing the FFI interface definitions can be completely automated with tools like bindgen [0]. Making FFI calls to C++ is a lot harder to do by hand, although cxx[1] is supposed to make doing so a lot easier as long as you can control the C++ end as well to be able to make it compatible with Rust Strings/Vectors/etc.

[0] https://github.com/rust-lang/rust-bindgen

[1] https://github.com/dtolnay/cxx

The point for me to learn C or C++ over Rust is not to interface with an existing codebase, but gaining proficiency in reading & modifying it.

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.

Learn C. You will always need to know it. The K&R book is not a very big book.

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.

21st Century C helps a lot [0]. It's not a huge volume but it spends a good amount of it picking out a great tool chain for C projects and how to use them.

[0] https://www.oreilly.com/library/view/21st-century-c/97814919...

> While learning C, you'll also learn about make, cmake, autotools, ninja, bash scripting, etc.

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.

I see those as three options: C, C++, and Rust.

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.

C/C++ is not a thing: they are separate and very different languages.

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.

Learning C is an extremely poor way to start learning C++ or Rust. It creates bad habits that take many people years, some a lifetime, to unlearn.

> Learning C is an extremely poor way to start learning C++ or Rust.

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++".

You have encountered Java Disease.

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.

Rust will force you into correctly handling the major footgun of C and C++ - ownership of memory. If you decide that you want to learn C++ later, it'll only take a few dozen segfaults instead of few hundred to get up to speed ('would something like this compile in rust?' is a helpful question to ask if possible)

IMHO: Learn both but start with Rust. Rust forces you to think about memory management topics (memory lifetimes and ownership) which you will also need to know about in C++, but in C++ you are entirely on your own so it's easier to "slip into" bad memory management practices (which you would need to unlearn again when moving from C++ to Rust).

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.

There's a lot of great resources out there for learning both Rust and C/C++. That being said, I feel like if nothing else, Rust serves as a great way to teach you the importance of memory safety. This is a skill that translates very well if/when you want to learn C/C++, as well.

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.

I'd say it depends a lot on what you value and where you'd like to spend your time.

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!

I guess it depends on what kind of tools you see yourself building with a compiled systems language.

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++.

If you ask HN, HN will almost always tell you to learn Rust.

But HN is its own echo chamber. Rust is practically unheard of outside the enclave. If you learn Rust, you will be obliged, in short order, to learn other languages that are actually useful in your target area.

So, find out what languages are used there, and learn those. The only bad mistake would be to start with C.

That said, it is not a mistake to learn Rust. Just don't expect it to be usable at work.

I will go against the grain and recommend that you learn C++. Yes. It's a complex language, but it is extraordinarily powerful and meant to be used when nothing else will do. It is not a suitable language for novices to write production quality code in. But in the hands of an expert, it can do some amazing things. Rust is nice, but its performance still doesn't come anywhere close to C++ for many tasks. When you need to build extremely high performance systems that are also very complex (think CAD software, simulation etc.,) C++ is simply unbeatable. Also, once you've mastered C++, you will find Rust fairly easy to learn.

> but its performance still doesn't come anywhere close to C++ for many tasks

Like what?

Domains where C++ is a better option include High Frequency Trading, and high performance computing and CGI (game engines, rendering engines) And despite Mozilla’s best efforts browsers.

I think learning a language is not the point, but learning underlying system (OS) is.

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.

Here's a quick way to figure out if Rust is for you: https://tourofrust.com/

I think learning Rust first - and then possibly C - is a better plan for your background of python and matlab. I think it can be difficult to appreciate C when coming from the higher-level languages, and so while it may be easy to get along with it, it won't really change how you think about code... My opinion would be different if you had done no programming before, then I'd say start with C, then Rust.

Learning Rust is a lot of fun. There's a large community of people who enjoy using it and helping others solve their problems on Discord, Reddit, and Discourse. Experienced embedded developers are saying really positive things about Rust for their work, with the exception that the open source ecosystem remains in its infancy. I'm noticing embedded Rust job listings sprouting up in a lot of industries, so I think we have much to be optimistic about at this point. Also, teams such as those at Ferrous systems are focusing on long-term viability of Rust for embedded by investing in the ecosystem and creating onboarding pathways: https://ferrous-systems.com/blog/

Even if you don't wind up doing embedded work, you can cffi your python to Rust libraries for performance optimizations. You probably won't be writing optimized Rust for a while, so don't plan for quick wins with Rust extensions until you're several months into working with Rust full time.

In your circumstances I'd skip Rust altogether and focus on what the industry's using and what your colleagues are using. This will most likely be C or C++. If you go for C++, you can also use it in other domains, such as data science.

Rust is something you learn if you want to get a job doing Rust or for your general knowledge, not if you want to solve a problem or understand an existing domain.

I would say give a nice look at C and C++, you are probably going to appreciate Rust a lot more if you know where your foot can be shot by it.

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.

Agreed. Learn C++ first, and you'll appreciate Rust more. But whatever you do, don't let expertise in one language become a chain holding you back from learning others. I know a lot of people who are afraid to go from being an expert in X to a beginner in Y, and this tendency is even more pronounced when X is hard to master, but it's a trap. A language that's hard to master will continue to waste your time forever. It's a classic hill climbing problem. Sometimes you have to go down through the Valley of Noob so you can climb a higher hill. Then you can look down at all the people who stayed with C++.

To me saying learn C++ to appreciate Rust sounds like advising someone to bang their head against the wall first because when they stop it will feel good.

Heh, there's a grain of truth to that. I think the metaphor I'd use is to try building a table or felling and trimming a tree using hand tools before getting out the power gear. Some people do like the manual approach, sometimes it's even the right choice, but generally letting the tools do the work is the better idea.

We're a fully Rust shop now (we write code for secure enclaves up to and including implementing a custom malloc from scratch). I actually don't see any reason to learn C anymore unless you are interfacing with older systems or doing stuff where you need to drop out of Rust's guardrails (if you're new to systems programming you're gonna wanna avoid unsafe code as much as possible).

It's just a lot harder to write broken programs because of how screamy the compiler is in Rust. You will spend more time getting your code to compile but it will have fewer errors (and be multi-threaded+memory safe by default).

I think most production software that is written de novo today will be in Rust over C/C++. It's just not comparable in my opinion. Like, when we implement stuff we can have logic errors but eliminating the entire class of buffer/array/pointer failures is extremely useful.

I have used Ruby and yes Rails for work for over 10 years. I did learn c++ in school but never use it professionally. Like you I see a lot of what I like in Ruby in Rust. I have been using it "amateurishly" for the last 3 years. I it has made me think about my Ruby code differently for the better. Could C/C++ do the same thing? I am unsure. I hope to one day use Rust as a professional but until then it will be my go to for fun projects and serve as a tool for learning. I expect Rust to extent beyond the statement of "systems language" at some point. I just wrote a search tool based on my browser history using 99% Rust (Actix server, Tantivy search and Yew wasm frontend). Not having to write much javascript for a full stack project was refreshing.

Before all, I'd spend a while learning C, because C is kind of lingua-franca so it will be useful to understand alot of programming languages, that are part of C-family, including C++, Rust and D. Also Rust end C++, I would consider learning D.

I work a lot with embedded devices (arm cortex-m chips mostly), and if you download the datasheets for some chip that you think that you might be using, I would guess that the only code mentioned in it are going to be in assembler or C.

Also, if you have a chip that you think you might be working on, check out the development tools from the chip manufacturer, it will probably be made for C.

Learning to use a chip is much easier if you have a library of examples written by the chip-maker for that specific chip.

For those reasons I would recomend C.

Rust. For sure, otherwise stick with C. Having programmed in C++ for a long time (but no more!), I think it has too much baggage (compiler support / versions / platforms etc) and the ecosystem isn't as good as Rust's. C is just C and you need to know it from a first-principals point of view, but it's terribly unsafe compared to Rust (kind of like driving in a 60's convertible with no seatbelts or ABS).

I think the Rust hype is starting to die. Take a look at D Language. It was created by Walter Bright (the first person to single-handedly make a C++ compiler, Zortech C++) and Andrei Alexandrescu (former C++ committee member and author of Modern C++ Design).

Also, for number crunching- since you're a data scientist– Julia and Numba might be better choices, as they crunch numbers efficiently.

Another interesting systems programming language is the Pascal descendant Oberon which is (way) simpler than all three languages mentioned:

https://www.miasap.se/obnc/oberon-report.html

You seem pretty set in your choice already, just looking for confirmation. what's stopping you?

Rust's compilers are built in C++. They are not on the same playing field yet. If you want to make a comparison, it would be C and Rust. Both are excellent system programming languages, but I recommend Rust for its forced memory-safe syntax.

Rust’s compiler is in Rust, though it does use a C++ library for the main backend, you can also use a newer one which is implemented in Rust.

Rust has a nice up-to-date book and more rich community than C++. Plus better tooling.

I count the bank of existing knowledge, Stackoverflow posts and tutorials, as the community. In that case I don't see how such a new arrival could have a richer one than C++. There are still relevant C++ questions that someone asked on a forum in 2002.

Be careful. That can also be actively harmful as people copy paste years old code from stackoverflow and don't know that it is already doable via primitives language provide.

Example, all the answers that tell you to import jquery.

How do you suggest keeping up with all the primitives provided by C++? The language seems to have a major makeover every few years.

A new Standard is issued every third year. C++11 and C++20 had numerous big improvements that seriously improved the whole coding experience. C++14 and C++17 had few wholly new features, but relaxed many restrictions. C++23 will not be a big release, although probably it will get "reflection", making it easier to write and to use serializer/deserializer libraries, and a comprehensive networking library.

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.

Given that you already use Python, have you considered writing C extensions as a way to take advantage of what you already know to learn something new (C language)?

You can do the same thing in Rust, but it's a bit more work.

Neither. Learn Scheme.

Structure and Interpretation of Computer Programs is still the best single book on computer programming: the most important concepts (closures, continuations, macros, transformations,...) for the least expense in complexity.

To what you learn from SICP, rust and C++, add just one thing: how to exploit a physical stack efficiently. Scheme->C++/rust will be easy. C++/rust->Scheme can still be quite difficult depending on how distracted you got by the complexity.

As a practical matter, most system software is written in C. Being able to read the Unix kernel has been valuable for nearly 40 years. You'd be surprised what one can accomplish with just functional decomposition.

My 5c:

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...

It sounds like you want in increase your range. Spending a few weeks learning basic C would provide a good starting point. Be sure you understand pointers, allocating memory, stack vs. heap, etc. From there you can launch off to C++, Rust, maybe Julia, etc.

Perhaps define "systems programming language".

rust, because it has cargo.

Reply on news.ycombinator.com