[flagged]
In your own comment you mention "actually the best outcome" but that's a matter of politics, doubtless you have different ideas about what "best" would be than I do, and I appreciate that perhaps you've never considered that anybody other than you could be right, but you might want to take a moment to think again.
The point is that they seem to have conflated opinions about what policies are correct for general real-world issues, with those that are specific to the task of programming.
> "No politics" usually means
No; "no politics" usually means "please do not attempt to bring up topics that relate to decisions made by governments, and instead stay focused on topics directly related to the project at hand".
> or at best the small-C conservative idea that the status quo has existed forever and so whatever happens to presently be the case is just how things should be.
I have never understood how this argument makes sense to anyone. Obviously, "changing the status quo" is a policy position in a way that "not changing the status quo" isn't. The argument is effectively that it's impossible to just not care about something, for any given thing. I refute this by noting that an effectively unlimited number of policies can be proposed, yet I am not constantly thinking about politics.
> but that's a matter of politics, doubtless you have different ideas about what "best" would be than I do, and I appreciate that perhaps you've never considered that anybody other than you could be right, but you might want to take a moment to think again.
Again, I can't fathom how this line of argument makes sense to anyone. "Politics" is, quite simply, understood by the overwhelming majority of people in such a way that determining "best outcome" for a computer program not used in any government capacity is obviously not a political matter.
Or else: in your view, what does "should `sudo` do X in Y situation?" have in common with "should country X go to war with country Y?" ?
Everything is political in the same way that everything is offensive and everyone is evil. As in, you're welcome to go around saying that, but don't expect people to find this to be an enlightened perspective.
Tale as old as time.
I genuinely hadn't thought of this point of contention beforehand, but oof he did not care for that.
GNU is nowhere near as dominant in the non-kernel code that people run any longer.
And a lot of the GNU zealots who were particularly interested in getting credit with naming got old.
https://distfiles.gentoo.org/releases/amd64/autobuilds/curre...
That killed most of the “user freedom” enthusiasm of the early days. These days, there’s the AGPL, but that’s mostly used like the BSL (“if you want to use AGPL in production, pay us”), than for bootstrapping freedom-respecting compute environments.
If you disagree, show me an AGPL userland that’s appropriate for daily-driving.
I’m slowly migrating off Linux to the BSDs these days. The politics seem less destructive to the user experience with them.
Can't you already do anything you want to GPL code locally?
By letting cloud services that use GPL software stay closed source it actively encourages development of cloud based tooling in a commercial context and users end up getting forced to sign up with and connect to a closed source cloud service they have even less control over than traditional locally running closed source software.
I think Stallmans motivation for the FSF includes a story about modifying a driver for a printer to support new features. Now imagine if that printer had a cloud based interface and imagine how the GPL would help Stallman add features for a new printer to it. It doesn't, if he wanted to fix the interface he would have to reverse engineer it from scratch. 40 years of FSF and it lets a decades old trend run circles around its goals.
This is why AGPL was invented. You might use my AGPL code in your cloud service, but you need to provide the source code you are running to your clients. You are not allowed to keep any secret sauce secret from your users.
MIT and BSD (and plain GPL) don’t protect users again abuses like this.
V3 is incompatible with selling bootloader locked software stacks (pretty much all consumer hardware these days).
Concretely, I can’t do this local thing: Take GPLv3 software, build a board, link the software to vendor blob firmware (~ all current hardware requires this step), flash it to a ROM on the board and sell it to you with a copy of the GPLv3 software’s source code.
I can take the same vendor blob, add a TCP stack, and have your device shell into a copy of GPLv3 software with closed source modifications running in my data center.
This has massive negative consequences for users of GPLv3-reliant IoT crap and cloud services.
Which is great. It prevents enshitification of consumer devices.
But their argument is that blocking that loophole, while not blocking an even worse loophole, caused more harm than good.
In other words we should have moved as much as possible directly to AGPL, and left the rest on GPLv2.
It is only "religious" if you think it in such a way.
I'd say the amount of skepticism (rather than valid criticism) has been no less than enthusiam in the community.
As the saying goes, there are two kinds of languages...
I think they just want to ditch GNU tools and lots of young, low level programmers want to use Rust (same rationale for Linus accepting Rust code into the kernel).
This is why so many Linux developers resists the addition of Rust or C++.
Yeah. I too, hate the Rust Evangelically Orthodox Later Day Christians.
Oh, wait... You're serious. What is religious about rewriting tools in Rust? Isn't that what most programmers do for fun and learning?
Is it any more religious than worshiping Alan Kay or Dijkstra?
> It makes me wonder how much is motivated by stuff other than what’s actually the best outcome.
Looks in the thread... Sees https://www.sudo.ws/security/advisories/
Are you sure the status quo is the better outcome?
"Religious" isn't being used to refer to people rewriting tools in Rust.
It's used to refer to people zealously commenting on message boards that every single tool ever built should be rewritten in Rust, and if you aren't rewriting your tool in Rust, you're an idiot.
Ok, but between me, GP and the article, who said that? Where are the Rabid RIIR fans?
And before you misquote me, I said, why wouldn't you rewrite stuff in Rust, if the status quo is ridden with bugs, and safety issues? And why shouldn't a Linux distro switch to it if they desire.
The person you replied to said: "The religious element of rust programmers seems more extreme than other languages."
You interpreted that in a way that ended up with you asking "What is religious about rewriting tools in Rust".
I clarified that the typical way "religious element of rust programmers" is interpreted is not the act of rewriting tools, but the proselytizing about rust on message boards. I then gave an example of what that proselytizing typically looks like (which was not a claim that you said something like that).
That is the "religious element" being referred to. The proselytizing is the religious element, not the act of rewriting tools in Rust.
(The meme "Rust Evangelists" didn't manifest out of thin air because people hate memory safety or whatever -- it's because people are really, really passionate about Rust, and are vocal about that passion)
Ok. Where is the proselytizing taking place in the article?
Is the sudo-rs did work, the proselytization? Where is it?
> The meme "Rust Evangelists" didn't manifest out of thin air
That's not how memes work. It's just something that appeals to some group that spreads it. It can be true, false and fabricated out of thin air.
What if I told you, that "What if I told you" meme isn't what Morpheus says to Neo? The scene itself is so divorced from meme it doesn't carry much resemblance (here https://youtu.be/L8H9DqkrkcY)
It's not? It's like you're picking random words out of my comment to quote without bothering to read what I'm writing. Nothing of what I said is about the article. It's about your misinterpretation of what fossuser meant when they said "religious element".
I can't explain the same thing for a third (fourth, I guess? since I just tried again) time, I'm running out of different ways to say it. So I'll just leave it there.
Your meta-commentary on memes is neat and all, but again, somehow, completely misses the point I was making.
My point, where is the proof of that "religious element" beyond memes? Is it in the article? Is it in the links? Where can we see this religious fervor in action?
The article is very matter of fact. I expect people to be matter of fact as well.
I swear to God, I feel like I'm asking for the Individualist Eleven book, and everyone asserts me it exists, and they read it, but no one can ever finds it.
> Your meta-commentary on memes is neat and all, but again, somehow, completely misses the point I was making.
It's necessary because memes aren't real. They might have started based on some interactions that 10 years ago, but by their nature they will mutate and twist.
You can argue with fossuser about the validity of what they said.
I'll offer my opinion, which is not some proof from god or anything that you seem to be seeking, which is that I find significantly more annoying comments from Rust users, about how something should be rewritten in Rust to fix everything, than any other language. But, again, this is not proof from god. I'm just a guy making an observation based on my lived experience. You have a different lived experience. Glad we could clear that up.
You know what, you or anyone else can start with actual proofs. I don't want your lived experience and memes as proof, I need messages, posts from people (bonus points for sudo-rs members) that show how zealous they are about Rust and rewriting all the things in it.
I'm a Java dev, that just dabbles in Rust. I've seen observed many claims about Rust zealotry with no actual proof. Whenever I ask for them, I get a blank stare and dodging.
Hence, my comparison with the book from Ghost in the Shell. It, too, was a meme, an actual memory virus. Everyone read it, and no one could find the proof it existed.
Have fun.
(I'm sure if I pick any specific quotes, you'll start arguing the semantics of what is "zealous", how whatever number of comments I pick are outliers, or not proof enough, etc. So, here's one query, of many, that you can pick through.)
In the end, I really could not care less if you agree with the characterization or not. But your enthusiastic defense is fun. If you keep going, you'll be coming close to being an example yourself!
First, a simple grading system: 0 - No RIIR sentiment 1- Joking or 2 - Mentioning Rust in positive light 3 - Suggesting Rust positive light for project 4 - Asking for RIIR, saying stuff like this wouldn't happen in Rust 5 - Demanding RIIR
| | | RIIR grade (0 -> 5) | Notes |
| --- | --------------------------------------------- | ------------------- | ----------------------------------------------------------- |
| 1 | https://news.ycombinator.com/item?id=43912708 | 4 | Parent post is talking about Rust |
| 2 | https://news.ycombinator.com/item?id=43910022 | 0 | Talks about Fish rewrite |
| 3 | https://news.ycombinator.com/item?id=43909844 | 0 | Discusses Issues |
| 4 | https://news.ycombinator.com/item?id=43909222 | 1 | Jokey on RIIR |
| 5 | https://news.ycombinator.com/item?id=43906665 | 0 | Talking about RIIR |
| 6 | https://news.ycombinator.com/item?id=43905224 | 0 | Promotes a rewrite in C versus a Rust rewrite |
| 7 | https://news.ycombinator.com/item?id=43897309 | 2 | Discusses Rust in positive light, but nothing about rewrite |
| 8 | https://news.ycombinator.com/item?id=43865281 | 0 | Discusses negatives of JS backends |
| 9 | https://news.ycombinator.com/item?id=43851214 | 0 | Talks about knowledge bias |
| 10 | https://news.ycombinator.com/item?id=43851075 | 5 | RIIR (maybe joke) |
| 11 | https://news.ycombinator.com/item?id=43840479 | 0 | RIIR is mentioned in passing, not actually used |
| 12 | https://news.ycombinator.com/item?id=43833836 | 4 | RIIR suggestion |
| 13 | https://news.ycombinator.com/item?id=43832828 | 0 | Advises against Rust |
| 14 | https://news.ycombinator.com/item?id=43832638 | 0 | Not RIIR |
| 15 | https://news.ycombinator.com/item?id=43832349 | 4 | Asks for RIIR (maybe jokingly) |
| 16 | https://news.ycombinator.com/item?id=43827713 | 0 | Congratulates on Rewriting in C#/Unity |
| 17 | https://news.ycombinator.com/item?id=43797673 | 0 | Neither it nor the GP are acually RIIR |
| 18 | https://news.ycombinator.com/item?id=43791746 | 3 | Mentions Rust in positive light |
| 19 | https://news.ycombinator.com/item?id=43791093 | 1 | Joke |
| 20 | https://news.ycombinator.com/item?id=43791090 | 1 | Joke |
| 21 | https://news.ycombinator.com/item?id=43781819 | 2 | Arguments for writing code in Rust |
| 22 | https://news.ycombinator.com/item?id=43769094 | 5 | RIIR |
| 23 | https://news.ycombinator.com/item?id=43768282 | 0 | Negative on RIIR |
| 24 | https://news.ycombinator.com/item?id=43766357 | 0 | Explaining what RIIR means |
| 25 | https://news.ycombinator.com/item?id=43766000 | 4 | Asks for RIIR |
| 26 | https://news.ycombinator.com/item?id=43764348 | 0 | Discusses implementation in Rust |
| 27 | https://news.ycombinator.com/item?id=43757201 | 0 | Talks about Rust |
| 28 | https://news.ycombinator.com/item?id=43731538 | 2 | Mentions Rust in positive light |
However actual number of RIIR between 2-5 depending how you look at it, 5-17%. Assuming the rest of pages have a similar spread, and that targeting only keywords of RIIR captures accurately the sentiment - I suspect the latter is the case. I've seen more negativity about Rust in https://news.ycombinator.com/item?id=43910745 in few hours, than positivity about Rust in several days.
And I've seen my comments that are positive about Rust get way more downvoted, than comments skeptical or negative on Rust.
Isn't not advertising a language the polar opposite of being religious about a language?
I am all for a memory safe sudo and I don't care which language it is written in, use C, Ada, Rust, as long as it is a suitable systems programming language understood by a community of developers and you can proof memory safety to an acceptable degree. If the people first to do it in an such an way happen to use Rust, not accepting that based purely on the language is what would sound religious to me..
Maybe this protectionist reaction (see recent drama within the Linux kernel) is every bit as religiously colored as some people claim Rust people are.
I mean memory safety? What comes next? Not allowing us to use after free like true men would? \s
My reply is flagged dead now which is fine since it did create an unproductive thread, but it was more that I had noticed Rust as a community seems to have more of an identity based political bent around it more so than other languages. Something I've also noticed with Mozilla - it's not just the language, but that the language signals you're a certain kind of person with a certain kind of politics in addition to the general pro-rust stuff.
I don't recall seeing this combination elsewhere with other languages before - though there have been religious like battles over languages forever, but I don't think it's been predictive of someone's political identity before?
This is a pretty astounding claim. On which data did you base that conclusion? Because if it is purely anecdotal, you might consider that this is a bit like with Apple fanboys. Apple generally makes good products. Most people who use their stuff don't even talk about it, but those who do talk about it tend to have strong opinions that extend the quality of Apples products themselves.
But these opinions are not even remotely representative of the broad majority of Apple users.
Rust similarily lends itself to fanboyism, because the language has a strong narrative going for it, that is part of its success. The narrative isn't even a bad one: create a programming language that makes certain common classes of mistakes impossible and others much harder. Like every topic with strong narrative this will draw in a certain amount of people who will strongly defend said narrative, but those aren't necessarily the manority of the people who use the language.
So unless you made a proper poll that tries to select for a broad set of Rust users instead of basing your judgment on a loud online minority I wouldn't be confident in the result.
I with "identity based bent" you mean they are inclusive and have strong community rules, it might just be that this is normal where the Rust users are from. Last time I checked Rust was very popular in European countries and over here these kind of rules are pretty off the shelve standard. But please tell me this isn't about you calling them "woke" and confusing basic human dignity with politics.
Tho the extra properties re side channels in said verified code outdoes Rust, so I'd also say it'd be undesirable to replace that C code with Rust
https://www.theregister.com/2024/11/08/the_us_government_wan...
Rust is part of a modernized iteration in language design this century
Nobody is calling for Ada code to be rewritten in Rust. But at this point you'd want an argument to choose Ada over Rust when it has become more widespread, especially in open source projects
Here's someone else's take on your question a few years ago: https://news.ycombinator.com/item?id=28347930
- Avionics
- ATM
- Space
- Rail
- Automotive
- Defense
- Security
- Medical
https://www.adacore.com/about-ada
You can find lots of resources here to learn Ada / SPARK: https://learn.adacore.com or just to see what is up. Alternatively, there are good blog posts, too.
For years I used a C window manager I wrote which was less than 150 lines[1], it can definitely be a terse language. But I've also written pretty tight Rust code for a card game engine & its http server. I don't think Rust is particularly more verbose. Rust code can be artistic too[2]
1. https://github.com/serprex/nobox/blob/master/nobox.c
2. https://github.com/serprex/Kelxquoia/blob/master/src/main.rs
https://github.com/serprex/nobox/blob/master/nobox.c is definitely terse. :D I get lost just by looking at it; a little bit of refactoring (indentation-wise) would help though.
But why does it matter if the language that has seen some traction in terms of "rewriting software in safer languages" is rust? At that point it becomes even more religious to just reflexively oppose rust because "well why didn't x or y see the same push??"? Again, it really doesn't matter why!
> But why does it matter if the language that has seen some traction in terms of "rewriting software in safer languages" is rust? At that point it becomes even more religious to just reflexively oppose rust because "well why didn't x or y see the same push??"? Again, it really doesn't matter why!
If it does not matter, then why not Ada / SPARK indeed? I am sure the whys matter to some extent.
I did start writing coreutils in Ada but I gave up. :(
Which is obviously false, and I think the novel thing about rust's hype is that it's always compared to C or C++ (instead of java or c#, for example).
I think that's why it feels like it's the only language that is talked about when discussing "memory safety" (even if most mainstream languages are memory safe now). Go had a similar "system lang" hype to it until it was clear that it really wasn't.
Ada is undoubtedly a systems language (as you said it's been used to build insanely complex systems and it did just fine), but from my POV the little marketing that it has doesn't emphasize that.
I think though one of the reason ada doesn't get discussed a lot is that it doesn't have a big open source community. Ada could even be more popular in terms of actual LoC written, but most of that development is held behind very closed doors, so it's very hard to actually get a community going. Which then makes it hard to actually go through a full rewrite of things like coreutils.
I'm not complaining about the downmods, I'm just weirded out - it's like a music forum disagreeing that flutes are real.
Edit: all links now fixed.
____
(generated, but with references)
# U.S. government guidance on memory-safe languages
Here's the list of links to U.S. government documents recommending memory-safe programming languages for cybersecurity.
1. *White House ONCD - "Back to the Building Blocks" (Feb 2024)* - Encourages developers to use memory-safe languages like Rust, Python, Java, C#, Go, Swift to reduce vulnerabilities. - Link: https://bidenwhitehouse.archives.gov/wp-content/uploads/2024...
2. *CISA, NSA, FBI, and partners - "Memory Safe Roadmaps" (Dec 2023)* - Recommends memory-safe languages (C#, Go, Java, Rust, Ruby, Swift) and roadmaps to eliminate memory issues. - Link: https://www.cisa.gov/resources-tools/resources/case-memory-s...
3. *NSA - "Software Memory Safety" (Nov 2022)* - Advises using memory-safe languages like C#, Go, Java, Ruby, Swift to avoid C/C++ vulnerabilities. - Link: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
4. *CISA - "Urgent Need for Memory Safety" (Sep 2023, updated Dec 2023)* - Promotes memory-safe languages as part of the Secure by Design campaign. - Link: https://www.cisa.gov/news-events/news/urgent-need-memory-saf...
5. *White House press release - "Future Software Should Be Memory Safe" (Feb 2024)* - Calls for memory-safe languages to reduce cyberattack surfaces. - Link: https://bidenwhitehouse.archives.gov/oncd/briefing-room/2024...
6. *NIST - "Safer Languages" (updated Oct 2022)* - Highlights memory-safe languages like Rust and Ada to prevent common vulnerabilities. - Link: https://www.nist.gov/itl/ssd/software-quality-group/safer-la...
But I'm aware that some people are frightened of new languages and paradigms especially if they're 'harder' than what they're used to.
2) the dependency list is tiny
3) it uses a cargo lock, so even if it were using a GitHub dependency, that file keeps a hash of the dependency and points at the specific commit, so if the dependency were to introduce a backdoor it wouldn't be automatically picked up and a commit history rewrite would also fail
https://github.com/trifectatechfoundation/sudo-rs/blob/main/...
I am not frightened. I program in many languages and have no problems grasping Rust concepts. However I find Rust way too opinionated and restricting for personal tastes. For business I can not see myself replacing C++ with Rust unless my paying clients specifically request it. So far not a single one had expressed any interest.