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.
>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.
>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.
> 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.
The goal of Rust is to build reliable systems software like the kind I've worked on for the last many years, not to be a better C, the original goal of which was to be portable assembler for the PDP-11.
> 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.
I think Rust's syntax and semantics are both the best by some margin across any industrial language, and they are certainly much better than any of the ones you listed. Also, you missed Haskell.
Haskell is interesting, it is probably one of the best programming languages ever devised but it just can't seem to gain traction. There are some isolated pockets where it does well (both business wise as well as geographically).
Interesting, I was also thinking of the similarities with Jehovah’s witnesses. It’s as if they somehow got into the building, were offered a job and now want to convince everyone of the merits of technical salvation.
Rust the technology is not bad, even though it is still complicated like C++, has rather poor usability (also like C++) and is vulnerable to supply-chain attacks.
But some of the people can be very irritating and the bad apples really spoil the barrel. There’s a commenter below gleefully writing that “C++ developers are spinning in their graves”. Probably slightly trolling and mentioning C++ doesn’t make sense in this kernel context, but such hostile, petty comments are not unheard of.
>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.
LLVM is free software. You appear to be making the common mistake of confusing the permissive vs. copyleft distinction with the open source vs. free software distinction.
Open source and free software mean almost exactly the same set of software; the only difference between the two terms, according to RMS and other free software advocates, is the emphasis. Sort of like the difference between the Gulf of America and the Gulf of Mexico: they mean the same body of water, but reflect a different viewpoint about it.
This confusion arises because RMS prefers the term "free software" over "open source", and also prefers copyleft over permissive licenses, so people sort of get the idea that they are the same distinction.
At least concerning Richard M. Stallman's take on this subject, this characterization is completely wrong.
RMS certainly does not consider the difference between open source and free software to be merely one of 'emphasis.' According to him they are completely different animals. Here are his words on their difference[0]:
> 'When we call software “free,” we mean it respects the users’ essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes (see http://www.gnu.org/philosophy/free-sw.html). This is a matter of freedom, not price, so think of “free speech,” not “free beer.”
...
Nearly all open source software is free software; the two terms describe almost the same category of software. But they stand for views based on fundamentally different values. Open source is a development methodology; free software is a social movement. For the free software movement, free soft-
ware is an ethical imperative, because only free software respects the users’ freedom. By contrast, the philosophy of open source considers issues in terms of how to make software “better”—in a practical sense only. It says that non-free software is a suboptimal solution. For the free software movement, however, non-free software [including non-free open source software] is a social problem, and moving to free software is the solution.'
[emphasis and square brackets mine]
It's not that RMS 'prefers the term "free software" over "open source"' but that he prefer software be free instead of non-free. The source being open is just an incomplete precondition for being free.
LLVM is free software, and it is a confusion to equate copyleft and free software, though I still maintain that free and open source are very distinct concepts which refer to different categories of licenses. That contrast is better stated by RMS in the article on the subject above which I linked above.
Original reply:
Primarily its this first line here:
>LLVM is free software. You appear to be making the common mistake of confusing the permissive vs. copyleft distinction with the open source vs. free software distinction.
LLVM is NOT free software because it is released under the Apache license, which is an open source license but not a free software license. This is opposed to the linux kernel and GCC which are free software because their source is available under the GPL license. Further it is not really a confusion to equate permissive licensing with open source as distinguished from copyleft and free software. In this context, free is equivalent in meaning to copyleft, as distinguished from the more permissive open source licenses.
> Apache License, Version 2.0 - This is a free software license, compatible with version 3 of the GNU GPL.
Furthermore:
> Further it is not really a confusion to equate permissive licensing with open source as distinguished from copyleft and free software.
You are in disagreement with the FSF on this issue. "permissive" licenses also follow the Four Essential Freedoms, none of which require viral licensing.
This is nonsense, and I have no idea why you need to believe it.
Open Source can be used as Free Software because Open Source can be used as proprietary software or anything else, as long as you include the license or mention the author somewhere or whatever. But these are both standards for actual licenses, and the actual licenses are different. Copyleft software can not be included in your proprietary software.
Copyleft software is restrictive. You are required to allow people to access it, and required to redistribute it in source form if you are redistributing it in compiled form (or over the network for modern copyleft licenses.) You are also required to include all of the changes that you have made to the things that you have compiled within that source distribution, and to also distribute other code that is required to to make your software package work under the same licensing.
The confusion is only in people spreading misinformation trying to confuse the two things. You clearly seem to know that RMS can prefer copyleft over permissive licenses, but still need to pretend that there's no difference between the two. If you know that someone can prefer white chocolate to dark chocolate, there's obviously something wrong with you if you in the same breath say that there is no difference between white chocolate and dark chocolate. Why deceive people? What's the point?
If they're all exactly the same, everybody should be using the GPL in Linux then. Shouldn't even be a thought. Why waste time forcing corporate-friendly licenses if it doesn't matter and some people are against them? Shouldn't parsimony rule then?
> 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?
For what it’s worth, I perceived hostility here a long time ago, but those people have pretty explicitly come around since. That said I also think the parent is just wrong to focus on gcc vs llvm as the source of that, and also to bring it up at this point regardless.
The only thing I could ever see misconstrued of as "hostility" with my earshot from anyone in t-compiler is myself saying something along the lines of "that sounds like a lot of effort that doesn't gain much over rustc_codegen_gcc, and I am not interested in contributing to a cpp codebase". Note that nowhere in my position I state anything like "this shouldn't exist" or "they should stop" or "we shouldn't cooperate". If anything, the communication channels with them are quite open and friendly. During the RustNL Q&A for the gccrs talk people from t-lang and t-compiler asked point blank "what can we do to help make your life easier". Beyond some minor concerns about the potential for language divergence and gccisms becoming a thing, which they have been very vocal about wanting to avoid, my opinion on the project is that it is net positive and I am impressed with them, and I'll help in any way I can, short of writing code on my spare free time for yet another rust compiler—one is a handful already for me :)
Yes, I'm being vague here because I don't think it's productive to bring up some old stuff, but I bring up at at all because I was trying to agree with you: at this point, it appears to be very fine and healthy, even if I didn't think that was 100% the case at one point.
If you really want to know, we can email about it, but I don't think it matters, because whatever it was is clearly under the bridge by now.
> 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.
Yes, this is it. The Rust code would be in an entirely different part of the project, not touching any of his code, only providing an abstraction for the Rust code to interact with it. The only thing the Rust team asked is to be notified of API changes that they would have to update their bindings for.
