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

71–80 of 797 posts

Re: Hard Rust requirements from May onward

#71

Post by zozbot234 »

crote wrote: post #61
uecker wrote: post #5

Earlier quoted context omitted.

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

The problem is not so much GC itself, but more like pervasive garbage collection as the only memory management strategy throughout the program. Tracing GC is a legit memory management strategy for some programs or parts of a program.

Re: Hard Rust requirements from May onward

#72

Post by einpoklum »

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.

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.

Re: Hard Rust requirements from May onward

#73

Post by lelanthran »

kaoD wrote: post #44
lelanthran wrote: post #4

Earlier quoted context omitted.

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.

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

Re: Hard Rust requirements from May onward

#74

Post by [deleted] »

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?

[deleted]

Re: Hard Rust requirements from May onward

#75

Post by mid-kid »

Wouldn't it make sense to wait for (or support) one of the rust-for-GCC ports to become viable? As far as I understand, rust in the kernel won't become mandatory either until it's supported by GCC, and as a boon, with multiple implementations you can be more certain that the language won't move as fast and break things anymore. There's already upstream rust support in GCC, so I don't reckon it's that far off from being usable, at least for projects choosing to target it specifically.

Furthermore, if these architectures are removed from further debian updates now, is there any indication that, once there's a rust toolchain supporting them, getting them back into modern debian wouldn't be a bureaucratic nightmare?

Re: Hard Rust requirements from May onward

#76

Post by julian-klode »

mid-kid wrote: post #75

Wouldn't it make sense to wait for (or support) one of the rust-for-GCC ports to become viable? As far as I understand, rust in the kernel won't become mandatory either until it's supported by GCC, and as a boon, with multiple implementations you can be more certain that the language won't move as fast and break things anymore. There's already upstream rust support in GCC, so I don't reckon it's that far off from bei…

Ports are not part of Debian and particularly don't release with Debian, they only ship unstable.

Re: Hard Rust requirements from May onward

#77

Post by tcfhgj »

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.

Firefox is 29% Javascript, 28% C++, 22% HTML, 10% C, 3% Python, 2,6% Kotlin and 5% other

> There is no guarantee that other bugs do not flurish in the rust echosystem.

well, less likely than in C thanks to a advanced type system, e.g. allowing authors of abstractions make their API much more fool proof.

> where every malicious actor can inject malware is a big warning sign.

Very much doubt that is the case...

Re: Hard Rust requirements from May onward

#78

Post by tialaramex »

IshKebab wrote: post #51
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"

No, supporting 5 year old mainstream hardware is a very reasonable thing to do. Supporting 20 year old hardware that barely anyone used even when it was new is not.

Indeed. Four targets are identified as potentially affected:

alpha, hppa, m68k and sh4

To be fair, lots of people did use Motorola 68xxx CPUs when those were new, it's just that it was 40+ years ago in products like the Commodore Amiga. The SH4 is most popularly connected to the Dreamcast, Sega's video game console from back when Sega made video game consoles.

The Alpha and PA Risc were seen in relatively recent and more conventional hardware, but in much tinier numbers, and when I say relatively I mean early this century, these are not products anybody bought five years ago, and when they were on sale they were niche products for a niche which in practical terms was eaten by Microsoft.

Re: Hard Rust requirements from May onward

#80

Post by lelanthran »

testdelacc1 wrote: post #49
lelanthran wrote: post #4

Earlier quoted context omitted.

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

> Acolytes being the people talking positively about their experience using a language and the strengths they think it has.

No, it's the people who have given rise to the multiple Rust memes over the years.

I'm battling to think of any other about-to-go-mainstream language that had the reputation of a hostile community. Scala? Kotlin? Swift? Zig? None of those languages have built such poor reputations for their communities.

After all, for quite a few years every thread on forums that mentioned C or C++ was derailed by Rust proponents. I didn't see C++ users jumping into Rust threads posting attacks, but there are many examples of Rust users jumping into C++ or C threads, posting attacks.

> That’s an interesting thought. It would run counter to everything we know about human nature, but interesting nevertheless.

Well, the fact that Rust is an outlier in this sample should tell you everything you need to know; other up-and-coming languages have not, in the past, gotten such a reputation.

Post reply on HN