I don't disagree [1], but remember that Rust can be unsafe too. Async is not a panacea, and it's confusing. And the `unsafe` escape hatch is still unsafe.
> you have a professional obligation to use a higher-level language, with stronger guarantees
Oh? So we have professional obligations now? For FOSS? News to me.
I don't get paid for my work. Not yet. So I have no obligation.
And when I do get paid, my code will be in my own safe language.
This accusatory response is exactly the kind of thing that puts a lot of people off Rust.
> factually, you do not. nobody does.
When I say "write C at a high level," I don't mean that I'm perfect. I mean that I write excellent C compared to all C programmers out there.
Engineering is not about perfection; it never was. It's about doing the best we can with the tools that we have.
[1]: https://git.gavinhoward.com/gavin/bc/src/branch/master/MEMOR...
Of course, feel free to judge for yourself.
I think the proof is in the pudding here. I can't imagine using a messaging client or an email client written in C, and also there isn't much that is written in C anymore even if I wanted to: you're looking at Swift/Java/Kotlin/TypeScript/JavaScript/C#/Vala/Dart/Rust/Go, and maybe C++.
Is anyone writing production servers in C these days? It feels like they're 100% Go and Rust.
There are notable exceptions, in particular I'm thinking about OpenBSD. I think OS dev is a pretty niche area though, especially when you're talking about OpenBSD's wide platform support, so I think it's more the exception that proves the rule than anything.
All code is machine code at bottom. Including the code that maintains abstractions convincing enough for you to think the “memory-safety” of rust or any other language is a static and guaranteed thing and not something that needs “unsafe” scaffolding to support it.
Much of the Rust compiler is written in Rust and so has fewer problems.
https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...
https://security.apple.com/blog/towards-the-next-generation-...
https://www.chromium.org/Home/chromium-security/memory-safet...
https://security.googleblog.com/2022/08/making-linux-kernel-...
Σ (memory corruption) + Σ (logic errors) ≥ Σ (logic errors)
So by reducing in 70% the costs of fixing the errors caused by those thousands of experts, as validated by the above reports, there is already a considerable reduction in software development expenses.
Lets see how serious those developers get to be around security issues, when liability finally takes off.
the point that is being made (obliquely) is that manual memory management is not possible for human beings to do effectively at scale
at scale means across a broad demographic of programmers, working on a broad set of programs
if you wanted performant and portable then C was all you had for a long time, and there is a lot of good software written in C, but that does not mean that it is a good tool in perpetuity
strcpy and pointer arithmetic are basically not possible to get right
we need to move beyond this very low level of abstraction
It's not possible for human beings to write correct code.
The hardest bug I ever found in a C program, one that took cumulative weeks of work until a tractable reproduction was found, came down to a ‘<’ that should have been ‘<=’. No language would have stopped that.
Yes, different languages have different levels of expressiveness, and can preclude or expose different kinds of errors. You'll never have a stray pointer in Python, and you'll never OOM making an accidental copy in C.
yet c code is inarguably more error-prone than basically any other language
Of course, the errors that do get through might be more severe in C than in python, but not always.
After all, the most expensive and destructive RCE ever was in a piece of Java software.
In that case this could have been caught with more careful unit tests, which would have exercised the erroneous condition, and potentially with fuzzing to excite corner cases. C is... not great for either of these.
If I wrote inline Markdown documentation for part of the Rust code with an example, cargo test will try to build my example, and check it works - not much good having a purported "example" which doesn't even work, is it? And yet many languages don't do this.
Fuzzing is still not part of the default Rust tooling.
"it works" is factually not true, look at ~any CVE
In early 1980's it was only running Bell Lab's world and a couple of universities that got hold of the source tapes.
I agree that C the programming language does not help you avoid memory errors, however, saying it's impossible is too binary. People do make mistakes, whether it's copy editors missing a typo or professional chefs misremembering whether they stocked an ingredient. Projects written in C need longer periods of code review and testing, but they can be made right. The code that took us to the moon was written in assembly after all.
It's true that the community at large writes lots of bugs. But that doesn't mean some people aren't productive with the language and write a relatively low number of bugs. There are some projects with better track records at this than others.
at scale, it is not possible for humans to hand-write C programs that are free of segmentation fault class errors
this is not controversial or in any way arguable
Inb4 you move the goalposts for "at scale". This is an operating system with capability-based access control which is not something that most operating systems even have.
Also the cryptographic constraints are part of the proof system.
this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence
it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a higher-level language, with stronger guarantees
edit:
> This brings me to my next reason: I have the discipline to write C at a high level.
factually, you do not. nobody does. you think you do, until you don't. human cognition is insufficient to satisfy this requirement. "discipline" does not fix the problem.