21–30 of 289 posts
The most fun thing reading this comparision is again that for an experienced C++ programmer who is used to managing memory by hand (and fixing segfaults), Rust's memory model doesn't seem that hard, because it makes sense, and he understands why the checks are important.
nobody with an inch of nous does that anymore.
The call out to sum types is something I feel. I've been using Rust daily for almost 10 years now, and sum types are absolutely still one of the things I love most about it. It's easily one of the things I miss the most in other languages that don't have them. I'm usually a proponent of "using languages as they're intended," but I missed exhaustiveness checking so much that I ported a version of it to Go[1] as a sort…
so, um, unions? i have to say that in many years of programming, i have almost never needed to use such types.
Earlier quoted context omitted.
You are still "managing" it even in that instance (just like in Rust). The overhead is just smaller than in say C or old style C++ with new/delete.
The overhead is the same. Rust just takes care that you're doing it right, while C++ lets you shoot your foot off in this area.
The difference is that the use of the smart pointers is checked of the compiler
The call out to sum types is something I feel. I've been using Rust daily for almost 10 years now, and sum types are absolutely still one of the things I love most about it. It's easily one of the things I miss the most in other languages that don't have them. I'm usually a proponent of "using languages as they're intended," but I missed exhaustiveness checking so much that I ported a version of it to Go[1] as a sort…
so, um, unions? i have to say that in many years of programming, i have almost never needed to use such types.
> i have almost never needed to use such types
Well sure. When is an abstraction "needed"? Before Fortran, nobody "needed" a programming language either. So is a programming language necessary?
That's the funny thing about the word "need." It has very narrow application, and it's precisely why I didn't mention the word a single time in my top level comment.
The call out to sum types is something I feel. I've been using Rust daily for almost 10 years now, and sum types are absolutely still one of the things I love most about it. It's easily one of the things I miss the most in other languages that don't have them. I'm usually a proponent of "using languages as they're intended," but I missed exhaustiveness checking so much that I ported a version of it to Go[1] as a sort…
That said, the bulk of our code is Nim, and it is lovely to work in. I just wish we didn't have to rely on C/C++ libraries and toolchains as much. CMake will be the death of me, I swear, and it would be nice to have all the thought we have to put into to lifetimes and safe bindings around unsafe C calls be able to be encoded into the language itself, rather than as comments and so on.
Earlier quoted context omitted.
so, um, unions? i have to say that in many years of programming, i have almost never needed to use such types.
Nope, not unions. Sum types. Sum types would be more analogous to tagged unions or discriminated unions. > i have almost never needed to use such types Well sure. When is an abstraction "needed"? Before Fortran, nobody "needed" a programming language either. So is a programming language necessary? That's the funny thing about the word "need." It has very narrow application, and it's precisely why I didn't mention the…
Earlier quoted context omitted.
Rust's memory model is even more familiar to C++ programmers who don't manage memory by hand because they have the same concepts of borrowing and lifetimes.
I was just trying to find a modern C++ tutorial, but there's nothing comparable to the Rust Book on the internet. I think even now the best resource to learn C++ is to first learn C, then original C++, then all the modern memory management techniques, which is just crazy hard for a new programmer compared to just going through the Rust book 10 times (which is needed to get a deep understanding).
I want to switch to Rust, to get away from the C/C++/Nim mix we rely on at work. But embedded development (specifically for the ESP32-S3 chip, but we also have to do a lot of STM32 work as well for our coprocessors) has sort of forced us down this path. That said, the bulk of our code is Nim, and it is lovely to work in. I just wish we didn't have to rely on C/C++ libraries and toolchains as much. CMake will be the d…
The most fun thing reading this comparision is again that for an experienced C++ programmer who is used to managing memory by hand (and fixing segfaults), Rust's memory model doesn't seem that hard, because it makes sense, and he understands why the checks are important.
> for an experienced C++ programmer who is used to managing memory by hand nobody with an inch of nous does that anymore.
Especially when performance matters (eg: high frequency trading systems, video games, constrained embedded systems, and more), the improved locality that you can get from custom memory management can be worth it all on its own.
For a good talk on this subject, see Lakos "Local Memory Allocators" presentation:
* part 1: https://www.youtube.com/watch?v=nZNd5FjSquk, part 2: https://www.youtube.com/watch?v=CFzuFNSpycI