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

141–150 of 797 posts

Re: Hard Rust requirements from May onward

#141

Post by the__alchemist »

Surac wrote: post #94

I think this is the wrong way to promote rust. For me rust is just a hype. I know nobody that programms or even thinks about rust. I’m from the embedded world an there c is still king. I understand that some will see rust as a good alternative, but as long as the real money is made in c it is not ready

Rust slaps on embedded too; I think that's one of its core competencies. But you have to do a lot of leg work for each piece of hardware because manufacturer support isn't there, and the OSS libs are usually not great. If your requirement is "Use only the most popular language in this domain", that's fine, but there's no point in evaluating or discussing other languages if so; the outcome is predetermined.

I think the linked requirement, the hype you see, and rust's own material is misleading: It's not a memory-safety one-trick lang; it's a nice overall lang and tool set.

Re: Hard Rust requirements from May onward

#142

Post by undeveloper »

noosphr wrote: 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.

"why use C when I could simply link to node?"

Re: Hard Rust requirements from May onward

#143

Post by littlestymaar »

testdelacc1 wrote: post #65
DaSHacka wrote: post #37

Earlier quoted context omitted.

Or those annoying nagging "well, what if I don't have an X86_64 CPU that was made in the last five years?", to which obviously our response should be: "get different hardware LOL, closedwontfix"

Has Linux dropped support for older x86 CPUs?

Rust hasn't either AFAIK.

Re: Hard Rust requirements from May onward

#144

Post by pseudalopex »

einpoklum wrote: post #84
mirashii wrote: post #60

Earlier quoted context omitted.

> Dependencies will be added, for very basic system utilities, on (parts of) a software ecosystem which is still a "moving target", not standardized, This is the status quo and always has been. gcc has plenty of extensions that are not part of a language standard that are used in core tools. Perl has never had a standard and is used all over the place.

If you're designing an OS distribution, you would have your base system written adhering strictly to language standards and without relying on flakey extensions (not that GCC C extensions are flakey, I'm guessing most/all of them are stable since the 1990s), and minimizing reliance on additional tools. For example, IIUC, you can build a perl interpreter using a C compiler and GNU Make. And if you can't - GCC is quite…

The procedure to produce GCC you cited was 13 steps. Many of the tools were made after distributions required GCC. And a similar procedure could produce a Rust compiler.

Re: Hard Rust requirements from May onward

#145

Post by bfkwlfkjf »

julian-klode wrote: post #55
noosphr wrote: post #25

Earlier quoted context omitted.

You could just read his signiture in the mailing list. https://mastodon.social/@juliank >Senior Engineer at Canonical.

Yes that's true and there's synergies but keep in mind I also have a personal mind

[flagged]

Re: Hard Rust requirements from May onward

#146

Post by hypeatei »

zozbot234 wrote: post #93
kaoD wrote: post #89

Earlier quoted context omitted.

But op means memory and data safe, without a GC nor a runtime, so it can be used as a systems programming language. For "some reason" people only talk about Rust in this space!

Swift is also memory safe in that sense.

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

Re: Hard Rust requirements from May onward

#147

Post by loloquwowndueo »

0x000xca0xfe wrote: post #110
cmm11 wrote: 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.

It’s called openBSD :) (don’t get me wrong, openBSD is awesome, but the default install which is secure out of the box is a bit spartan heheh)

Re: Hard Rust requirements from May onward

#148

Post by tayo42 »

lelanthran wrote: post #73
kaoD wrote: post #44

Earlier quoted context omitted.

In my experience from these threads, there are more people polluting the discussion by complaining about Rust "acolytes" than actual acolytes. Rust haters seem strangely obsessed.

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

Rust language and rust community are intertwined. It's a design descion from the language creators

Re: Hard Rust requirements from May onward

#149

Post by pron »

zozbot234 wrote: post #71
crote wrote: post #61

Earlier quoted context omitted.

> I think the spin that Rust is necessarily the way forward is what is wrong. Well, what's the alternative? The memory safety problem is real, I don't think there is any doubt about that. C/C++ is a dead end: the community has thoroughly rejected technical solutions like the Circle compiler, and "profiles" are nothing more than a mirage. They are yet again trying to make a magical compiler which rejects all the bad c…

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 rabid software correctness advocate, and I think that people should acknowledge that correctness, safety (and the reasons behind it) are much more complex than the binary question of what behaviours are soundly disallowed by a language (or ATS advocates would say that from that their vantage point, Rust is just about as unsafe as C, and so is completely uninteresting from that perspective).

The complexity doesn't end with spatial vs temporal safety. For example, code review has been found to be one of the most effective correctness measures, so if a language made code reviews easier, it would be very interesting from a correctness/security perspective.

Re: Hard Rust requirements from May onward

#150

Post by [deleted] »

troupo wrote: post #21
justinclift wrote: post #6

One of the follow up messages is interesting: https://lists.debian.org/debian-devel/2025/10/msg00288.html > Rust is already a hard requirement on all Debian release architectures and ports except for alpha, hppa, m68k, and sh4 (which do not provide sqv). Wonder what this means for those architectures then?

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

[deleted]
Post reply on HN