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

161–170 of 797 posts

Re: Hard Rust requirements from May onward

#161

Post by lambdaone »

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 dropped for pragmatic reasons, so can these architectures. If people really, really want to preserve these architectures as ongoing platforms for the future, they need to step up and create a backend for the Rust toolchain that supports them.

Re: Hard Rust requirements from May onward

#162

Post by kaoD »

hypeatei wrote: post #146
zozbot234 wrote: post #93

Earlier quoted context omitted.

Swift is also memory safe in that sense.

Swift uses Automatic Reference Counting (ARC) which is a form of garbage collection.

Now I'm curious, how does it GC cycles, if at all?

EDIT: from a brief search: it doesn't.

Re: Hard Rust requirements from May onward

#163

Post by fweimer »

curt15 wrote: post #130
zozbot234 wrote: post #42

Earlier quoted context omitted.

m68k has a LLVM port already, so Rust can be implemented for that platform.[0] It would be nice to have LLVM backends for alpha, hppa and sh4 - these older architectures tend to be quite simple so a working LLVM has plenty of value as a reference and for educational use. (LLVM even used to have an in-tree DEC Alpha backend, though that was back in 2011 and not relevant to any version of Rust.) [0] Looks like there is…

Shouldn't the codegen_gcc project[1] theoretically allow Rust to target backends that only GCC supports? [1] https://github.com/rust-lang/rustc_codegen_gcc

LLVM is desirable for other reasons (LLVMpipe for example), so investing into an LLVM port is probably a better use of limited resources than improving and maintaining a retargeted rustc for GCC.

Re: Hard Rust requirements from May onward

#164

Post by andrepd »

superkuh wrote: post #157

Rust is a great language for devs. They love it and how developer centric everything about it is. But for end users on Debian trying to compile rust stuff is a nightmare. They do breaking changes in the compiler (rustc) every 3 months. This is not a joke or exaggeration. It's entirely inappropriate to use such a rapidly changing language in anything that matters because users on a non-rolling distro, LIKE DEBIAN, wil…

rustc stable is continually updated yes. But surely any given release of debian targets a specific version of the toolchain. What's the issue?

Re: Hard Rust requirements from May onward

#165

Post by fweimer »

viraptor wrote: post #121
troupo wrote: post #21

Earlier quoted context omitted.

> Wonder what this means for those architectures then? They will be rebranded as "retro computing devices"

Most don't need to be rebranded. Alpha and hppa are retro computing and haven't been available to buy for 18 and 15 years respectively. Sh4 died this year. Only m68k is still holding on, but is a rounding error in the number is users.

Interesting bit about SH-4. I thought that Renesas had previously promised parts availability until 2029?

Re: Hard Rust requirements from May onward

#166

Post by onli »

superkuh wrote: post #157

Rust is a great language for devs. They love it and how developer centric everything about it is. But for end users on Debian trying to compile rust stuff is a nightmare. They do breaking changes in the compiler (rustc) every 3 months. This is not a joke or exaggeration. It's entirely inappropriate to use such a rapidly changing language in anything that matters because users on a non-rolling distro, LIKE DEBIAN, wil…

I wouldn't see it that way.

First, Debian is not a distro where users have to compile their software. The packages contain binaries, the compilation is already done. The instability of Rust would not affect users in any way.

And second, as a developer, I never had a more unpleasant language to work with than Rust. The borrow checker back then was abysmal. Rust is not about developer happiness - Ruby is - but its memory safety makes it a useful option in specific situation. But you can be sure that many developers will avoid it like a plague - and together with the breakage and long compile times that's probably why moves like the one dictated here are so controversial.

Re: Hard Rust requirements from May onward

#167

Post by loglog »

superkuh wrote: post #157

Rust is a great language for devs. They love it and how developer centric everything about it is. But for end users on Debian trying to compile rust stuff is a nightmare. They do breaking changes in the compiler (rustc) every 3 months. This is not a joke or exaggeration. It's entirely inappropriate to use such a rapidly changing language in anything that matters because users on a non-rolling distro, LIKE DEBIAN, wil…

Since when do Debian users need to compile APT themselves?

Re: Hard Rust requirements from May onward

#168

Post by Measter »

pron wrote: post #149
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++.…

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

Zig only does bounds checking by default in Debug and ReleaseSafe builds. If you build with ReleaseFast or ReleaseSmall it will happily do an out of bounds read: https://godbolt.org/z/733PxPEPY

Re: Hard Rust requirements from May onward

#169

Post by bluGill »

forgetfulness wrote: post #135
viraptor wrote: post #121

Earlier quoted context omitted.

Most don't need to be rebranded. Alpha and hppa are retro computing and haven't been available to buy for 18 and 15 years respectively. Sh4 died this year. Only m68k is still holding on, but is a rounding error in the number is users.

Aren’t m68k computers only a few models from the 1990s and 1980s, and some more recent hobby projects? That’s squarely in the retro computing enthusiasts category. I’m not in the Debian world, but those do seem to me like the types of systems that could use their own specialized distros rather than being a burden to the mass market ones. It’s not as if you could run a stock configuration of any desktop environment on…

m68k is used in a number of embedded systems today. It is unknown (to me) how many of those run linux (as opposed to some other embedded OS), but I would guess at least some do. I also don't know how many run (or want to run) debian vs something else (a custom yacto distribution is my first guess), but that might be non-zero. It is possible someone is running a non-debian distribution and using debian packages to provide their updates.

Does or should debian care? I don't know.

Re: Hard Rust requirements from May onward

#170

Post by Galanwe »

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…

[flagged]
Post reply on HN