Issue is, Rust is not a drop-in replacement for C. The memory safety features are just one part, and since Rust is also a “weakly” functional language, thus its prefered to write such code with it.
D is a mostly drop-in replacement (type renaming and such needed though), and it doesn’t have that issue. D even has a mode called BetterC, where the D standard library and the garbage collector is left out.
Yeah, it’s not a small change. If there was a simpler way to make C memory-safe, it would have been done decades ago. It’s just a different language too, which is fair given how much younger it is.
D kind of did that (C pointers are still an option, alongside with the preferred dynamic arrays, which has the memory safety features), and once I’ve seen a C compiler fork that retroactively added D-style memory safety features, although they also very much insisted on the “const by default” mantra.
I think this is one of those things where there’s no “kind of”. Pointers were added for a reason, you’re probably not going to implement a database very well without them. If you use them, at some scale you’re inevitably going to have memory bugs. Technically, if you were to only use hardcoded printfs, C is memory safe too.
If there was a simpler way to make C memory-safe, it would have been done decades ago.
We’ve had compile time sanitizers (-fsanitize=blah in gcc/clang) and runtime sanitizers (valgrind) for ages. I don’t know how they stack up against rust’s compile time sanitizers, but it’s something.
Issue is, Rust is not a drop-in replacement for C. The memory safety features are just one part, and since Rust is also a “weakly” functional language, thus its prefered to write such code with it.
Anything that is drop-in replacement for C (or C++ for that matter) is going to be awful because of the same compatibility burden, imo
What about Zig?
Oh boy, Zig is just uglier C++ with memory safety, and it still has those awful header files…
IIRC it’s garbage collected, so really it’s just a version of Java.
It does not use a GC
D is a mostly drop-in replacement (type renaming and such needed though), and it doesn’t have that issue. D even has a mode called BetterC, where the D standard library and the garbage collector is left out.
Yeah, it’s not a small change. If there was a simpler way to make C memory-safe, it would have been done decades ago. It’s just a different language too, which is fair given how much younger it is.
D kind of did that (C pointers are still an option, alongside with the preferred dynamic arrays, which has the memory safety features), and once I’ve seen a C compiler fork that retroactively added D-style memory safety features, although they also very much insisted on the “const by default” mantra.
I think this is one of those things where there’s no “kind of”. Pointers were added for a reason, you’re probably not going to implement a database very well without them. If you use them, at some scale you’re inevitably going to have memory bugs. Technically, if you were to only use hardcoded printfs, C is memory safe too.
We’ve had compile time sanitizers (-fsanitize=blah in gcc/clang) and runtime sanitizers (valgrind) for ages. I don’t know how they stack up against rust’s compile time sanitizers, but it’s something.