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

401–410 of 797 posts

Re: Hard Rust requirements from May onward

#401

Post by fishmicrowaver »

4bpp wrote: post #192
tcfhgj wrote: 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"

That is a crude and politically inept way of putting it, but do you not think there is some grain of truth to it? If you opt into something with as high a barrier to entry and necessary time commitment as a programming language, you naturally also opt into the existing community around that language, because that will be where the potential contributors, people to help you solve issues, and people you have to talk to…

Is that stuff still going on? People were rather intense about certain politics during COVID, but outside of some furries on the Rust discord I haven't noticed anything outwardly political?

Re: Hard Rust requirements from May onward

#402

Post by int0x29 »

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

This isn't promotion. There is a feature. It is written. They have decided to ship it.

Secondly the argument that because you don't use it in your area no one should use it in OS development is nonsensical.

Re: Hard Rust requirements from May onward

#404

Post by csande17 »

woodruffw wrote: post #371
cwzwarich wrote: post #278

Earlier quoted context omitted.

The Rust specification you link is performative and only intended to satisfy requirements of certification processes. No one is actually using it to implement the language, as far as I am aware. There is other work on specifying Rust (e.g. the Unsafe Code Guidelines Working Group), but nothing approaching a real spec for the whole language. Honestly, it is probably impossible at this point; Rust has many layers of im…

“There’s a standard, but it’s performative” is a different argument than the top level one. But even if we accept that, it doesn’t seem like a good comparative argument: anybody who has written a nontrivial amount of C or C++ has dealt with compiler-defined behavior or compiler language extensions. These would suggest that the C and C++ standards are “performative” in the same sense, but repeated claims about the vir…

They have a document that they sometimes describe using the word "specification", but its README clarifies that it's not actually a specification:

> The FLS is not intended to be used as the normative specification of the Rust language

Re: Hard Rust requirements from May onward

#405

Post by nicoburns »

lelanthran wrote: post #4
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…

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.

> If you could separate the language from the acolytes it would have seen much faster adoption.

Good news: you can. And that's why it has had fast adoption.

(those advocating for Rust in "meme-like" ways are not generally the same people actually developing the Rust compiler or the core parts of it's ecosystem)

Re: Hard Rust requirements from May onward

#406

Post by hollerith »

4bpp wrote: post #192
tcfhgj wrote: 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"

That is a crude and politically inept way of putting it, but do you not think there is some grain of truth to it? If you opt into something with as high a barrier to entry and necessary time commitment as a programming language, you naturally also opt into the existing community around that language, because that will be where the potential contributors, people to help you solve issues, and people you have to talk to…

We need more effective ways to prevent ideological capture of our institutions especially when there is no actual connection between an institution's mission (e.g., to support the use of Rust) and religion, politics, sexuality or morals.

Re: Hard Rust requirements from May onward

#407

Post by hiccuphippo »

coderjames wrote: post #368
lambdaone wrote: post #161

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…

> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages > Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. But hasn't all that foundational code been stable and wrung out already over the last 30+ years? The .tar and…

Every software is stable and wrung out until someone finds an exploit.

Re: Hard Rust requirements from May onward

#408

Post by throwaway2037 »

The follow-up is solid gold:

    > I find this particular wording rather unpleasant and very unusual to what I'm used to from Debian in the past. I have to admit that I'm a bit disappointed that such a confrontational approach has been chosen.
Ref: https://lists.debian.org/debian-devel/2025/10/msg00286.html

Re: Hard Rust requirements from May onward

#409

Post by einpoklum »

fanf2 wrote: post #132
einpoklum wrote: post #40

That seems like a bad idea to me: Dependencies will be added, for very basic system utilities, on (parts of) a software ecosystem which is still a "moving target", not standardized, and IIANM itself has further dependencies. I wonder whether platform compatibility won't be jeopardized, either. I would be worried if even C++ dependencies were added for basic system utilities, let alone something like Rust. Now, grante…

Before apt, the main user interface for dpkg was dselect, which was written in C++

But doesn't this actually strengthen my point? Debian transitioned from a tool written in a more demanding language to a tool written in a less-demanding one.

Re: Hard Rust requirements from May onward

#410

Post by selfmodruntime »

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

> I know nobody that programms or even thinks about rust

This is your bias alone. I know tons of people and companies that do. Rust most likely runs on your device.

Post reply on HN