11–20 of 161 posts
Unless you're going to be doing something that specifically requires C++ (some game engine related code comes to mind), go with Rust. Most real-world code (by number of codes and lines of code) is something else than C/C++ nowadays, just because of developer velocity and a larger hiring pool. 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 peopl…
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!
Between C++ and Rust, my bet would be that you decide Rust. But—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 m…
I'm confused when people preach Zig and then safety in the same sentence. Zig has basically all the same problems that C++ has with a few extra bells and whistles. There are perfectly good reasons to like Zig, but it being "safe" is not one of them. > 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 de…
Between C++ and Rust, my bet would be that you decide Rust. But—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 m…
I'm confused when people preach Zig and then safety in the same sentence. Zig has basically all the same problems that C++ has with a few extra bells and whistles. There are perfectly good reasons to like Zig, but it being "safe" is not one of them. > 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 de…
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.
There is just not enough information in your post in what you want to do with your knowledge. 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
Unless you're going to be doing something that specifically requires C++ (some game engine related code comes to mind), go with Rust. Most real-world code (by number of codes and lines of code) is something else than C/C++ nowadays, just because of developer velocity and a larger hiring pool. 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 peopl…
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.
Unless you're going to be doing something that specifically requires C++ (some game engine related code comes to mind), go with Rust. Most real-world code (by number of codes and lines of code) is something else than C/C++ nowadays, just because of developer velocity and a larger hiring pool. 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 peopl…
> Most real-world code (by number of codes and lines of code) is something else than C/C++ nowadays, just because of developer velocity and a larger hiring pool. 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)…
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.
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
-fno-strict-aliasing -fno-strict-overflow
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.
There is just not enough information in your post in what you want to do with your knowledge. If you have a long time horizon, Rust is the safer bet, if you want a job fast, C++ has probably more job offers.
Honestly my main short-time goal is to write performant applications, I have some processes in mind that would work way better if I could manage memory instead. 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