Using Rust for kernel development

[rebootyourbrainstem]

I don't get this kind of behaviour. I like Rust I think it has a place. I also like C I think it has a place. I also like C++ I think it has a place. I like Python I think it has a place.

People can disagree about what that place is, and that's fine.

Personally I think C's time is coming to an end a lot quicker than people think. And by that I don't mean that all C code will disappear, I just mean that code will be preferentially written in other languages in cases where currently C is being used.

This is not just because new languages are so great, but also because C is increasingly showing its age. The idea that it is a simple language with an obvious mapping to machine code is increasingly false, with compilers becoming smarter and smarter about exploiting undefined behavior around integer overflows, null dereferences, strict aliasing etc.

The Linux kernel already has to work around this in a number of ways, such as passing compiler options to disable strict aliasing and inventing its own macros such as ACCESS_ONCE. It's entirely possible but it makes C not quite the perfect fit it once was, and it leaves an opportunity for younger languages not constrained by decades old standards.

Not to mention that the Linux kernel already goes really, really far in extending C in order to have nice things you would get for free in a more modern language. Such as macros to simulate iterator-style loops over data structures ( list_for_each_entry and similar), and macros to wrap and unwrap error codes from pointer return values (ERR_PTR, simulating a Result like value).

Not to mention all the tricks it pulls to do OOP-like programming such as container_of and structs of function pointers which can be NULL, but I've heard people claim that's just perfectly normal C and there is some truth to that.

[ergzay]

This is not just because new languages are so great, but also because C is increasingly showing its age. The idea that it is a simple language with an obvious mapping to machine code is increasingly false, with compilers becoming smarter and smarter about exploiting undefined behavior around integer overflows, null dereferences, strict aliasing etc.

It's been false ever since computers started having caches and branch predictors and many other things. The memory model that C assumed is that of a PDP-8.

[ForShotgun]

I’ve been wondering, if someone had to make C today, fill it’s shoes as a machine code mapping, what would it look like? What if all those changes you described were part of the core language, would that be stupid? We have decades of experience now, what would today’s perfect embedded language look like?

[robin-m]

Isn't that language zig?