> [Filho said]: "Almost four years into this, I expected we would be past tantrums from respected members of the Linux kernel community. I just ran out of steam to deal with them, as I said in my email."
I'm not surprised Wedson feels this way.
It's irresponsible to leave devs out to dry like this. If the Linux Foundation hires Linus and others and pays them gobs and gobs of dough, they should lead. If you set the technical direction, then you need to make it clear every day, that's where we are going. Passive aggression is fine for bad marriages and failed companies, but this is a multi-billion dollar business. Someone needs to be the grown up in the room.
Rust in the kernel is still an experiment, you can't lead in a direction that doesn't exist. The "nontechnical nonsense" is actually the more important and more difficult part of software development.
My feeling about Rust is that it's a playground language where many ideas are tried and insights can be formed, but it needs to be distilled down to something simpler with a stable ABI to be used for something like Linux. Moreover, why be "afraid some other kernel will do to it what it did to Unix"? Wouldn't it be great if Linux could be replaced by something better? Why not pursue that direction?
Rust has used reaserch from 80s and 90s languages. The result may seem novel because the programming language theory and languages that Rust copied are not well known among systems programmers. The ideas are old, Rust added the polish and packaging of the features with a focus on practical non-reaserch use.
Rust isn't that new any more. 1.0 has been released almost a decade ago.
What features do you rely on? This is effectively the opposite of my experience, which is why I am curious: even our embedded OS at work is almost free of nightly features, and everything higher in the stack has been on stable for a long time. Always interested in learning how experiences differ!
Yes, for that OS we’re using asm_const, which is almost stable, naked functions, and used_with_arg, which is linker related. We also use array_methods but that could be polyfilled, if the other three were stable.
crates.io sees about 13% of requests from nightly compilers, although that may be biased by CI tests that just check for future compatibility rather than needing nightly features.
For application development nightly hasn't been necessary for many years now. Places where people use nightly are increasingly just nice to haves and small optimizations.
> Rust in the kernel is still an experiment, you can't lead in a direction that doesn't exist.
"There go my people, I must find out where they are going so I can lead them."
> [B]ut it needs to be distilled down to something simpler with a stable ABI to be used for something like Linux.
Why? I really not understanding a practical reason why that would be necessary.
> Moreover, why be "afraid some other kernel will do to it what it did to Unix"? Wouldn't it be great if Linux could be replaced by something better? Why not pursue that direction?
It's mostly a ridiculous alternative in the here and now. People use Linux, right now, although a fine thing to do. People want a memory safe language to write drivers and filesystems in the kernel, right now. It makes lots of sense to write use Rust in the Linux kernel, right now.
So maybe? It still takes lots of work of make something like that happen?
I'd love if the entire RfL team played hard ball, relicensed their contributions as MIT/ISC/BSD, and moved to FreeBSD or illumos or began contributing to RedoxOS, but I wouldn't expect anything new for awhile.
I'm not surprised Wedson feels this way.
It's irresponsible to leave devs out to dry like this. If the Linux Foundation hires Linus and others and pays them gobs and gobs of dough, they should lead. If you set the technical direction, then you need to make it clear every day, that's where we are going. Passive aggression is fine for bad marriages and failed companies, but this is a multi-billion dollar business. Someone needs to be the grown up in the room.