Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

41–50 of 797 posts

Re: Hard Rust requirements from May onward

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

[flagged]

Well, so far this thread has 0 people shilling Rust, a couple shilling Common Lisp and a bunch complaining about Rust shills (you included).

Makes you think, huh?

Re: Hard Rust requirements from May onward

#42

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?

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 basic initial support but no 'core' or 'std' builds yet. https://doc.rust-lang.org/rustc/platform-support/m68k-unknow... This should potentially be fixable.

Re: Hard Rust requirements from May onward

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

How can lisp be fast if it doesn't have static typing and uses GC?

Re: Hard Rust requirements from May onward

#44

The language is tough love, and I think it's important despite what the first respondent has said. Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage. I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe…

The pushback is against the acolytes not the language. If you could separate the language from the acolytes it would have seen much faster adoption.

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.

Re: Hard Rust requirements from May onward

#46
post #15

The language is incredibly frank, and I agree with it completely. The retro-computing hobby doesn't need the ability to run contemporary operating systems. It's insane that x86 Debian is still compiling all software targeting Pentium Pro (from 1995!). x64 Debian is a bit more modern, and you must splurge for a CPU from 2005 (Prescott) to get the plethora of features it requires

Wow, those are exactly the same targets I use for releasing x86 and x64 (Windows) builds, but even I think it's a little over the top for Debian to support Pentium Pro.

We're really talking about alpha, hppa, m68k and sh4

Re: Hard Rust requirements from May onward

#47
post #5

The language is tough love, and I think it's important despite what the first respondent has said. Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage. I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe…

I think the spin that Rust is necessarily the way forward is what is wrong. IMHO Rust has severe problems and what is considered "modern" is mostly taste. We have seen the same thing in the past with a push towards C++, Java, managed languages. What is new is that the free software movement is now controlled so much by corporate interests that some of these changes are pushed through aggressively against the interest…

> The whole point of free software should be that I do not have to adapt to some companies's idea of what is modern, if I do not want to.

This hasn’t changed.

Re: Hard Rust requirements from May onward

#48

The language is tough love, and I think it's important despite what the first respondent has said. Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage. I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe…

[flagged]

For me it actually is the language. While a little pushy at times I think the arguments for rewriting certain things in a safer language is well founded. If the apt tool chains is one of those places I'll leave for the Debian developers to determine, but for decompression tools I can see a benefit.

If Rust should be the language of choice, preferably not. The syntax is awful, the language is complicated and Rust programs seems to collect dependencies at the same rate as JavaScript. Where I might agree with you is that Rust seems to attract a certain type of people. They write absolutely brilliant software, but like the Rust compile, they are rather particular with what input they'll accept.

In the end I don't really care what apt is written in, I'm not the one writing the code. I just use the tool. It would be sad if some platforms are left behind, because the Rust developers don't care about them and not because they're no longer useful.

Re: Hard Rust requirements from May onward

#49

The language is tough love, and I think it's important despite what the first respondent has said. Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage. I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe…

The pushback is against the acolytes not the language. If you could separate the language from the acolytes it would have seen much faster adoption.

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

Rust is already pretty successful adoption wise. It’s powering significant parts of the internet, it’s been introduced in 3 major operating systems (Windows, Linux, Android), many successful companies in a variety of domains have written their entire tech stack in it. Adoption as measured by crates.io downloads has doubled every year for the last 10 years.

Now I’m imagining how much more widely Rust would be used if they had adopted your visionary approach of never saying anything positive about it.

Re: Hard Rust requirements from May onward

#50
post #34

Earlier quoted context omitted.

Many programmers feel the same way about Lispers. It's best to set aside your gut feelings about the community and think primarily about the technical and organizational merits and disadvantages of the technology.

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.
Post reply on HN