being new does not mean you do not have the right to develop the same way everybody else is. they did not start these issues, there were C people causing issues for no reason other than not liking rust that started it.
Have you actually read the reasoning behind the anti-rust? it has absolutely nothing to do with it being rust. They would have just as many issues with it if it was Go instead.
I have seen the reasoning they are actually presenting, and it is just various versions of “but I don’t want this to be here” even though they have the option of not interacting with it. nobody is forcing maintainers to support rust code in the thing they maintain, they just can’t prevent rust code from interfacing with it. their arguments are based purely on not wanting to interact with rust but they don’t have to, so they are wrong to block it.
The issue is with creating more work for others. Supporting a multi-language toolchain and build environment is a lot more work than a single language one. The R4L folks have made it their mission to shoehorn Rust into the kernel and they’ve explicitly stated that they will not avoid making more work for others. This has upset some longterm maintainers who did not sign up for additional workload.
Linus Torvalds has been accused of many things but he has always been loyal to his best maintainers. That’s been a big key to his success.
I think R4L may very well be the right idea in the long term but it should absolutely be thoroughly discussed what will be rust and what will remain C.
Introducing a new language with no guidelines is guaranteed to cause issues in the long term and likely significantly slow down development.
being new does not mean you do not have the right to develop the same way everybody else is. they did not start these issues, there were C people causing issues for no reason other than not liking rust that started it.
Have you actually read the reasoning behind the anti-rust? it has absolutely nothing to do with it being rust. They would have just as many issues with it if it was Go instead.
I have seen the reasoning they are actually presenting, and it is just various versions of “but I don’t want this to be here” even though they have the option of not interacting with it. nobody is forcing maintainers to support rust code in the thing they maintain, they just can’t prevent rust code from interfacing with it. their arguments are based purely on not wanting to interact with rust but they don’t have to, so they are wrong to block it.
But did you read the exchange this conversation is about? It sounds like you’re operating on month-old headlines.
The issue is with creating more work for others. Supporting a multi-language toolchain and build environment is a lot more work than a single language one. The R4L folks have made it their mission to shoehorn Rust into the kernel and they’ve explicitly stated that they will not avoid making more work for others. This has upset some longterm maintainers who did not sign up for additional workload.
Linus Torvalds has been accused of many things but he has always been loyal to his best maintainers. That’s been a big key to his success.
I think R4L may very well be the right idea in the long term but it should absolutely be thoroughly discussed what will be rust and what will remain C.
Introducing a new language with no guidelines is guaranteed to cause issues in the long term and likely significantly slow down development.