Hacker News Reader

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.

Irony.

No, just Rust's original stated goal.

Uhh, no. Rust started its life as a language with a garbage collector. It turned out to be a great C replacement, but that was never its original goal.

> 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).

I like Haskell, but I never want to work with Haskellers, ever again. I’ll do personal / solo Haskell projects. But never professionally on a team. Haskellers are not team players.

Rustaceans should really take Haskell as a cautionary tale. It doesn’t matter how good your tech is, if your community is actively hostile to newcomers, if you try to haze every newcomer by making them recite your favorite monad definition before giving them the time of day.

Rustaceans are already working their way onto my shitlist for proliferating X years’ Rust experience all over the place. And no, that’s not HR’s fault. HR has no idea what Rust is. It’s rustaceans corrupting the hiring process to reward their fellow cultists.

It’s idiotic to be so insular and so tribalistic, if you want to increase adoption of your favorite language. Programming languages are like natural languages. The more people that use them, the more valuable it is to speak it. Imagine if someone tried to get you to learn mandarin by shitting on your native language. You catch a lot more flies with honey than vinegar.

I’d rather be stuck in JS hell forever, than have to deal with such toxic, dramatic, dogmatic people. And I really dislike writing JavaScript… but the community and ecosystem around the language are way more important than the syntax and semantics. You want the engineers and builders to vastly outnumber the radioactive PL theorists.

That's a rather drastic generalization! As a counterpoint I've worked on professional teams with, what, 20 or 30 different Haskellers over the years and the number of "toxic, dramatic, dogmatic people" in that set is zero (or one if I really stretch the definition, and then only dogmatic, not toxic or dramatic). None were poor at their jobs, and the proportion of truly excellent software engineers with deep capability in the hard and soft skills needed to get code shipped was far greater than 50%.

That said, if toxic behavior occurs it can be more visible in smaller communities, just by how the numbers work out, so I don't doubt you've had a hard time interacting with some Haskellers, and I sympathize with you. Please point me to any toxic behavior you see in the public Haskell community and I'll do my best to address it with whatever authority I have.

True!

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.

The language is moving too fast? The language is moving extremely slowly imo, too slowly for a lot of features. C++ is moving faster at this point.

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.

[0] https://courses.cs.duke.edu/common/compsci092/papers/open/st...

> Open source and free software mean almost exactly the same set of software

> Nearly all open source software is free software; the two terms describe almost the same category of software.

I see no disagreement, how is GP "completely wrong"?

Edit: I'm wrong on my first reply, as pointed out here: https://news.ycombinator.com/item?id=46226602

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.

> 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.

GNU disagrees with you: https://www.gnu.org/licenses/license-list.html

> 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.

I stand corrected! Thank you for the info.

The four essential freedoms[0] are good reading for the first principles of software freedom concept.

[0]https://en.wikipedia.org/wiki/The_Free_Software_Definition

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?

Wait till you see the vulnerabilities introduced... Makes you wonder how organic it really is

> 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.

There's another point of hostility when it was expressed - not sure by who - that internals.rust-lang.org wasn't an appropriate forum to discuss gccrs

Generally speaking I think that Rust channels should be open to all implementations