I could really feel the (not expressed in public) rust in kernel tensions at FOSDEM this year. I heard it expressed in one-to-one discussions several times. Concerns and sighs. I'm not jealous of that situation.
I’m not sure I understand what all the fuss is about. Where do the tensions stem from? Do some developers feel it is being imposed on them? Do others feel unwelcome?
@teotwaki all of it. The introduction of a new language adds a lot of sand in the machinery. Borders. Added complexity. Lots of more to learn and keep track of. And the ones FOR this see the "others" to be old farts preventing evolution etc.
I think that’s pretty fair. FOSS projects rarely are shining beacons of change management done well.
I’m not sure I understand why so many people “in charge” of adopting/managing #Rustlang in some projects appear to despise the language so much. Feels very counter intuitive to me.
@teotwaki I don't think being against rust in a particular context should necessarily be seen as being "against the language" though. Just against it being used like that. In that context. In that way.
@teotwaki I haven't been there, but based on what I remember from LWN comments last time this hit the news (correct me if I'm wrong):
One of the contention point was that a subsystem maintainer needs to be able to independently refactor internal APIs, which includes fixing all places that use those APIs, and if one of those places is written in Rust, then a maintainer either needs to learn Rust. Or get someone else's help, but that's not independent.
@teotwaki the complexity also adds up when one is doing 4-year+ LTS editions for (paying) customers as suddenly one needs to start backporting the Rust parts too and need somebody who gets how to do that, how to test it, etc etc, while the C-team is in place maybe for two decades already and doing great without that hassle. But I do see the advantages of a language like Rust, more in the golang camp here for systems things though, but will re-evaluate Rust
another way to view this what is different about extending kernel with rust versus all the other existing ways (C++, assembly, pykernel, lua-kernel, gokernel) ... if the fear is the whole thing is going towards rust then I would look at BeOS as an example (eg. C++) ... from a portability standpoint rust probably has an edge and thats what makes people nervous in that everything could be rewritten ... personally I have no horse in this race and I would rather prefer heterogeneity
Sebastian Lauwers
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Sebastian Lauwers • • •Sebastian Lauwers
in reply to daniel:// stenberg:// • • •I think that’s pretty fair. FOSS projects rarely are shining beacons of change management done well.
I’m not sure I understand why so many people “in charge” of adopting/managing #Rustlang in some projects appear to despise the language so much. Feels very counter intuitive to me.
daniel:// stenberg://
in reply to Sebastian Lauwers • • •Sebastian Lauwers
in reply to daniel:// stenberg:// • • •Wolf480pl
in reply to daniel:// stenberg:// • • •@teotwaki
I haven't been there, but based on what I remember from LWN comments last time this hit the news (correct me if I'm wrong):
One of the contention point was that a subsystem maintainer needs to be able to independently refactor internal APIs, which includes fixing all places that use those APIs, and if one of those places is written in Rust, then a maintainer either needs to learn Rust. Or get someone else's help, but that's not independent.
Jeroen Massar
in reply to daniel:// stenberg:// • • •Jim Fuller
in reply to daniel:// stenberg:// • • •