8 ms·
"It'll be slower than C", they'll say. However, I would gladly sacrifice performance for memory safety, at least in an alternate, opt-in, network stack. Unfort
by mbreedlove 11y ago
"It'll be slower than C", they'll say. However, I would gladly sacrifice performance for memory safety, at least in an alternate, opt-in, network stack.
Unfortunately, I doubt this will ever happen while Linus is around. He seems to be quite fond of C. I assume he would argue this is a matter of shitty developers, not a shitty language.
- jimktrains2 11y agoRust 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.
- deleted 11y ago[deleted]
- qznc 11y agoRust 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)
- nyan4 11y agoNim GC is optional; It can be disabled to write system libraries.
- deleted 11y ago[deleted]
- denim_chicken 11y agoRust is not a decent contender. It is far too immature. The only reasonable contender is C++.
- ufo 11y agoC++ is not reasonable if your goal is to avoid memory safety bugs.
- denim_chicken 11y agoNeither 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.
- mikeash 11y agoHas 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.
- steveklabnik 11y agoThis is sort of what Cyclone tried, in a way.
- mikeash 11y ago
- deleted 11y ago[deleted]