Comment by reactordev
10 months ago
The problem is aging code sours like milk.
I empathize but we need to have people take over these initiatives and refactor them into something easier the maintain. Not saying introduce a new language or anything but change how we fundamentally look at “The Kernel”. I think reducing scope and making it so hardware providers must maintain their drivers is a good start. If your toolchain doesn’t suffice, create a new tool.
If rust is so much better, create a new kernel in rust and force a paradigm shift. I think we can do better than bicker and fight over it and post email chains about it. Bring solutions. Tech debt is just OpEx to everyone else.
> create a new kernel in rust and force a paradigm shift.
And then what?
A kernel by itself isn't very useful. Even if your kernel is somehow superior in every way, you need software to target it, so to be a successful replacement for linux you basically have to be completely compatible with any software that currently runs on linux, which not only means a massive amount of work just to keep up with changes in linux, but constraints on your own design.
And then there is hardware support. If you are a fledgling project, how do you get hardware vendors to write drivers for you?
No part of this explains why Linux should be changed. It just means the new project has a lot of work to do.
>Bring solutions. Tech debt is just OpEx to everyone else.
What if there was a rust compiler to C, that produced like readable, compliant C code for the kernel. And then developers that want to work in rust can publish their original rust code to some third party location, so the reviewers have no idea if the C code they receive it was originally written in rust or not.
The output of a compiler produce unidiomatic code. And if the C gets edited you need to back port to Rust which is more work and may be impossible.
Try what you said with even well align languages like TS and JS and it would be hard to work with.
And what happens if somebody starts modifying that C code? Even a one way translator like you describe could be a challenge, making it two way seems close to impossible.
The problem is that the C guys don't want to define certain semantics. Currently "it works", but Rust wants invariants.
> making it so hardware providers must maintain their drivers is a good start
How do you propose that happens?
There is redox os
It's a cool idea but it's licensed MIT instead of GPL or something copyleft so I won't contribute to it.
Rust-only ecosystem would be pretty cool though. It may be worth just forking linux for the sake of compatibility, and keeping the license going. I don't see a future otherwise.
I'd also like to see better compiler diversity. Maybe once gccrs rolls around we will see different attitudes around rust emerge, compared to C/C++ which have more distributed development.
The Rust community does seem to be more focused on non-copyleft licenses, do you have any ideas why that is?
5 replies →