C’mon man, this is just a textbook fallacious slippery slope argument. Rust isn’t some brand new language whose stable release was less than a year ago, it’s over a decade old now. Scheme and Lisp are interpreted languages for God’s sake, it’s borderline* impossible to use them for kernel programming.
Also I’m pretty sure the whole point of the Rust project that all this drama is centered around is to keep Rust code separate from the kernel. From what I understand the whole point is to maintain Rust bindings to the kernel API as a separate project, so that if developers want to write a driver in Rust, they can without having to rewrite those bindings themselves. But the kernel code itself will still be all C code. Now I’m not a kernel developer, and the last time I wrote a driver was for my operating systems class in university over a decade ago, so take that with a grain of salt.
* I say borderline because anything is possible with code if you’re creative enough, but anyone trying to submit Scheme or Lisp code to the Linux kernel is gonna get laughed off the Internet
Of course I don’t mean that you should introduce Lisp or Scheme into the Linux kernel. However, I don’t rule out anything when it comes to the future of programming. Kernel programming isn’t that special. If you need to make a scheduler, dynamic memory manager or an interpreter, as part of the kernel, because it solves your problem, you do it. Maybe you want the kernel to generate thread optimised FPGA and micro code on the fly? And this is done with some kind of interpreter. Who knows.
My point is that it’s probably a bad idea introduce any new language into the kernel. A new backwards compatible version of memory safe c might be a good idea though. If it can be done.
Haven’t touched the Linux kernel in 10+ years, but my guess is that a good approach is to write a new micro kernel in Rust. One that is compatible with most existing drivers and board support packages. And of course it has to maintain the userspace ABI and POSIX yada yada. Probably what the Redox project aims for, but I don’t know.
Keeping the Rust bindings in a separate project might be unnecessary though. I’m sceptic about allowing upstream drivers written in Rust just because I find that there is such a great value in sticking to one language. I also know that many kernel developers are getting old and it gets harder to learn new languages the older you get. Especially if the language comes with a decent share of sugar and bling (the minimalism of lisp and c is valuable).
If there is a problem finding driver developers that want to write C code, then sure. But breaking the flow of the senior maintainers/developers likely isn’t worth it. Unless they ask for it.
And also, I really haven’t been following this Rust in the Linux kernel debate.
Any language containing eval in its spec cannot be (fully) compiled ahead of time, you’ll need interpretation or JIT.
Also last I checked (it’s been a while) Racket compiles to bitcode and then links in a bitcode interpreter. There’s static lisp/scheme compilers but when they come across an eval, they’re going to bail and compile in a JIT compiler or interpreter to deal with that stuff.
Fair enough, but you COULD create a compiler for a a subset of the language without eval. There are so many dialects of Scheme, what’s one without eval? Evals are very much evil anyway.
There’s plenty of schemes that aren’t fully standards-compliant but I don’t think leaving out eval is common – it’s easy to implement and nothing about the standard says that it needs to run code fast.
Just wanted to point out that eval is the real static vs dynamic boundary. As to evil, sure, you shouldn’t run just any code you find without having a sandbox in place, C’s way to do the same thing is to call cc followed by dlopen, that’s way scarier, which is why people just link in lua or something instead. I guess in <currentyear> you should probably include a wasm runtime instead of using dlopen.
C’mon man, this is just a textbook fallacious slippery slope argument. Rust isn’t some brand new language whose stable release was less than a year ago, it’s over a decade old now. Scheme and Lisp are interpreted languages for God’s sake, it’s borderline* impossible to use them for kernel programming.
Also I’m pretty sure the whole point of the Rust project that all this drama is centered around is to keep Rust code separate from the kernel. From what I understand the whole point is to maintain Rust bindings to the kernel API as a separate project, so that if developers want to write a driver in Rust, they can without having to rewrite those bindings themselves. But the kernel code itself will still be all C code. Now I’m not a kernel developer, and the last time I wrote a driver was for my operating systems class in university over a decade ago, so take that with a grain of salt.
* I say borderline because anything is possible with code if you’re creative enough, but anyone trying to submit Scheme or Lisp code to the Linux kernel is gonna get laughed off the Internet
I don’t think you get my point.
Of course I don’t mean that you should introduce Lisp or Scheme into the Linux kernel. However, I don’t rule out anything when it comes to the future of programming. Kernel programming isn’t that special. If you need to make a scheduler, dynamic memory manager or an interpreter, as part of the kernel, because it solves your problem, you do it. Maybe you want the kernel to generate thread optimised FPGA and micro code on the fly? And this is done with some kind of interpreter. Who knows.
My point is that it’s probably a bad idea introduce any new language into the kernel. A new backwards compatible version of memory safe c might be a good idea though. If it can be done.
Haven’t touched the Linux kernel in 10+ years, but my guess is that a good approach is to write a new micro kernel in Rust. One that is compatible with most existing drivers and board support packages. And of course it has to maintain the userspace ABI and POSIX yada yada. Probably what the Redox project aims for, but I don’t know.
Keeping the Rust bindings in a separate project might be unnecessary though. I’m sceptic about allowing upstream drivers written in Rust just because I find that there is such a great value in sticking to one language. I also know that many kernel developers are getting old and it gets harder to learn new languages the older you get. Especially if the language comes with a decent share of sugar and bling (the minimalism of lisp and c is valuable).
If there is a problem finding driver developers that want to write C code, then sure. But breaking the flow of the senior maintainers/developers likely isn’t worth it. Unless they ask for it.
And also, I really haven’t been following this Rust in the Linux kernel debate.
Technically there’s no such thing as a compiled or interpreted language. Python compilers exist. You could write a Scheme or Lisp compiler. Racket is a Scheme that can be interpreted or compiled
Any language containing
evalin its spec cannot be (fully) compiled ahead of time, you’ll need interpretation or JIT.Also last I checked (it’s been a while) Racket compiles to bitcode and then links in a bitcode interpreter. There’s static lisp/scheme compilers but when they come across an eval, they’re going to bail and compile in a JIT compiler or interpreter to deal with that stuff.
Fair enough, but you COULD create a compiler for a a subset of the language without eval. There are so many dialects of Scheme, what’s one without eval? Evals are very much evil anyway.
There’s plenty of schemes that aren’t fully standards-compliant but I don’t think leaving out eval is common – it’s easy to implement and nothing about the standard says that it needs to run code fast.
Just wanted to point out that eval is the real static vs dynamic boundary. As to evil, sure, you shouldn’t run just any code you find without having a sandbox in place, C’s way to do the same thing is to call
ccfollowed bydlopen, that’s way scarier, which is why people just link in lua or something instead. I guess in <currentyear> you should probably include a wasm runtime instead of usingdlopen.