Hacker News new | ask | show | jobs
by sharedptr 1506 days ago
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

1 comments

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.
Unless you're manually implementing data structures or something similar you basically never need to manage your memory manually in modern C++. std::vector takes care of most your needs and smart pointers exist for the few cases where it doesn't. There's not really a lot of difference to Rust there except that OOB access is a panic in Rust and (most likely) a segfault in C++ but you can trivially enable that checking by putting the STL in debug mode.

C++'s problem is that most people never learn it properly and think "C/C++" is a thing because most courses/tutorials are stuck in the 90s and effectively teach shitty C with classes and iostream. Rust is great and has really nice features which I'd like to have in C++ too (like pattern matching) but memory safety is really not an issue in proper modern C++. I'm aware that this is a bit of a "you're just holding it wrong" but pretty much all languages have things you shouldn't do anymore once they evolve, it's just more obvious in the one with strong backwards compatibility requirements to the ancient language created before all the modern research into language design.

It's entirely possible to invoke memory unsafety in modern C++.

    std::vector<int> v {1, 2, 3};
    int& x = something(v);
    something_else(std::move(v));
    x = 42;
Is this UB? Impossible to tell without examining the code of the functions involved!
Nobody said it's impossible, it's just generally not an issue if you write normal code (read: stop treating C++ as C, they are completely different languages). There's only very little difference in how much you need to think about lifetimes and stuff between Rust and modern C++, it's far from being "hard". Sure Rust holds your hands a bit more in those regards but you can also just turn on address sanitizer and friends and then you have a very similar experience.
I took an Earley parser library written in Java and ported it to C++ with just using smart pointers everywhere for memory management and it Just Works™. Like magic really as I can’t recall having to hunt down any segfaults and I spent a bunch of time debugging that thing because porting from Java wasn’t really a copy paste operation especially since I never mess with Java so don’t know the standard library stuff.
> 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?

Problems with memory management are a fading memory when coding modern C++.

All the things Rust advocates insist cannot be done safely in C++ are now trivial. Use-after-free, leaks, buffer overruns, what-have-you, no longer need any attention to avoid if you stick to modern C++. Some people insist on coding as if it were C, and bring along all of C's failings. Leave them behind.

Unfortunely, only when working solo, or with a team that really embraces security.

Those people that insist on coding as if it were C are still a very big group across the industry.

The problem is that it's too late to add linear typing to C++ at this point and get rid of all other types. So I would say yes.