People doing open-source work often feel very tribal about their code and block ideas that are good but threaten their position in the community. Essentially same thing as office politics except it's not about money, it's about personal pride.
I’m not really sure what point you’re making. All I see there is - or was - some unclear management within Linux itself.
- There was an experiment to have rust in Linux. It got provisional approval from Linus.
- Some people in the Linux kernel blocked essentially any changes being made to make the rust experiment able to succeed.
- Some people who were trying to get rust into Linux got frustrated. Some quit as a result.
- Eventually Linus stepped in and told everyone to play nice.
This whole drama involved like 5 people. It’s not “the majority of the rust community”. And it kinda had nothing to do with rust the language. It was really a management / technical leadership challenge. And it seems like it’s been addressed by leadership stepping in and giving clearer guidelines around how rust and C should interoperate, both at a technical and interpersonal level.
So what’s your point? Is rust bad because some people had an argument about it on the Linux kernel mailing list about it? ‘Cos uh, that’s not exactly a new thing.
The "provide value" argument can be used for anything. Modern software politics and foundation sponsorship pressure are so complex that this argument may not even be true.
It may be true in this case, but certainly you have seen corporate bloat being added to "open" source projects before.
> Modern software politics and foundation sponsorship pressure are so complex that this argument may not even be true.
May not, or may yes. As far as I know with my own interactions with the Linux kernel community, is that it's very different from typical "modern software politics", at least different enough that I'd make the claim they're special from the other communities.
If there is any community I'd assume makes most of their choices disregarding politics or pressures and purely on technical measures, it would be the Linux kernel community. With that said, no person nor community is perfect, but unless there is some hard evidence pointing to that the Linux people were forced to accept Rust into the kernel for whatever reason, then at least I'd refrain from believing in such theories.
You're right that I'm appealing to authority, but that doesn't make my argument invalid.
The people who decided rust has value in the kernel are linux kernel developers. Ie, traditional C developers who see value in using rust in linux. Rust in linux has caused plenty of headaches. If rust didn't add commensurate value to make the trouble worth it, it wouldn't be getting adopted.
They wrote their own language (C) too. They invented a new language because the current crop of languages didn't suit their needs. Your argument ignores the parts of history that are inconvenient and highlights the ones that you think support it.
"Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own."
People arguing for UNIX/C, also tend to forget the decade of systems languages that predates them, starting with JOVIAL in 1958.
They also forget that after coming up with UNIX/C, they went on to create Plan 9, which was supposed to use Alef, abandoned its designed, later acknowledege lack of GC as an key issue, created Inferno and Limbo, finalizing with contributions to Go's original design.
"Alef appeared in the first and second editions of Plan 9, but was abandoned during development of the third edition.[1][2] Rob Pike later explained Alef's demise by pointing to its lack of automatic memory management, despite Pike's and other people's urging Winterbottom to add garbage collection to the language;[3] also, in a February 2000 slideshow, Pike noted: "…although Alef was a fruitful language, it proved too difficult to maintain a variant language across multiple architectures, so we took what we learned from it and built the thread library for C."[4]"
If rust didn’t provide value to the Linux kernel, there’s no way it would have made out of the experimental phase.
Rust isn’t an invading tribe. It’s just a tool.
> Rust isn’t an invading tribe
People doing open-source work often feel very tribal about their code and block ideas that are good but threaten their position in the community. Essentially same thing as office politics except it's not about money, it's about personal pride.
I'm sure that submitting a PR to a Rust project to rewrite parts in Ada/SPARK would be met with great enthusiasm.
8 replies →
Does this image count as significant tribalism in parts of the Rust community?
https://github.com/microsoft/typescript-go/discussions/411#d...
Taken from the above Github discussion regarding Go and Typescript.
https://imgur.com/a/efdIuWb
2 replies →
[flagged]
Didn't Hector step down essentially as a direct result of that behavior? https://www.phoronix.com/news/Asahi-Linux-Lead-No-Upstream
Do you have an example of other R4L maintainers harassment? Because you've spammed the same single example 3-4 times on this post alone.
2 replies →
I’m not really sure what point you’re making. All I see there is - or was - some unclear management within Linux itself.
- There was an experiment to have rust in Linux. It got provisional approval from Linus.
- Some people in the Linux kernel blocked essentially any changes being made to make the rust experiment able to succeed.
- Some people who were trying to get rust into Linux got frustrated. Some quit as a result.
- Eventually Linus stepped in and told everyone to play nice.
This whole drama involved like 5 people. It’s not “the majority of the rust community”. And it kinda had nothing to do with rust the language. It was really a management / technical leadership challenge. And it seems like it’s been addressed by leadership stepping in and giving clearer guidelines around how rust and C should interoperate, both at a technical and interpersonal level.
So what’s your point? Is rust bad because some people had an argument about it on the Linux kernel mailing list about it? ‘Cos uh, that’s not exactly a new thing.
1 reply →
[flagged]
https://www.redox-os.org/
1 reply →
The "provide value" argument can be used for anything. Modern software politics and foundation sponsorship pressure are so complex that this argument may not even be true.
It may be true in this case, but certainly you have seen corporate bloat being added to "open" source projects before.
> Modern software politics and foundation sponsorship pressure are so complex that this argument may not even be true.
May not, or may yes. As far as I know with my own interactions with the Linux kernel community, is that it's very different from typical "modern software politics", at least different enough that I'd make the claim they're special from the other communities.
If there is any community I'd assume makes most of their choices disregarding politics or pressures and purely on technical measures, it would be the Linux kernel community. With that said, no person nor community is perfect, but unless there is some hard evidence pointing to that the Linux people were forced to accept Rust into the kernel for whatever reason, then at least I'd refrain from believing in such theories.
> If rust didn’t provide value to the Linux kernel, there’s no way it would have made out of the experimental phase.
That’s “appeal to authority” fallacy.
You're right that I'm appealing to authority, but that doesn't make my argument invalid.
The people who decided rust has value in the kernel are linux kernel developers. Ie, traditional C developers who see value in using rust in linux. Rust in linux has caused plenty of headaches. If rust didn't add commensurate value to make the trouble worth it, it wouldn't be getting adopted.
Pointing out that something was iterated upon and adopted in the place it was introduced is now a fallacy, amazing.
1 reply →
They wrote their own language (C) too. They invented a new language because the current crop of languages didn't suit their needs. Your argument ignores the parts of history that are inconvenient and highlights the ones that you think support it.
You mean as in "having fun"?
"Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own."
-- https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist...
People arguing for UNIX/C, also tend to forget the decade of systems languages that predates them, starting with JOVIAL in 1958.
They also forget that after coming up with UNIX/C, they went on to create Plan 9, which was supposed to use Alef, abandoned its designed, later acknowledege lack of GC as an key issue, created Inferno and Limbo, finalizing with contributions to Go's original design.
"Alef appeared in the first and second editions of Plan 9, but was abandoned during development of the third edition.[1][2] Rob Pike later explained Alef's demise by pointing to its lack of automatic memory management, despite Pike's and other people's urging Winterbottom to add garbage collection to the language;[3] also, in a February 2000 slideshow, Pike noted: "…although Alef was a fruitful language, it proved too difficult to maintain a variant language across multiple architectures, so we took what we learned from it and built the thread library for C."[4]"
-- https://en.wikipedia.org/wiki/Alef_(programming_language)
UNIX and C creators moved on, apparently those that whorship them haven't got the history lesson up to date.
for a project like unix at the time and even linux now I think "having fun" is absolutely one of their needs.
1 reply →
"invading"
I'm sure your choice of words helps the discussion.
Back when the primary consumers of the kernel were other researchers. Not billions of machines running our society.
the kernel is the value part, not the language that the kernel is written in