Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

Post reply on HN
Print view View original

241–250 of 797 posts

Re: Hard Rust requirements from May onward

#241

Post by tempest_ »

noisem4ker wrote: post #108
lelanthran wrote: post #80

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

From the outside looking in most of the push back against rust seems to be of the "I am too old, never make mistakes, and don't want to learn a new thing late in my career" variety.

I have rarely seen an argument that pushes back against Rust with actual alternative solutions to the problems the rust proponents are trying to solve. It is mostly a bunch of old people letting the perfect be the enemy of the good.

Re: Hard Rust requirements from May onward

#242

Post by lelanthran »

timeon wrote: post #128
lelanthran wrote: post #73

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?

If you change it to "Rust community haters seem strangely obsessed.", it is still valid.

> If you change it to "Rust community haters seem strangely obsessed.", it is still valid.

Maybe. What does that have to do with the Rust community having such a poor reputation compared to other communities?

Re: Hard Rust requirements from May onward

#243

Post by jamincan »

egorfine wrote: post #183

I'm happy for all developers programming in their favorite programming languages. Programming for over 30 years I have seen entire ecosystems come and go. What I don't get is the burning need for Rust developers to insult others. Kind of the same vibes that we get from systemd folks and LP. Does it mean they have psychological issues and deep down in their heart they know they need to compensate? I remember C vs Pasc…

Who is insulting others and where?

Re: Hard Rust requirements from May onward

#244

Post by pron »

throwaway17_17 wrote: post #222
pron wrote: post #149

Earlier quoted context omitted.

> it's simply not interesting from a safety perspective The reason memory safety is interesting in the first place (for practical, not theoretical reasons) is that it is a common cause of security vulnerabilities. But spatial memory safety is a bigger problem than temporal memory safety, and Zig does offer spatial memory safety. So if Rust's memory safety is interesting, then so is the memory safety Zig offers. I'm a…

I am very much inclined to agree with you, but do you have any sourcing for a claim that spatial is a bigger problem with regards to security vulnerabilities? Every time I feel like posting similar sentiments I just know that a reply linking to an article about how Microsoft and/or Google claim 70% of bugs are memory safety issues will be posted. Both of the ‘studies’ (code surveys) seem to claim use-after-free make…

Mitre place spatial memory safety higher on the list: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html (also >3x KEV)

Re: Hard Rust requirements from May onward

#245

Post by tmtvl »

lambdaone wrote: post #161

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…

> Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety.

I don't know about that. Look at the code for the COSMIC desktop environment's clock widget (the cosmic-applet-time directory under https://github.com/pop-os/cosmic-applets>), for example. It's pretty much unreadable compared to a C code base of similar complexity (GNU coreutils, for example: https://savannah.gnu.org/projects/coreutils/>).

Re: Hard Rust requirements from May onward

#246

Post by woodruffw »

krater23 wrote: post #235
lambdaone wrote: post #161

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…

Memory safety is mostly a issue of the past. Clearly, there are new code bases with memory issue too. But we have tools to prevent that. The new security issues are supply chain attacks. And Cargo is the way to have exactly this.

> Memory safety is mostly an issue of the past.

Can you provide some evidence to support this? There’s a large body of evidence to the contrary, e.g. from Chrome[1].

> But we have tools to prevent that. The new security issues are supply chain attacks.

Speaking as a “supply chain security” person, this doesn’t really hold water. Supply chain attacks include the risk of memory unsafety lurking in complex dependency trees; it’s not an either-or.

[1]: https://www.chromium.org/Home/chromium-security/memory-safet...

Re: Hard Rust requirements from May onward

#247

Post by gpm »

dcsommer wrote: post #227
gpm wrote: post #202

Earlier quoted context omitted.

Not really. All (current) languages eventually have a compiler/runtime that is memory unsafe. This is basically fine because it's a tiny amount of surface area (relative to the amount of code that uses it) and it exists in a way that the input to is relatively benign so there's enough eyes/time/... to find bugs. There's also nothing stopping you from re-implementing python/ruby/... in a safer way once that becomes th…

> basically fine How many type confusion 0 days and memory safety issues have we had in dynamic language engines again? I've really lost count.

Are you counting ones that involve running malicious code in a sandbox and not just trusted code on untrusted input? Because then I'd agree, but that's a much harder and different problem.

My impression is that for the trusted code untrusted input case it hasn't been that many, but I could be wrong.

Re: Hard Rust requirements from May onward

#248

Post by kstrauser »

dvtkrlbs wrote: post #239
kstrauser wrote: post #225

Earlier quoted context omitted.

I find Rust much easier to write than C. Its types let me be reasonably sure I’ve written appropriate code before I even get to the point of running tests, and I don’t have to memorize the flow of the whole program to have that assurance. For instance, struct Feet(i32); struct Meters(i32); fn hover(altitude: Meters) { println!("At {} meters", altitude.0); } fn main() { let altitude1 = Meters(16); hover(altitude1); le…

Related library Sguaba [1] from Helsing AI written by Jon Gjengset it allows you to define coordinate systems on the type level and safe conversion and calculation with them. [1] https://github.com/helsing-ai/sguaba

I love that sort of thing. It so much easier to get up and running with plausible results when it’s all but impossible to misuse the API. “Darn it, it’s making me cast Celsius to Meters before I call this function. Hey, wait, that can’t be right…”

Re: Hard Rust requirements from May onward

#250

Post by dvtkrlbs »

Antibabelic wrote: post #26
Mond_ wrote: post #11

Earlier quoted context omitted.

> IMHO Rust has severe problems and what is considered "modern" is mostly taste. Really? As opposed to e.g. C or C++ (as the most important languages which Rust is competing with)? Sure, taste plays into everything, but I think a lot of people work with Rust since it's genuinely a better tool. I hear you on free software being controlled by corporate interests, but that's imo a separate discussion from how good Rust…

Ada and SPARK fulfilled the promise of a safe systems language decades ago without making most of the mistakes Rust does. Rust has its strong sides, sure, but it's far from the only shop in town. The GCC happens to include an Ada compiler as well.

The problem is they forgot about making the language approachable so it lives in its bubble for safety criticial usage (which Rust kinda starting to eat its lunch from with the certified Rust fork)
Post reply on HN