On Tue, Jan 23, 2024 at 10:58:09PM +0000, David Howells wrote: > Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > I really want this to happen. It's taken 50 years, but we finally have > > a programming language that can replace C for writing kernels. > (I'm not sure Matthew wants to rewrite the existing kernel piece in Rust, my read is more like he feels Rust can be used for new or experimental stuffs) > I really don't want this to happen. Whilst I have sympathy with the idea that > C can be replaced with something better - Rust isn't it. The syntax is awful. > It's like they looked at perl and thought they could beat it at inventing > weird and obfuscated bits of operator syntax. Can't they replace the syntax > with something a lot more C-like[*]? > Isn't the feeling on the syntax (like, hate or can live with) really based on personal experience? I'd rather not use this as an argument, since I can find syntax haters for every language ;-) > But quite apart from that, mass-converting the kernel to Rust is pretty much > inevitably going introduce a whole bunch of new bugs. > Desite whether this is what gets proposed here, I do really want to agree with you, but I'm not able to tell whether this is an educational prediction or unnecessary worry, since I could say the same thing for every patchset that adds new features ;-) To me, it doesn't matter which language wins the "best C replacement for kernel programming" award, the lessons we learn from Rust-for-Linux will likely apply for any other "high-level" language. Hope that we can all agree on that it's all OK that people want to try out new stuffs and see if they *actually* work. Because then we can discuss on something concrete and objective. Regards, Boqun > David > > [*] That said, we do rather torture the C-preprocessor more than we should > have to if the C language was more flexible. Some of that could be alleviated > by moving to C++ and using some of the extra features available there. That > would be an easier path than rusting the kernel. > >
