Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A couple of points from somebody who enthusiastically writes new C code every day:

> ...the complexity of C / C++

In this case, please don't throw C and C++ into the same bucket, C++ is vastly more complex than C.

> Rust seems to have the qualities I like about C

...a subset of Rust has those qualities, but the whole of Rust has the same problems as C++: overboarding complexity both in the language and stdlib.

To lure C users over to a memory-safe language, we need a programming language that just adds the comptime memory-safety features to a 'small language' like C, but none of the higher level features (which only serve to split the language community into different tribes - which is also the biggest problem of C++).

Finally: yes, C is not memory safe, but when 'language-level memory safety' is essential for security, then there's something fundamentally wrong with the sandbox the compiled C code runs in.



I actually find that Go has the qualities of C that I like. Namely, simpler language constructs and no classes.


“...when 'language-level memory safety' is essential for security, then there's something fundamentally wrong with the sandbox the compiled C code runs in.”

Doesn’t the problem then just become what do you write the sandbox in? If you have security-critical code that can’t be sandboxed, because it is the sandbox, then it seems that language-level safety is your only remaining defense?


Yes, it definitely makes a lot of sense to write the sandbox in a memory safe language like Rust. Not even the most die hard C fan would argue against that ;)


Even if a C program is sandboxed, lots of programs handle sensitive data that memory errors can leak. For a simple example, even in a sandbox, a memory error could pretty easily lead to being able to grab another user's password out of memory.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: