Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

91–100 of 797 posts

Re: Hard Rust requirements from May onward

#91

Earlier quoted context omitted.

Is it just the "retro-computing hobby"? There could still be businesses who might need support for old machines, especially in developing countries. I don't know the actual situation though, I'm open to the idea that my suggestion is insane.

It is not retro-computing. New 32-bit and x86 CPUs are produced, sold, and used today. See (relatively recent) list of manfuacturers here: https://en.wikipedia.org/wiki/List_of_x86_manufacturers and scroll down for other categories of x86 chip manufacturers. These have plenty of uses. Maybe in another 30 years' time they will mostly be a hobby, but we are very far from that time.

Which ones of those don’t have MMX / SSE? Debian is not enabling any x86 instruction extensions that didn’t ship on the Pentium Pro

Re: Hard Rust requirements from May onward

#92
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

I'll first say that 32-bit CPUs, including x86-based ones, are not retro computing. They still carry the load of all sorts of important computing systems, today. They are still being produced (IIANM, also by Intel and AMD). Sure, with much more limited use cases, and it's definitely not the mainstream, but it's there. Not a hobby and not for a 'retro' experience. But you are also completely ignoring limited-capabilit…

32-bit might not be, but i686 definitely is. Last pure i686 chips without MMX shipped sometime around 1998-1999

Re: Hard Rust requirements from May onward

#93
post #89

Earlier quoted context omitted.

Java and C# are memory safe languages, as are common interpreted languages like Python and Ruby. Even JavaScript is memory safe, barring the possibility of subtle JIT bugs that may practically impact such safety.

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.

Re: Hard Rust requirements from May onward

#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

Re: Hard Rust requirements from May onward

#95
post #91

Earlier quoted context omitted.

It is not retro-computing. New 32-bit and x86 CPUs are produced, sold, and used today. See (relatively recent) list of manfuacturers here: https://en.wikipedia.org/wiki/List_of_x86_manufacturers and scroll down for other categories of x86 chip manufacturers. These have plenty of uses. Maybe in another 30 years' time they will mostly be a hobby, but we are very far from that time.

Which ones of those don’t have MMX / SSE? Debian is not enabling any x86 instruction extensions that didn’t ship on the Pentium Pro

This is not accurate, the Trixie 32-bit release requires a Pentium 4.

Re: Hard Rust requirements from May onward

#96
post #24
post #10

Earlier quoted context omitted.

I haven't either, until I read comments on Rust in Linux on social media outside HN. Apparently, Rust is part of the "woke agenda"

Yep, I noticed that under a lot of videos mentioning rust in kernel, or rust in general there's a high chance that the comment section will just be straight up lifted from 4chan pol or a similar place

Is there any particular reason for this? Do they not agree with the code of conduct more than normal?

Re: Hard Rust requirements from May onward

#97
post #62
post #10

Earlier quoted context omitted.

I haven't either, until I read comments on Rust in Linux on social media outside HN. Apparently, Rust is part of the "woke agenda"

People are (understandably) sick of the fact that for whatever reason, the biggest proponents of Rust are insufferable. Personally, I'm simply bothered by the fact that (one of?) the most famous figure of Rust on Linux and Rust Forever consumes and advocates for pornography that's illegal in my country, without being held accountable by the community. From what I could piece together, the only group who ever cried wo…

I'm genuinely not sure who you're talking about or whether this is an accurate characterization of their views. For that matter, I'm not sure what country you're in and whether I myself agree with that country's laws about whatever kind of pornography this is. Certainly plenty of countries I don't live in and have no ties to have laws I disagree with or violate routinely.

I'm pretty suspicious of demands for communities to hold people accountable, especially when the community in question is a loose group of people who mostly communicate online and are united by their shared use of a specific programming technology; and who probably disagree on all sorts of other issues, including contentious ones.

Re: Hard Rust requirements from May onward

#98
post #89

Earlier quoted context omitted.

Java and C# are memory safe languages, as are common interpreted languages like Python and Ruby. Even JavaScript is memory safe, barring the possibility of subtle JIT bugs that may practically impact such safety.

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!

There are currently no widely-used programming languages other than Rust that offer the memory safety guarantees Rust has without a garbage collector. I think this is bad, and I wish more people would develop memory-safe systems languages that explore other parts of the design space like Rust does. But in the meantime, Rust is pretty good, certainly preferable to C or C++.

Re: Hard Rust requirements from May onward

#100

> It's important for the project as whole to be able to > move forward and rely on modern tools and technologies > and not be held back by trying to shoehorn modern software > on retro computing devices. Rust is the present and the future and it's quite logical that it becomes a key requirement in Linux distributions, but I'm really not convinced by the wording here… This last sentence feels needlessly antagonistic.

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.

But the message is not just "we will require Rust and here's the timeline (and some things may break)", it's also "I know what I'm going to break and it's your problem to fix it" (via the CC line) and ends in a passive-aggressive way (the phrase "Thank you for your understanding." is basically a polite way of saying "and fuck you too."). This gets people off-side, and makes it more likely they're going to throw up barriers rather than either do what you ask or find some other way to collaborate/achieve the ideal outcome.
Post reply on HN