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

61–70 of 797 posts

Re: Hard Rust requirements from May onward

#61

Post by crote »

uecker wrote: post #5
CartwheelLinux wrote: post #2

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…

> 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 code and accepts all the good code without making any code changes, which of course isn't going to happen.

Garbage collection is a huge dealbreaker for the people still on C/C++. This immediately rules out the vast majority of memory-safe languages. What is left is pretty much only Zig and Rust. Both have their pros and cons, but Rust seems to be more mature and has better community adoption.

The way I see it, the pro-memory-safety crowd is saying "There's a giant hole in our ship, let's use Rust to patch it", and the anti-Rust crowd yells back "I don't like the color of it, we shouldn't repair the hole until someone invents the perfect solution". Meanwhile, the ship is sinking. Do we let the few vocal Rust haters sink the ship, or do we tell them to shut up or show up with a better alternative?

Re: Hard Rust requirements from May onward

#62

Post by alt187 »

tcfhgj wrote: post #10
CartwheelLinux wrote: post #2

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 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 wolf about this is a forum full of contemptious little angry men who spend weeks researching people they hate on the internet. No one seems to want to touch the subject from fear of being associated with them.

I'll give it to you, this is not a great time.

Re: Hard Rust requirements from May onward

#63

Post by zozbot234 »

hulitu wrote: post #58
CartwheelLinux wrote: post #2

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 don't quite understand the pushback against memory safe languages As far as i read on HN, the only memory safe language discused on HN is rust and mostly with childish pro arguments.

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.

Re: Hard Rust requirements from May onward

#64

Post by NewsaHackO »

DaSHacka wrote: post #37
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.

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"

Is your point that rust doesn't run on a computer built in 2020?

Re: Hard Rust requirements from May onward

#65

Post by testdelacc1 »

DaSHacka wrote: post #37
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.

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?

Re: Hard Rust requirements from May onward

#66

Post by einpoklum »

nikanj wrote: 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-capabilities hardware, like embedded systems and micro-controllers. That includes newer offerings from ST Microelectronics, Espressif, Microchip Technology etc. (and even renewed 'oldies' like eZ80's which are compatible with Zilog's 8-bit Z80 from the 1970s - still used in products sold to consumers today). The larger ones are quite capable pieces of hardware, and I would not be surprised if some of them use Debian-based OS distributions.

Re: Hard Rust requirements from May onward

#67

Post by bestouff »

hulitu wrote: post #56
mdhb wrote: post #50

Earlier quoted context omitted.

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.

> The reason is actually incredibly clear There is no guarantee that other bugs do not flurish in the rust echosystem. There are no publicly known quality code checks of rust programs except a big "trust us"(see firefox with all its CVEs, despite "rust"). And combined with the Cargo echosystem, where every malicious actor can inject malware is a big warning sign.

There are guarantees that many types of bugs won't happen in Rust code. That alone is a great progress.

Re: Hard Rust requirements from May onward

#68

Post by mdhb »

Antibabelic wrote: post #32
nikanj wrote: 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

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.

Isn’t this the specific reason things like the raspberry pi were developed to solve?

Re: Hard Rust requirements from May onward

#69

Post by kaoD »

hulitu wrote: post #56
mdhb wrote: post #50

Earlier quoted context omitted.

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.

> The reason is actually incredibly clear There is no guarantee that other bugs do not flurish in the rust echosystem. There are no publicly known quality code checks of rust programs except a big "trust us"(see firefox with all its CVEs, despite "rust"). And combined with the Cargo echosystem, where every malicious actor can inject malware is a big warning sign.

I might be misunderstanding here but... what you're saying is that Rust programs can still have bugs? Isn't that the same as other programs except Rust prevents the most disastrous and common bugs that lead to most CVEs?

If I got that right, how is "it's still not perfect" an argument?

Agree with the Cargo objection.

Re: Hard Rust requirements from May onward

#70

Post by mdhb »

hulitu wrote: post #56
mdhb wrote: post #50

Earlier quoted context omitted.

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.

> The reason is actually incredibly clear There is no guarantee that other bugs do not flurish in the rust echosystem. There are no publicly known quality code checks of rust programs except a big "trust us"(see firefox with all its CVEs, despite "rust"). And combined with the Cargo echosystem, where every malicious actor can inject malware is a big warning sign.

a bunch of major projects have conclusively shown that moving to memory safe languages without any doubt whatsoever results in more secure software.
Post reply on HN