> 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.

Nah, the existence of a scheduler that performs some workload better than the generic one isn't very interesting. It's a well known fact that specialized schedulers perform better. It's just that the generic one advanced enough so that it's not worth switching for most people, but that's only after you look at the hassle of managing them.

What is really interesting here is the central piece of the kernel written on Rust, and working perfectly fine.

That is exactly what I meant, thank you. That said, I would like to know the differences in those implementation details as to why it outperforms the default scheduler.