3 ms·

I think this is gonna be a hard sell. The standard economic analysis of cooperatives is that, being run by their employees, they find it hard to embrace disrup

by dash2 5y ago

I think this is gonna be a hard sell. The standard economic analysis of cooperatives is that, being run by their employees, they find it hard to embrace disruptive change (e.g. change which involves firing people). Hence, you probably buy your food from a shareholder-owned business, not an employee-owned cooperative. Linux is a bit like a cooperative in that decisions are made by the software engineers, not by shareholders or managers. In particular, most Linux contributors are probably heavily invested in C. If Rust gets the big boost of being allowed into the kernel, that could make C - and their own skills - be perceived as less valuable, maybe even obsolete eventually. I'll do some economic imperialism here, and claim that Rust's technical merits or otherwise are a second-order issue. Linux developers have an interest in keeping C dominant, so that will probably happen.

jleahy 5y ago
The average Linux kernel developer is probably confident in 5-10 languages, and I can’t imagine they would really have trouble picking up Rust. That kind of argument might hold for the average junior javascript dev, but kernel developers are normally an experienced bunch and C is rarely learnt today as a sole language.
- paulddraper 5y ago
  Be that as it may, thanks to selection bias, the vast majority of kernel devs still probably prefer working in C.
- dash2 5y ago
  Yes, I'm sure they're extremely smart, but equally, they are deeply expert in C, and it is not that easy to become deeply expert in Rust (or any other language). Even smart people can't just pick up new tools in a day.
  - Mic92 5y ago
    They way rust is used in the kernel is a lot more constrained in scope and APIs compared to normal userland rust and hence easier to learn. A lot of added rust API are also just high-level abstraction of already existing concepts/code used in the kernel.
tialaramex 5y ago
I think pragmatism wins. It seems very likely to me that a safer alternative which has similar characteristics to Linux attracts most of the users and contributors and thus renders Linux irrelevant. Once upon a time it seemed like there was no practical way that could be done, but today not so much. This is in some sense a co-operative, but it's first and foremost technical. A co-operative farm feels a duty to consider Jim's irrational dislike of corn when deciding what the farm should grow. On the one hand, this land is very suitable for corn, there is a need for it, and they have all the equipment, on the other hand, Jim hates corn. But the technical focus means that although Jim's dislike of corn is respected in the LKML, it doesn't override the technical decision that clearly we should grow corn. Among non-experts you can end up with lengthy arguments about how "good" C programmers don't make the mistakes Rust defends against. Those arguments won't last five minutes on the LKML because everybody there considers themselves a "good C programmer" and has made those mistakes. One big technical obstacle to Rust was allocation. In C all your allocation is explicit, so that's kernel policy. A line of code that seems to simply assign a to b, for example, must not in fact secretly allocate resources. The ordinary day-to-day Rust you write does have some implicit allocation, but the Rust-for-Linux people landed changes so that you can have core and much of alloc in Linux but lose features that have implicit allocation. Unless there's a hitherto unforeseen technical blocker, Rust in Linux seems inevitable at this point. They have a list of unstable features they're requiring -- expect over the next months either things get crossed off (having meanwhile become stable) or removed from Rust-for-Linux in favour of an alternative. Unlike Firefox I'm guessing Linus has no appetite for living on the bleeding edge, so I think once Rust-for-Linux is just stable Rust, it'll make its way towards the Linus tree.
- pjmlp 5y ago
  https://fuchsia.dev/ https://fuchsia.dev/ and https://source.android.com/ https://source.android.com/ will happily keep using C++ and Rust. Regardless of what Linux kernel team decides to do.
pjmlp 5y ago
C was born to make UNIX portable (V4), so any UNIX clone will have a symbiotic relation with C, which kind of boils down to your line of argumentation. I see Rust having more success in OSes, and platforms, that aren't so reliant on being UNIX clones.

by dash2 5y ago

jleahy 5y ago

The average Linux kernel developer is probably confident in 5-10 languages, and I can’t imagine they would really have trouble picking up Rust. That kind of argument might hold for the average junior javascript dev, but kernel developers are normally an experienced bunch and C is rarely learnt today as a sole language.

paulddraper 5y ago
Be that as it may, thanks to selection bias, the vast majority of kernel devs still probably prefer working in C.
dash2 5y ago
Yes, I'm sure they're extremely smart, but equally, they are deeply expert in C, and it is not that easy to become deeply expert in Rust (or any other language). Even smart people can't just pick up new tools in a day.
- Mic92 5y ago
  They way rust is used in the kernel is a lot more constrained in scope and APIs compared to normal userland rust and hence easier to learn. A lot of added rust API are also just high-level abstraction of already existing concepts/code used in the kernel.

tialaramex 5y ago

I think pragmatism wins. It seems very likely to me that a safer alternative which has similar characteristics to Linux attracts most of the users and contributors and thus renders Linux irrelevant. Once upon a time it seemed like there was no practical way that could be done, but today not so much. This is in some sense a co-operative, but it's first and foremost technical. A co-operative farm feels a duty to consider Jim's irrational dislike of corn when deciding what the farm should grow. On the one hand, this land is very suitable for corn, there is a need for it, and they have all the equipment, on the other hand, Jim hates corn. But the technical focus means that although Jim's dislike of corn is respected in the LKML, it doesn't override the technical decision that clearly we should grow corn. Among non-experts you can end up with lengthy arguments about how "good" C programmers don't make the mistakes Rust defends against. Those arguments won't last five minutes on the LKML because everybody there considers themselves a "good C programmer" and has made those mistakes. One big technical obstacle to Rust was allocation. In C all your allocation is explicit, so that's kernel policy. A line of code that seems to simply assign a to b, for example, must not in fact secretly allocate resources. The ordinary day-to-day Rust you write does have some implicit allocation, but the Rust-for-Linux people landed changes so that you can have core and much of alloc in Linux but lose features that have implicit allocation. Unless there's a hitherto unforeseen technical blocker, Rust in Linux seems inevitable at this point. They have a list of unstable features they're requiring -- expect over the next months either things get crossed off (having meanwhile become stable) or removed from Rust-for-Linux in favour of an alternative. Unlike Firefox I'm guessing Linus has no appetite for living on the bleeding edge, so I think once Rust-for-Linux is just stable Rust, it'll make its way towards the Linus tree.

pjmlp 5y ago
https://fuchsia.dev/ https://fuchsia.dev/ and https://source.android.com/ https://source.android.com/ will happily keep using C++ and Rust. Regardless of what Linux kernel team decides to do.

pjmlp 5y ago

C was born to make UNIX portable (V4), so any UNIX clone will have a symbiotic relation with C, which kind of boils down to your line of argumentation. I see Rust having more success in OSes, and platforms, that aren't so reliant on being UNIX clones.