It's painful to write because writing software that is memory safe is not easy. Rust makes it insanely easy in comparison to the "old way" of doing it (hacking together a C program then having to patch security holes every release, never being certain that your code is actually memory safe).
> Can I not write a well designed and correct program in C? Of course I can.
Of course you can. All it takes is a separate formal proofing process, countless hours of static analysis and many more months of fixing security bugs. Good thing that's so much simpler than Rust's static analysis which runs on every compilation and mathematically proves that its memory model was not violated.
I think if we have learned one thing in the history of C programs, it's that this sentiment that "a sufficiently smart programmer can write safe C code" is quite harmful. While technically true, I don't think I've ever met such an individual and I doubt one exists.
however, usually code is written by multiple people. (and i would also count your future self as another person).
that collaboration on the same code base requires automatic tests, otherwise the next person will break the code in non-obvious ways.
We have decades of coredumps and exploits to convince us that nobody can. How many well-known apps can you name that have never blown up randomly? I can't think of a single one. How much more failure until it's reasonable to think that C requires an inhuman level of perfection and almost any alternative would be an improvement?
I hear good things about seL4 but that wasn't written so much as translated from Haskell during a formal process that makes Rust look like finger painting.
It's actually more fun than that. They have two implementations of seL4, and they use formal proofs to show that the Haskell model is identical to the C implementation. How much fun is that! /s
Rust and Go advocates will have you think that they have conquered security via the memory mgmt and API front but there is still the off chance they haven't..or that the SA (what is left of that maligned profession outside playbooks and the devops marketing you read here and online) has allowed you a chance for glory.
1. Do not trust user input. This is a cardinal rule in whatever source. If the rule were followed vigorously in every case there would be 90% less exposure. When you take user input, filter. 2. Learn the standard and stick to it.
Finally #3 (unix) Write an application to do a certain thing well.
On #1, having just stumbled across a deserializer that can be commanded to allocate a 2^63 byte buffer, I agree 110%.
On #2, the problem is that the standard says things like "walking off the end of an array is undefined behavior" and "use after free is undefined behavior" yet we don't seem to have any programmers who can be trusted to reliably avoid these problems with zero runtime checking.
I do disagree with you, as it happens, but I'd downvote this sort of thing if I agreed too. There's a difference between bluntness being read as rudeness and what you're doing. Stop.
A year or so ago I wrote a Postgres extension in Rust. It was a real delight to have a package manager and to only have to worry about allocations within Postgres.
But whenever I want to code a big hairball without libraries or namespaces and use autoconf and all that great stuff, I still stick with C.
Please report this to the Hacker News mods, if you have evidence. It's against the rules, and they check this kind of thing. Nobody should be doing it.
> IP Holders, well this is speculative.
All of Rust's stuff is MIT/Apache2 licensed. There is a trademark on the name and logo, held by Mozilla, but other than that, there's none.
This clearly showed me the advantage of Rust over C.