31–40 of 161 posts
In the future, those codebases will only be the legacy ones and you will end up doing more maintenance with C++.
With Rust your investment of today will pay off in a few years.
Deciding what to learn today is an investment decision and you should look into what you think the future will look like. To me it looks Rusty. :-)
Yeah, the unreasonable C++ hate is real. That said, from the modern perspective, the old versions of C++ do suck very much. If you're not even acquainted with C++11 yet, you should definitely check out C++20. 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 m…
I would choose Rust. Today it might be that the market has more jobs on C++ and there are more codebases. In the future, those codebases will only be the legacy ones and you will end up doing more maintenance with C++. With Rust your investment of today will pay off in a few years. Deciding what to learn today is an investment decision and you should look into what you think the future will look like. To me it looks…
Earlier quoted context omitted.
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
With C++ realistically memory management is so hard that if you want to go solo, and you don't want to debug segfaults all the time, Rust is definitely the way to go. It teaches you manual memory management like nothing else.
Honest question as I'm not a C++ developer: Even with all the new C++17/20 stuff?
Earlier quoted context omitted.
Again, this is a tiny portion of actual coders. 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…
When the car's automatic gearbox breaks down, it is nice that there are some mechanics around.
I don't understand why someone who has so much open source information, has the intelligence to learn C-level languages, and has a certain experience in the industry, would ask such a question.
I’m actually surprised that the general consensus isn’t rust as that’s the new shiny plus the people saying C++ are giving very valid reasons beyond the usual language dogma arguments that these discussions usually devolve into.
Earlier quoted context omitted.
With C++ realistically memory management is so hard that if you want to go solo, and you don't want to debug segfaults all the time, Rust is definitely the way to go. It teaches you manual memory management like nothing else.
> With C++ realistically memory management is so hard Honest question as I'm not a C++ developer: Even with all the new C++17/20 stuff?
Earlier quoted context omitted.
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…
> I'm confused 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…
First of all, that's security, not safety. Lots of software exists in an environment where it isn't going to be attacked.
> Things like checked arithmetic matter and should be enabled by default in safe builds.
Rust offers actual checked arithmetic - for example, suppose I have a 32-bit signed integer (i32) and I want to add something to it, in Rust I can choose the most appropriate of:
add - also presented as the + operator, in debug this will panic on overflow, but in production I can choose, either panic or just have it wrap silently
checked_add - at runtime check for overflow and get either None or Some(i32)
overflowing_add - this time instead of Option we get a pair back, with our (wrapped if necessary) numeric answer and a boolean saying if we overflowed
saturating_add - addition saturates at the minimum and maximum thresholds
unchecked_add - even in debug builds this is not checked (yes it's unsafe)
wrapping_add - this performs the most likely native hardware behaviour, wrapping numbers around at the limits
You might also realise your variable should inherently have certain arithmetic, for example a 16-bit PCM sample should always have saturating arithmetic (getting this wrong is one reason badly written older audio software can sound bad) so you can make them Saturating or maybe you actually want wrapping arithmetic on the simulated 32-bit CPU registers in your Motorola 68000 simulator, so you use Wrapping for them.
The debug behaviour for the trivial + operator is not intended to be your best defence, if you're sure you want wrapping, write that down, if you're sure you want to check, write the check. But sure, if you somehow want your release code to panic, but don't want to write the panics out by hand, you can tell the compiler you want this in release builds.
> By definition, buffer bleeds can happen in safe Rust.
Nope.
> The borrow checker can protect against UAF and overflow, but it can't protect against all kinds of underflow
And it doesn't, in safe Rust the actual bounds checks are emitted, and they only get elided in most cases because in idiomatic Rust it's clear to the compiler that the checks are unnecessary (e.g. iterating over items in a vector, the compiler knows how long the vector is, and it can see we're starting at the beginning and stopping at the end, so, we don't need the bounds check and it won't actually be emitted in the machine code). thing[index] is bounds checked in safe Rust.
> No language is actually 100% memory safe, not with respect to buffer bleeds.
Many languages are 100% memory safe. Most fascinating here is WUFFS which - in exchange for its restricted purpose - gets to be both entirely safe and faster than the C (or C++, or Rust) you'd actually write.
You literally can't write a "buffer bleed" type goof in WUFFS. I don't mean "You won't because it's so easy to get it right" or even "It will warn you about the problem at runtime so you can fix it". I mean code which can exhibit that bug does not compile.