Ask HN: Learn C++11 or Rust in 2022?

Some employers are actually far-sighted enough to spend money training their employees.

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.

I find it difficult to articulate, so forgive me if I'm not getting my point across, but the gist of what I'm trying to say in that section is less about straight binary compatibility and more about API design in general, playing to the respective language's strengths. I feel like Rust encourages more "C-like" APIs, and its added features (such as memory safety) are in effect the whole running time of the program, regardless of where that memory comes from or how it's initialized. On the other hand, C++ has something of a vendor lock-in regarding how it functions - RAII, constructors, exceptions, inheritance, etc. etc. all assume you have objects with a lifecycle that starts and ends in C++, and that those objects see most of their use according to C++'s object model. All of C++'s features come together in a brilliantly harmonized way and build off each other, but, if you forgo even some of those features, you end up missing out on most of them.

Since it looks like you want to use it for some personal projects and you’re already comfortable with C, I’d suggest C++.

I’ve found that Rust requires more careful design to satisfy the borrow checker, whereas in C++ you’d just copy or use a smart pointer and move on with life. Additionally, when in Rust you have to change that careful design, the changes tend to cascade and spread.

All of the above could be largely avoided by using copying and smart pointers also in Rust, except that goes against the culture and what everyone else is doing. Most of the APIs you’re using will probably want you to use references…

To me Rust is the kind of language you’d use if you have your solution figured out and you want to implement a robust program based on that. Flexibility and development speed are not its strengths.

Here’s a fun way to decide. Do Raytracing in One Weekend[1] in one of them. Then rewrite it again in the other. That should give you a good sense for which one you want to invest in.

Spoiler: I did this exercise myself. I found Rust to be more convenient in some ways. The Rayon crate made adding parallelism (threads) pretty easy. Some other crates made things pretty terminal output easier.

C++ feels more familiar to me in many ways though - I also write C fairly often. Implementing parallelism was more difficult. (I tried `pragma omp` stuff which should work similarly to Rayon, but couldn’t get it to work.) But just getting something working seems a little more straightforward.

I find myself fighting Rust somewhat often. In C/++, if you know what you’re doing, and you just want something working as a fun side project, it usually takes less dev time in my experience. Maybe that’s because I’m still learning it. Some folks will argue that the Rust compiler forces you to write better code and actually makes dev faster because it catches your mistakes. I haven’t found this to be true.

For example trying to implement simple polymorphism in Rust that was analogous to the implementations in Raytracing Weekend got ugly very fast. I ended in a weird hell of having to add annotations to everything to support generics. Again maybe I don’t understand the language enough, but adding polymorphism was a 5-minute straightforward exercise in C++, even as someone who doesn’t write it often.

I like a lot of stuff about Rust but I’m doing my hobby dev stuff in C instead nowadays, mostly for dev speed like I said, and probably would opt for using a subset of C++ for higher-level projects.

[1] https://raytracing.github.io/books/RayTracingInOneWeekend.ht...

I feel that by starting with FP, for example by starting with something close to ML in syntax and concepts, you cut yourself from too much of the programming world as everything else feels completely foreign and weird. But I get your point, you can approach it from the other side and also develop your intuition this way.