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

231–240 of 797 posts

Re: Hard Rust requirements from May onward

#231

Post by OptionOfT »

wolvesechoes wrote: post #214
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…

If people really, really want to have all infra written in Rust, they should step-up and stop using LLVM.

What is the concern with LLVM? I'm asking because I genuinely don't know.

Re: Hard Rust requirements from May onward

#232

Post by kstrauser »

OptionOfT wrote: post #230
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…

It would've saved the Mars Climate Orbiter: https://en.wikipedia.org/wiki/Mars_Climate_Orbiter > An investigation attributed the failure to a measurement mismatch between two measurement systems: SI units (metric) by NASA and US customary units by spacecraft builder Lockheed Martin.[3]

That was exactly what I was thinking of when I wrote that.

But also think of how many libc functions take multiple ints or multiple chars in various orders. You can get carried away with typing, i.e. by having a separate type for everything*. Still, imagine you’re writing, say, a hypothetical IDE device driver and had separate types for BlockNumber and ByteInBlock so that it’s impossible to transpose read(byte_offset,block) instead of read(block,byte_offset), even if those are really the same kind of numbers.

That kind of thing makes a gazillion bugs just vanish into the ether.

Re: Hard Rust requirements from May onward

#233

Post by fastball »

s20n wrote: post #187

> This extends at first to the Rust compiler and standard library, and the Sequoia ecosystem. By Sequoia, are they talking about replacing GnuPG with https://sequoia-pgp.org/ for signature verification? I really hope they don't replace the audited and battle-tested GnuPG parts with some new-fangled project like that just because it is written in "memory-safe" rust.

Or did Rust just raise its Series A?

Re: Hard Rust requirements from May onward

#234

Post by zozbot234 »

davemp wrote: post #177
zozbot234 wrote: post #71

Earlier quoted context omitted.

Basically correct, but Zig is not a memory safe language. It may be an improvement wrt. syntax over C, and its standard library facilities may be genuinely better than Rust's wrt. writing unsafe code, but it's simply not interesting from a safety perspective. I'm sure that even the most rabid Zig advocates would readily acknowledge this point. > Garbage collection is a huge dealbreaker for the people still on C/C++.…

Rust technically isn’t a memory safe language the second you use “unsafe”. Rust advocates tend to pretend the can have their cake and eat it too when comparing it to other low level languages. No, just because you have the word unsafe next to the scary parts doesn’t make it okay. I’ve written a good chunk of low level/bare metal rust—unsafe was everywhere and extremely unergonomic. The safety guarantees of Rust are a…

The safety guarantees of Rust the language around unsafe are just as good as C or Zig if you use the appropriate facilities (raw pointers, MaybeUninit, UnsafeCell/Cell, Option for nullability, Pin etc). Sometimes this is made unnecessarily difficult by standard library code that expects all the guarantees of ordinary Safe Rust instead of accepting more lenient input (e.g. freely aliasable &Cell's), but such cases can be addressed as they're found.

Re: Hard Rust requirements from May onward

#235

Post by krater23 »

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.

Re: Hard Rust requirements from May onward

#236

Post by BobBagwill »

tialaramex wrote: post #35
IshKebab wrote: post #19

Earlier quoted context omitted.

Feels accurate to me. He's clearly anticipating the "but how will I run Debian on my PDP-11??" naysayers that always try to derail things.

Right. I do have some nostalgia for installing Linux on a brand new PC which had less total RAM than my computer today has cache, but we need to be clear eyed about what makes sense for a maintained piece of software. I also have feelings about steam trains, but burning coal is not a sensible way to power a train in 2025. A nostalgia-fuelled Linux distro, maybe using a deliberately slimmed down or retro kernel, and c…

> I also have feelings about steam trains, but burning coal is not a sensible way to power a train in 2025.

Solved problem:

United States Patent Application 3127321 Date of Patent March 31, 1964 NUCLEAR REACTOR FOR A RAILWAY VEHICLE

Re: Hard Rust requirements from May onward

#237

Post by lelanthran »

testdelacc1 wrote: post #124
lelanthran wrote: post #102

Earlier quoted context omitted.

> 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 ha…

> not the same as having a hostile community Hostile according to who? According to the haters, maybe. I’m sure the Go community was called “hostile” by haters back in the day. Look at the drama created by Linux maintainers who were being insanely hostile, coming up with spurious objections, being absolute asshats - to the point where even Linus said enough was enough. The Rust for Linux members conducted themselves…

> I’m sure the Go community was called “hostile” by haters back in the day.

I was there, and no it wasn't. The Go community didn't jump into every programming discussion throwing around accusations of dinosaur, insecurity, etc.

Re: Hard Rust requirements from May onward

#238

Post by bgwalter »

pizlonator wrote: post #226

They’d be better off just compiling the package manager with Fil-C No changes required. Bringing up the fil-C toolchain on weird ports is probably less work than bringing up the Rust toolchain

I agree with this. Fil-C is really impressive and Rust can panic, too (if panics/aborts are a concern).

Re: Hard Rust requirements from May onward

#239

Post by dvtkrlbs »

kstrauser wrote: post #225
allisdust wrote: post #204

Earlier quoted context omitted.

Sadly most people don't agree with this I have been seeing hatred on this forum towards Rust since long time. Initially it didn't make any kind of sense. Only after actually trying to learn it did I understand the backlash. It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried. Especially coming from the world of memory managed languages. This creates push back a…

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

Re: Hard Rust requirements from May onward

#240

Post by lelanthran »

timeon wrote: post #127
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…

> Scala? Kotlin? Swift? Zig? None of those languages have built such poor reputations for their communities. > I didn't see C++ users jumping into Rust threads posting attacks, but there are many examples of Rust users jumping into C++ or C threads, posting attacks. I already seen this with Zig. And even without language communities. Look at this whole thread. Look in to the mirror. Regularly when Rust is mentioned o…

> Look in to the mirror.

Pointing out that the Rust community has gained such a poor reputation while other communities have not requires "looking into the mirror"?

Post reply on HN