Hacker News Reader

Comment by jimktrains2 | Hacker News Reader

Rust is actually a decent contender in this space. Memory safe and with the performance of C.

> I assume he would argue this is a matter of shitty developers, not a shitty language.

All developers are shitty.

Rust also has nearly no runtime and no garbage collector. Lack of GC makes it possible to integrate a Rust library into scripting languages etc. This is an easier upgrade path from C, which D, Go, Nim, etc cannot provide.

(For my projects I prefer D, but Rust has a point here)

Nim GC is optional; It can be disabled to write system libraries.

Rust is not a decent contender. It is far too immature. The only reasonable contender is C++.

C++ is not reasonable if your goal is to avoid memory safety bugs.

Neither is Rust, which comes with a huge RTS that itself likely full of such bugs. The library and the compiler too may have bugs that compromise the "guaranteed" memory safety of a libc written in Rust.

There is no silver bullet here. If one takes into account all the sources of bugs, C may very well be the best choice given its maturity and its ecosystem. Our best bet is likely to put more resources towards glibc development and especially fuzz testing. I bet there are only 1-2 developers who work on glibc full-time.

Has there been any work on a safe C? Not a C-ish language that is safe, but an actual implementation of the C language itself.

The C standard doesn't require the compiler to check the validity of array indexing and pointer dereferences and such, but it also doesn't require the compiler not to. Can they be added without destroying performance and compatibility?

Some of this already exists, with stuff like stack canaries and address sanitizer. But can it go beyond these ad hoc solutions that catch common mishaps, and become something truly reliable?

It should be possible to just flip a switch on the compiler and have it so that, for example, if you alloca() X bytes and then use the resulting pointer to access byte X+1, that is reliably caught at runtime. And not just as some single patch that specifically looks out for alloca() abuse, but as part of a wider system that understands and catches all out of bounds access.

This is sort of what Cyclone tried, in a way.

Cyclone looks cool, but it's a pretty significant departure from normal C. I'm wondering how far you can take safety without changing the actual language at all. Or rather, how far you can take safety without changing the language and without completely killing performance. Memory safety shouldn't be hard: track all valid regions and pointers to them and don't allow mixing stuff up. But doing it fast is tough.

Have you looked at CCured?

http://www.cs.berkeley.edu/~necula/Papers/ccured_pldi03.pdf

"CCured is a program transformation system that adds memory safety guarantees to C programs by verifying statically that memory errors cannot occur and by inserting run-time checks where static verification is insufficient."

I haven't heard of it before, but that's the sort of thing I'm thinking of, and that looks pretty cool. Looks like the resulting programs still perform reasonably well too.

FYI, Rust has no more of a runtime system than C/C++.

Rust does not really have an RTS per se. libstd is just a standard library.

Also, even if rustc has soundness bugs, you won't find them if you don't look for them, and even then, just trying to make your program fit the types will prevent most bugs.

By the way, glibc's code is too horrible to be read - musl is a more modern alternative.

> Rust does not really have an RTS per se. libstd is just a standard library.

And if you don't want to use the standard library, you just say #![no_std] https://doc.rust-lang.org/stable/book/using-rust-without-the...

That doesn't mean sticking with the status-quo is the solution.

Rust certainly looks like a better starting point for modern, safe low-level programming than C. C served us quite well for over 40 years, but perhaps it's time to move on...

> C++ is not reasonable if your goal is to avoid memory safety bugs.

I'll get crucified for saying this but it's easier to write safe code in C++ than C. C requires a perfect discipline very few people can maintain.

Cyclone-lang had good ideas about how to fix C, almost 10 years ago. I wish it has been more successful. i was less "alien" looking than Rust.

True, and hence why my rants about C tend to kind of ignore C++, as the community is more safe aware and strives to avoid the C compatibility subset.

However, it is very hard to avoid C++ developers that don't follow the modern C++ mantra to use it as if it was C, specially in the enterprise space.

You end up with "C compiled with C++" code style, which usually isn't subjected to any kind of code reviews or static analysis.

At what point will people consider Rust mature enough though? If we're going on number of years in existence, then C will always be older than Rust and the "well it's more 'battle-tested'" argument will never be false (for any language that is currently younger than C).

Maybe in a decade.

Do you not use git, because it hasn't been a decade? Will you only start using it after April 7th?

I've heard someone in real life say "git just isn't there yet", so I couldn't resist humoring myself with this comment, sorry.

Reply on news.ycombinator.com