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.
I'm not ready to go back to C++ for this, but I know exactly what you're talking about regarding polymorphism. It's all magic and fairy dust for me, I'm really enjoying Rust. But once you want a dyn trait instead of a simple function, suddenly half of the magic doesn't work any more, and the language explodes into all riddles. (Interesting ones, I admit, and often there is some valuable insight at the end. But still a distraction.)
I guess as C++ veterans, we have to re-learn which approaches will work straight-forward, and which are the ones are asking for trouble. (I eventually found decent solutions for my problems that, while not the ones I had in mind initially, didn't require solving any hard puzzles.)
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...