Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

101–110 of 797 posts

Re: Hard Rust requirements from May onward

#101
post #13

I don't get the need for Rust since I happily compile common lisp to machine code when I need fast binaries. But the people who use the language have an amazing talent to make people on the fence hate them within half a dozen sentences. They remind me of Christian missionaries trying to convert the savages from their barbarous religions with human sacrifice to the civilised religion with burning heretics.

> Christian missionaries trying to convert the savages Fast forward 5 centuries, it turns out they were in fact pretty successful as South America central Africa are the places where Catholicism is the most active today, far more than in Europe.

Yes, by doing a lit of killing in those places.

Re: Hard Rust requirements from May onward

#102

Earlier quoted context omitted.

> Acolytes being the people talking positively about their experience using a language and the strengths they think it has. No, it's the people who have given rise to the multiple Rust memes over the years. I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community. Scala? Kotlin? Swift? Zig? None of those languages have built such poor reputations for their comm…

> I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community. Because you’re young or you weren't around in 2010 when Go was gaining adoption. Same shit back then. People said “I like the language, it’s quite useful” followed by tirades from people who thought it was the end of human civilisation. It had exactly the reputation you speak of. (“DAE generics???”) Ev…

> Because you’re young or you weren't around in 2010 when Go was gaining adoption.

I've been working as a programmer since the mid-90s

>> I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community.

> People said “I like the language, it’s quite useful” followed by tirades from people who thought it was the end of human civilisation.

And? That's not the same as having a hostile community. I never saw Go proponents enter C# or Java discussions to make attacks against the programmers using C# or Java like I saw constantly wirh Rust proponents entering C or C++ discussions and calling the developers dinosaurs, incompetent, etc.

Re: Hard Rust requirements from May onward

#103
post #50
post #34

Earlier quoted context omitted.

Yes, but we're not making a push to make everything a bilingual c/lisp code base. Rust people for some reason are.

Not a Rust or even a systems language guy but it’s not “for some reason”. The reason is actually incredibly clear and about removing the single largest surface area of security problems in the entire history of Linux.

Is it the largest though? Based on https://owasp.org/www-project-top-ten/, it would be part of #6 or #8. While one can always walk and chew gum at the same time (and those rewriting system software are likely not the same people who need to design systems with less flawed access control), replacing stable software is not without risk (e.g. https://lwn.net/Articles/1043103/, which is an instance of #6 caused by rust). Would you trust a rewrite of OpenSSH in rust (absent any information about its authors)?

Re: Hard Rust requirements from May onward

#104

Earlier quoted context omitted.

> Rust haters seem strangely obsessed. Well, this is a great example. People complaining about the community are labeled as people complaining about the language. Do you not see the problem here?

I think you'd need to give answer to your own questioning here... why did you take "Rust haters" as "Rust -language haters", and not as "Rust -community haters"?

> I think you'd need to give answer to your own questioning here... why did you take "Rust haters" as "Rust-language haters", and not as "Rust-community haters"?

Because it literally says "Rust haters"; not "Rust community haters".

Are you saying that when someone refers to "Rust", they mean the community and not the language?

Re: Hard Rust requirements from May onward

#105

Earlier quoted context omitted.

I think you'd need to give answer to your own questioning here... why did you take "Rust haters" as "Rust -language haters", and not as "Rust -community haters"?

> I think you'd need to give answer to your own questioning here... why did you take "Rust haters" as "Rust-language haters", and not as "Rust-community haters"? Because it literally says "Rust haters"; not "Rust community haters". Are you saying that when someone refers to "Rust", they mean the community and not the language?

Yes, you're half way there.

Re: Hard Rust requirements from May onward

#106
post #69
post #56

Earlier quoted context omitted.

> The reason is actually incredibly clear There is no guarantee that other bugs do not flurish in the rust echosystem. There are no publicly known quality code checks of rust programs except a big "trust us"(see firefox with all its CVEs, despite "rust"). And combined with the Cargo echosystem, where every malicious actor can inject malware is a big warning sign.

I might be misunderstanding here but... what you're saying is that Rust programs can still have bugs? Isn't that the same as other programs except Rust prevents the most disastrous and common bugs that lead to most CVEs? If I got that right, how is "it's still not perfect" an argument? Agree with the Cargo objection.

If perfect isn't needed, we might as well stick with the 20+ years old mature codebase, there's no need to move to another language. I mean the "code to parse .deb, .ar, .tar," is done and whatever memory bugs should've been already fixed .

Use Rust for evergreen projects by all means, just leave mature tested systems alone, please.

Re: Hard Rust requirements from May onward

#108

Earlier quoted context omitted.

Acolytes being the people talking positively about their experience using a language and the strengths they think it has. So the people with positive opinions should say nothing at all, and the people with negative opinions should be free to share. And somehow, you think this will lead to faster adoption. That’s an interesting thought. It would run counter to everything we know about human nature, but interesting nev…

> Acolytes being the people talking positively about their experience using a language and the strengths they think it has. No, it's the people who have given rise to the multiple Rust memes over the years. I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community. Scala? Kotlin? Swift? Zig? None of those languages have built such poor reputations for their comm…

> I didn't see C++ users jumping into Rust threads posting attacks

There absolutely are, and have been. You could say it's a reaction. I don't want to argue about who started it.

I agree with you that if the Rust community has gained such a peculiar reputation, it's also due to valid reasons.

Re: Hard Rust requirements from May onward

#109
post #69

Earlier quoted context omitted.

I might be misunderstanding here but... what you're saying is that Rust programs can still have bugs? Isn't that the same as other programs except Rust prevents the most disastrous and common bugs that lead to most CVEs? If I got that right, how is "it's still not perfect" an argument? Agree with the Cargo objection.

If perfect isn't needed, we might as well stick with the 20+ years old mature codebase, there's no need to move to another language. I mean the "code to parse .deb, .ar, .tar," is done and whatever memory bugs should've been already fixed . Use Rust for evergreen projects by all means, just leave mature tested systems alone, please.

OK? So, is your position that Debian is only for software that's old enough to vote?

Or maybe Debian should never rely on any software written after 2015?

Re: Hard Rust requirements from May onward

#110
post #54

If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages. Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725

What a horrible mindset. I'll never understand this "security" argument.

    It is our responsibility to our users to provide them the most secure option possible as the default.
Removing features is not the most secure option possible. Go all the way then and remove everything. Only when your computer cannot do anything it will be 100% secure.
Post reply on HN