Some pretext: I'm a Rust skeptic and tired of Rust Evangelism Task Force and Rewrite in Rust movements.
---
Yes. I remember that message.
Also let's not forget what marcan said [0] [1].
In short, a developer didn't want their C codebase littered with Rust code, which I can understand, then the Rust team said that they can maintain that part, not complicating his life further (Kudos to them), and the developer lashing out to them to GTFO of "his" lawn (which I understand again, not condone. I'd have acted differently).
This again boils down to code quality matters. Rust is a small child when compared to the whole codebase, and weariness from old timers is normal. We can discuss behaviors till the eternity, but humans are humans. You can't just standardize everything.
Coming to marcan, how he behaved is a big no in my book, too. Because it's not healthy. Yes, the LKML is not healthy, but this is one of the things which makes you wrong even when you're right.
I'm also following a similar discussion list, which has a similar level of friction in some matters, and the correct thing is to taking some time off and touching grass when feeling tired and being close to burnout. Not running like a lit torch between flammable people.
One needs to try to be the better example esp. when the environment is not in an ideal shape. It's the hardest thing to do, but it's the most correct path at the same time.
One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring that there is a specification (the specification donated by/from Ferrous Systems, might have significant issues), or prioritizing the kernel higher than Rust.
If I had been enthusiastic about Rust, and wanted to see if it could maybe make sense for Rust to be part of the Linux kernel[0], I would probably had turned my attention to gccrs.
What is then extra strange is that there have been some public hostility against gccrs (WIP Rust compiler for gcc) from the rustc (sole main Rust compiler primarily based on LLVM) camp.
It feels somewhat like a corporate takeover, not something where good and benign technology is most important.
And money is at stake as well, the Rust Foundation has a large focus on fundraising, like how their progenitors at Mozilla/Firefox have or had a large focus on fundraising. And then there are major Rust proponents who openly claim, also here on Hacker News, that software and politics are inherently entwined.
[0]: And also not have it as a strict goal to get Rust into the kernel, for there might be the possibility that Rust was discovered not to be a good fit; and then one could work on that lack of fit after discovery and maybe later make Rust a good fit.
I think the main issue is that it never was about how rust programmers should write more rust. Just like a religion it is about what other people should do. That's why you see so many abandoned very ambitious rust projects to tackle x,y or z now written in C to do them all over again (and throw away many years of hardening and bug fixes). The idea is that the original authors can be somehow manipulated into taking these grand gifts and then to throw away their old code. I'm waiting for the SQLite rewrite in rust any day now. And it is not just the language itself, you also get a package manager that you will have to incorporate into your workflow (with risks that are entirely its own), new control flow models, terminology and so on.
Rust should have done exactly one thing and do that as good as possible: be a C replacement and do that while sticking as close as possible to the C syntax. Now we have something that is a halfway house between C, C++, JavaScript (Node.js, actually), Java and possibly even Ruby with a syntax that makes perl look good and with a bunch of instability thrown in for good measure.
It's as if the Jehova's witnesses decided to get into tech and to convince the world of the error of its ways.
>One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring that there is a specification (the specification donated by/from Ferrous Systems, might have significant issues), or prioritizing the kernel higher than Rust.
On the flip side there have been many downright sycophants of only C in the Linux kernel and have done every possible action to throttle and sideline the Rust for Linux movement.
There have been multiple very public statements made by other maintainers that they actively reject Rust in the kernel rather than coming in with open hearts and minds.
Why are active maintainers rejecting parts of code that are under the remit of responsibility?
Personally, I observe that Rust is forced everywhere in the Linux ecosystem. One of my biggest concerns is uutils, mostly because of the permissive license it bears. The Linux kernel and immediate userspace shall be GPL licensed to protect the OS in my opinion.
I have a personal principle of not using LLVM-based languages (equal parts I don't like how LLVM people behave against GCC and I support free software first and foremost), so I personally watch gccrs closely, and my personal ban on Rust will be lifted the day gccrs becomes an alternative compiler.
This brings me to the second biggest reservation about Rust. The language is moving too fast, without any apparent plan or maturing process. Things are labeled unstable, there's no spec, and apparently nobody is working on these very seriously, which you also noted.
I don't understand why people are hostile against gccrs? Can you point me to some discussions?
> It feels somewhat like a corporate takeover, not something where good and benign technology is most important.
As I noted above, the whole Rust ecosystem feels like it's on a crusade, esp. against C++. I write C++, and I play with pointers a lot, and I understand the gotchas, and also the team dynamics and how it's becoming harder to write good software with larger teams regardless of programming language, but the way Rust propels itself forward leaves a very bad taste in the mouth, and I personally don't like to be forced into something. So, while gccrs will remove my personal ban, I'm not sure I'll take the language enthusiastically. On the other hand, another language Rust people apparently hate, Go, ticks all the right boxes as a programming language. Yes, they made some mistakes and turned back from some of them at the last moment, but the whole ordeal looks tidier and better than Rust.
In short, being able to borrow-check things is not a license to push people around like this, and they are building themselves a good countering force with all this enthusiasm they're pumping around.
Oh, I'll only thank them for making other programming languages improve much faster. Like how LLVM has stirred GCC devs into action and made GCC a much better compiler in no time.
> What is then extra strange is that there have been some public hostility against gccrs (WIP Rust compiler for gcc) from the rustc (sole main Rust compiler primarily based on LLVM) camp.
Could you point at a single quote from a member of the compiler team, current or former, that can be construed as hostility?
> In short, a developer didn't want their C codebase littered with Rust code
from reading those threads at the time, the developer in question was deliberately misunderstanding things. "their" codebase wasn't to be "littered" with Rust code - it wasn't touched at all.
Some pretext: I'm a Rust skeptic and tired of Rust Evangelism Task Force and Rewrite in Rust movements.
---
Yes. I remember that message.
Also let's not forget what marcan said [0] [1].
In short, a developer didn't want their C codebase littered with Rust code, which I can understand, then the Rust team said that they can maintain that part, not complicating his life further (Kudos to them), and the developer lashing out to them to GTFO of "his" lawn (which I understand again, not condone. I'd have acted differently).
This again boils down to code quality matters. Rust is a small child when compared to the whole codebase, and weariness from old timers is normal. We can discuss behaviors till the eternity, but humans are humans. You can't just standardize everything.
Coming to marcan, how he behaved is a big no in my book, too. Because it's not healthy. Yes, the LKML is not healthy, but this is one of the things which makes you wrong even when you're right.
I'm also following a similar discussion list, which has a similar level of friction in some matters, and the correct thing is to taking some time off and touching grass when feeling tired and being close to burnout. Not running like a lit torch between flammable people.
One needs to try to be the better example esp. when the environment is not in an ideal shape. It's the hardest thing to do, but it's the most correct path at the same time.
[0]: https://web.archive.org/web/20250205004552mp_/https://lwn.ne...
[1]: https://lkml.org/lkml/2025/2/6/404
One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring that there is a specification (the specification donated by/from Ferrous Systems, might have significant issues), or prioritizing the kernel higher than Rust.
If I had been enthusiastic about Rust, and wanted to see if it could maybe make sense for Rust to be part of the Linux kernel[0], I would probably had turned my attention to gccrs.
What is then extra strange is that there have been some public hostility against gccrs (WIP Rust compiler for gcc) from the rustc (sole main Rust compiler primarily based on LLVM) camp.
It feels somewhat like a corporate takeover, not something where good and benign technology is most important.
And money is at stake as well, the Rust Foundation has a large focus on fundraising, like how their progenitors at Mozilla/Firefox have or had a large focus on fundraising. And then there are major Rust proponents who openly claim, also here on Hacker News, that software and politics are inherently entwined.
[0]: And also not have it as a strict goal to get Rust into the kernel, for there might be the possibility that Rust was discovered not to be a good fit; and then one could work on that lack of fit after discovery and maybe later make Rust a good fit.
I think the main issue is that it never was about how rust programmers should write more rust. Just like a religion it is about what other people should do. That's why you see so many abandoned very ambitious rust projects to tackle x,y or z now written in C to do them all over again (and throw away many years of hardening and bug fixes). The idea is that the original authors can be somehow manipulated into taking these grand gifts and then to throw away their old code. I'm waiting for the SQLite rewrite in rust any day now. And it is not just the language itself, you also get a package manager that you will have to incorporate into your workflow (with risks that are entirely its own), new control flow models, terminology and so on.
Rust should have done exactly one thing and do that as good as possible: be a C replacement and do that while sticking as close as possible to the C syntax. Now we have something that is a halfway house between C, C++, JavaScript (Node.js, actually), Java and possibly even Ruby with a syntax that makes perl look good and with a bunch of instability thrown in for good measure.
It's as if the Jehova's witnesses decided to get into tech and to convince the world of the error of its ways.
2 replies →
>One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring that there is a specification (the specification donated by/from Ferrous Systems, might have significant issues), or prioritizing the kernel higher than Rust.
On the flip side there have been many downright sycophants of only C in the Linux kernel and have done every possible action to throttle and sideline the Rust for Linux movement.
There have been multiple very public statements made by other maintainers that they actively reject Rust in the kernel rather than coming in with open hearts and minds.
Why are active maintainers rejecting parts of code that are under the remit of responsibility?
Personally, I observe that Rust is forced everywhere in the Linux ecosystem. One of my biggest concerns is uutils, mostly because of the permissive license it bears. The Linux kernel and immediate userspace shall be GPL licensed to protect the OS in my opinion.
I have a personal principle of not using LLVM-based languages (equal parts I don't like how LLVM people behave against GCC and I support free software first and foremost), so I personally watch gccrs closely, and my personal ban on Rust will be lifted the day gccrs becomes an alternative compiler.
This brings me to the second biggest reservation about Rust. The language is moving too fast, without any apparent plan or maturing process. Things are labeled unstable, there's no spec, and apparently nobody is working on these very seriously, which you also noted.
I don't understand why people are hostile against gccrs? Can you point me to some discussions?
> It feels somewhat like a corporate takeover, not something where good and benign technology is most important.
As I noted above, the whole Rust ecosystem feels like it's on a crusade, esp. against C++. I write C++, and I play with pointers a lot, and I understand the gotchas, and also the team dynamics and how it's becoming harder to write good software with larger teams regardless of programming language, but the way Rust propels itself forward leaves a very bad taste in the mouth, and I personally don't like to be forced into something. So, while gccrs will remove my personal ban, I'm not sure I'll take the language enthusiastically. On the other hand, another language Rust people apparently hate, Go, ticks all the right boxes as a programming language. Yes, they made some mistakes and turned back from some of them at the last moment, but the whole ordeal looks tidier and better than Rust.
In short, being able to borrow-check things is not a license to push people around like this, and they are building themselves a good countering force with all this enthusiasm they're pumping around.
Oh, I'll only thank them for making other programming languages improve much faster. Like how LLVM has stirred GCC devs into action and made GCC a much better compiler in no time.
6 replies →
> What is then extra strange is that there have been some public hostility against gccrs (WIP Rust compiler for gcc) from the rustc (sole main Rust compiler primarily based on LLVM) camp.
Could you point at a single quote from a member of the compiler team, current or former, that can be construed as hostility?
4 replies →
> In short, a developer didn't want their C codebase littered with Rust code
from reading those threads at the time, the developer in question was deliberately misunderstanding things. "their" codebase wasn't to be "littered" with Rust code - it wasn't touched at all.