Retiring from the Rust for Linux Project – Wedson Almeida Filho
1–10 of 107 posts
Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho
#2[flagged]
Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho
#3[flagged]
> A passive-aggressive exit, but not unusual compared to other Rust drama.
By Linux kernel drama standards, it was a non-event.
You have the video segment in text, it was pretty non-technical. "NO! We don't want to encode what our assumptions are! We don't want to learn Rust. What do you mean write down our assumptions?"
Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho
#4i encourage everyone to watch the linked video [0]. reminds me of the recent non-technical arguments made in the freebsd thread [1].
git mailing lists have such a greybeard IRC vibe to them. i will, from now on, use "only accepts patches per mail" as a proxy for "not worth suggesting new ideas to" for all projects. it's a stupid proxy. correlation and causation and all that. but it's a very useful one for your sanity.
Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho
#5i encourage everyone to watch the linked video [0]. reminds me of the recent non-technical arguments made in the freebsd thread [1]. git mailing lists have such a greybeard IRC vibe to them. i will, from now on, use "only accepts patches per mail" as a proxy for "not worth suggesting new ideas to" for all projects. it's a stupid proxy. correlation and causation and all that. but it's a very useful one for your sanity…
I did, I'm actually puzzled he referenced this.
You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors.
That this discussion repeats itself can only be taken to be either:
1) Evil C programmers are stodgy and old, and can't/won't get with the program, boo!
2) The Rust minority has, as of yet, failed to properly answer what happens when C APIs change in either signature or semantics, either of which can break the Rust bindings. Some questions:
* Who tests to avoid this?
* Who's expected to fix it? The one changing the C code, who might not know Rust or a separate bindings team?
* Is there a process ? A person to contact/raise the issue with? To get help or to have the work done?
* What happens if the bindings cannot be fixed in time for the next Kernel release? Put differently, will Rust bindings changes hold back changes to the C code?
If broken bindings indeed can hold back changes, then C changes are held back by Rust and indeed then the onus is on the committer to either forego improving/evolving the C API or pick up Rust and fix the bindings also. In that case, yes, the Rust bindings will either freeze the C API or force the individual contributor to learn Rust.
That people repeat their concerns isn't an expression of stupidity any more than a result of the people driving Rust into the kernel have yet to properly communicate how they envision this process to work, I suppose.
Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho
#6I try to sit on the fence when it comes to Rust and the Linux kernel. On one end, is Rust the right choice to be included... over others such as Zig or (perhaps) Odin? Are we 10 years too soon to include a "safe language" ????
Then again, we have Linus Torvolds who, in the last 20 years, has been hell-bent against including C++ in the kernel despite backlash.. yet.. he has accepted Rust a year or so ago. He obviously sees Rust in a completely different manner compared to C++ -- even though you could write crap code in Rust as well.
I get it -- the amount of harcore C programmers are likely shrinking. This means, over time, the linux kernel will eventually have less maintainers. It seems, to me, that Linus accepts reality that he is getting older (54) and wont be the maintainer forever. The younger generation are going to be the back-bone of keeping the project alive and if they are NOT focusing their efforts on C.. then what are they focusing on?
Rust, as good as it is, does have hype riding behind it. We also have other "Nu" languages which are eventually getting their stable releases in the coming months/years. Again, is Rust the right choice?
I understand the backlash especially veterans who have put in their efforts on the kernel and have no wish to learn Rust. I am sure there are plenty of Rust people throwing their world views opinions yet barely wrote anything decent in C, if at all.
Seems like everyone has an opinion even if their views on the opposite end is lacking.
As I say I try to sit on the fence. I have not focused my efforts on Rust but I don't actively object to it. I am just skeptical it has been added too soon to the project... but that is my opinion.
Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho
#7i encourage everyone to watch the linked video [0]. reminds me of the recent non-technical arguments made in the freebsd thread [1]. git mailing lists have such a greybeard IRC vibe to them. i will, from now on, use "only accepts patches per mail" as a proxy for "not worth suggesting new ideas to" for all projects. it's a stupid proxy. correlation and causation and all that. but it's a very useful one for your sanity…
I did, I'm actually puzzled he referenced this. You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors. That this discussion repeats itself can only be taken to be either: 1) Evil C programmers are stodgy and old, and can't/won't get with the program, boo! 2) The Rust minority has, as of ye…
Why the answers to these questions are not the same as if C code was calling other C code?
Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho
#8Earlier quoted context omitted.
I did, I'm actually puzzled he referenced this. You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors. That this discussion repeats itself can only be taken to be either: 1) Evil C programmers are stodgy and old, and can't/won't get with the program, boo! 2) The Rust minority has, as of ye…
Why the answers to these questions are not the same as if C code was calling other C code?
That should be obvious ?
The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover.
If I am contributing to the Linux kernel already, I presumably have a decent grasp of C, the central abstractions in the code I am changing, the email-based patch workflow and so on. So when my code breaks adjacent code, I should have a good chance of fixing those issues also, and most often, this won't become the main body of work.
If jamming in Rust bindings means the great mass of existing contributors are forced to learn Rust, whether they wish or not, to either maintain bindings or to drop out altogether, then raising the pitchforks is not an unreasonable response.
Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho
#9They let you in, you take a shit on the floor and leave. Who is to blame?
I don't blame this guy. It's the people who let the Barbarians in, because politics.
Sometimes gates need to be kept.
Re: Retiring from the Rust for Linux Project – Wedson Almeida Filho
#10Earlier quoted context omitted.
Why the answers to these questions are not the same as if C code was calling other C code?
That should be obvious ? The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover. If I am contributing to the Linux kernel already, I presumably have a decent grasp of C, the central abstractions in the code I am changing, the email-based…
Well then raise these concerns and find a way to solve them together. Not dismiss a proven solution to real and even dangerous problems like memory unsafety.
It's unreasonable for educated grown men to react like 12yo children and resist change cause "we don't like eating our vegetables even though they are good for our health". If you actually care about the Linux kernel you will find a way forward even if that means communicating with people or even changing habits.
At the end of the day I don't think that the people that are contributing to the Linux Kernel do it out of good will but rather more about than prestige and building a resume. Or else we wouldn't have this resistance to progress.