That's a great analogy. I like C, and when people resist it I worry about their programming skills. That may not be fair, but sometimes the complexity of C / C++ is a version of complexity you will see in a big application.Sometimes the complexity is needless, confusing, dangerous-- insert what you hate here.
But really Rust seems to have the qualities I like about C and less problems. Also, all the reasons I used to have for wanting to be "close to the metal" are getting abstracted away in hardware. I think the only remaining reasons to use C is the huge existing code base.
I'd like to see the Ada guys, and especially the SPARK guys, talk about Rust the way Rust people talk about C. That said, I'm just gonna add ACL2 to my Common Lisp toolbox and then I too will have the power of theorem proving.
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.
“...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.
I am not yet convinced that Rust is a sufficient answer to C. Its constraints do solve some issues, but I am not really convinced. Also personally dislike the self-identification of Rust users. Rustafarian? Seriously?
You probably get accustomed to it, but I am not sure if I want to yet. Not deep enough into compilers to know why variables cannot be implicitly mutable or not. Probably a compiler necessity to enact its borrowing rules. But ultimately the compiler should make my life easier. Only ever using one thread or process does solve several common locking issues.
In that regard C string handling will probably let more people move away from it than its security flaws.
It will probably end up like always. There are some applications where some languages shine. And the simplicity of C has merits, otherwise another language would have taken its place. Of course C still has a lot of momentum and perhaps another language would do better in the specific use case.
But really Rust seems to have the qualities I like about C and less problems. Also, all the reasons I used to have for wanting to be "close to the metal" are getting abstracted away in hardware. I think the only remaining reasons to use C is the huge existing code base.
reply