Re: The Case for Rust (in any system)
- In reply to: Karl Denninger : "Re: The Case for Rust (in any system)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 05 Sep 2024 21:58:41 UTC
On 2024-09-05 21:20, Karl Denninger wrote: > On 9/5/2024 14:09, Alan Somers wrote: > >> By now I expect that most of you have seen the long list of new >> security advisories that just came out. Strikingly, all were the >> result of memory handling errors. And none of them wouldn't have >> happened if their respective programs had been written in a >> memory-safe language. >> > > To argue that the answer is to put a diaper on a child so it does not > drop excrement on the carpet is to forever treat said human as an > infant without control of its sphincters. While such an answer might > be necessary for a short period of time in all young human creatures > it also should be obvious that we are all walking around today without > them and thus said prophylaxis is to cover for a deficiency rather > than a necessity. > This argument has been had since Rust was first created. Rust was created to be a solution to a real problem that cannot be solved by "just writing better C code". Rust was created because projects like Chromium found that 70% of their bugs are memory related.[0] The amount of time wasted discovering, debugging and fixing these bugs is unreal. These bugs and vulnerabilities are inevitable if you use a language like C no matter the skill of your developers. I also wanted to speak to the "C is a dying language" argument. I am a third-year CS bachelor student at one of the best technical universities in the Netherlands. Our bachelor never did cover much C, but after the last year even the low level OS course has been ported to Rust code. Our memory management and concurrency courses now also offer Rust examples and exercises. That means that our CS students are now primarily taught Python, Java, Rust and Assembly. Students are expected to somewhat be able to read C code but are never asked to write any. Of the students that I know that actually program in their free time, all of them do so in Rust. I don't even know a single student who can even write C. We take about 400 new students each year. I love C but writing it is cumbersome and doing it correctly even more so. There's a major learning curve which few new programmers are even starting on. Contributing to a C codebase is also much more cumbersome. They each have their own rules, own standards and conventions and their own build system. With Rust you know what to expect. And as for the speed of Rust, there *can* be some overhead by the runtime. But Rust has so much fewer footguns that you will inevitably write more performant code. If you use the standard libraries reallocating vectors, hashmaps etc you will be using the fastest algorithm known and possibly using SIMD or other architecture specific instructions. It's developers like me who will have to maintain codebases like FreeBSD in 10 or 20 years and I've personally written magnitudes more Rust than C. For me there's no point in starting a project in C other than giving myself a challenge. Is it possible for FreeBSD to incrementally start accepting Rust code? I would think so. I recently spoke with zirias on the forums about the potential of a dedicated "authentication service" which would allow unprivileged processes to verify user authentication without ever needing to read the password store (as an alternative to pam_unix(8)). In my opinion a daemon like this would be a prime candidate for writing in Rust. The major downside of this is that I expect few FreeBSD developers currently know Rust. But I think it will be much easier to find new Rust contributors than C contributors and this will even more so in the future. Rust is absolutely thriving in FOSS right now. And to the developers who don't know Rust: It shouldn't take long for an experienced C developer to learn the basics. There is already an abundance of Rust literature including the Rust book[1]. And you can play with Rust in the playground[2]. [0]: https://www.chromium.org/Home/chromium-security/memory-safety/ [1]: https://doc.rust-lang.org/stable/book/ [2]: https://play.rust-lang.org