Linux is taking in Rust here and there already, I don't think that alone is interesting and the parent point is that the same thing could have been written in C.
I'm not sure if you mean "Linux taking in Rust is not interesting" or "This component in Rust (apart from implementation details) is interesting", but I absolutely think both are interesting.
For the first (which you may agree with, IDK), Linux has refused to take C++, etc. as languages.
For the second, my understanding is that the kernel support was kind of a provisional trial integration of Rust, and that no essential components were to be written in Rust. Now an alternate scheduler isn't a an essential component, but it the first thing I've heard of that would get me to compile a rust component for the kernel.
Edit: wait, wait, wait, this is eBPF driven? Does that even need the kernel linux support? This becomes even more interesting to me. Sounds like we could maybe see eBPF filters Go or Nim soon if that's the case.
Comments
I'm not sure if you mean "Linux taking in Rust is not interesting" or "This component in Rust (apart from implementation details) is interesting", but I absolutely think both are interesting.
For the first (which you may agree with, IDK), Linux has refused to take C++, etc. as languages.
For the second, my understanding is that the kernel support was kind of a provisional trial integration of Rust, and that no essential components were to be written in Rust. Now an alternate scheduler isn't a an essential component, but it the first thing I've heard of that would get me to compile a rust component for the kernel.
Edit: wait, wait, wait, this is eBPF driven? Does that even need the kernel linux support? This becomes even more interesting to me. Sounds like we could maybe see eBPF filters Go or Nim soon if that's the case.