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

751–760 of 797 posts

Re: Hard Rust requirements from May onward

#751

Post by RustSupremacist »

blub wrote: post #679
jeroenhd wrote: post #437

Earlier quoted context omitted.

If only more people were willing to let their opinions be changed over time like that, rather than clinging onto them.

It depends if the original opinion was a reasoned one or just based on personal feelings. The dependency explosion is still a problem and I’m not aware of any real solution. It would have been interesting to to see why their opinion changed… I’m guessing it’s as simple as the perceived benefits overriding any concerns and no major supply-chain attacks being known so far.

It depends on how you define supply chain attacks.

Recently, there was an exploit discovered in an abandoned Rust package that was used by many other Rust projects, many unaware of it due to the sheer number of dependencies. Whether by negligence or malice, having a known vulnerability that permeates significant portions of the ecosystem is on the order of a supply chain attack.

https://edera.dev/stories/tarmageddon

Worse yet, independent research suggests that the state is arguably much worse: https://00f.net/2025/10/17/state-of-the-rust-ecosystem/

Given projects that make the claim of switching to Rust to access new contributors, it remains to be seen how many of those new contributors are capable of being retained.

Re: Hard Rust requirements from May onward

#752

Post by mgh95 »

steveklabnik wrote: post #726
mgh95 wrote: post #379

Earlier quoted context omitted.

Large parts of tooling dependent on cargo; for examples, lsp, analyzer, etc. Once you take out cargo, rusts development environment becomes quite poor.

This is also just a matter of work, for example, the Buck folks have put in the work so that rust-analyzer works well with projects based on it.

That's good. I generally think these kinds of tools (lsp, analyzers, etc.) should be based upon CLI tools. I'll be more open to when either projects seeking to integrate rust utilize tools such as buck or these tools can be more easily integrated into make/cmake based projects.

There is a lot of legacy code out there and I generally feel like many of the rust advocates forget how important it is to play well with legacy project setups.

Re: Hard Rust requirements from May onward

#753

Post by RustSupremacist »

4bpp wrote: post #158
cmm11 wrote: post #54

If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages. Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725

Unfortunately, this kind of culture where you joyfully screw over your real users to chase the approval and benefit of some spherical user in a vacuum that you would like to cater to has become endemic in the free software world. It probably started with GNOME 3 (deliberately strip-mined of functionality, actively hostile to customisability, wasteful of screen space, all for the sake of chasing some HCI-prophesied tr…

GNOME highlights most of the worst possible characteristics open source has, especially their last 15 years. Narcissism, opaque decisions, politics, virtue signaling, 4chan obsession, and toxic behavior describe just the past few months of that project. It's high time to cancel GNOME.

Re: Hard Rust requirements from May onward

#754

Post by testdelacc1 »

hunterpayne wrote: post #749
testdelacc1 wrote: post #671

Earlier quoted context omitted.

Here, find the “null result” in this study by the Android team - Eliminating Memory Safety Vulnerabilities at the Source ( https://security.googleblog.com/2024/09/eliminating-memory-s... ). They stopped adding new memory unsafe code and they saw a dramatic drop in the number of memory safety vulnerabilities. They only write new code in Kotlin or Rust now. The Android team shipped a more secure operating system to bil…

> If you had you wouldn’t conflate memory safety with a lack of memory manipulation. We are all aware of unsafe. We are also aware that all those assurances of safety go away in those circumstances. This is cherry-picking. I didn't say all research papers, just most. This is a very specific circumstance. Under specific circumstances these ideas will work. This example is one where the replaced code wasn't that old, o…

> android runs on a very specific set of hardware

How could anyone possibly think this? It runs on ARMv7, ARM64, x86 and x86-64. What else do you want it to run on? It runs on literally billions of devices, made by hundreds of manufacturers - phones, TVs, Chromebooks, cars. All of these couldn’t be more different.

Windows/MacOS are examples of supporting specific hardware. Android works on incredibly diverse hardware. All of which will be powered by Rust now.

> wasn’t that old

Binder is about 20 years old. Linux is 30 years old, by the way. It was developed across 3 different corporations. There’s a reason the code was incredibly difficult to make changes to.

Could we stick to facts, please? This stuff isn’t hard to google.

> I also doubt switching to Rust is always a good idea.

No one said this, by the way. This is a strawman you’ve constructed.

PS the problem is that none of what you write makes sense. No one is giving me any pushback apart from you. And the only way you’re able to pushback is by completely ignoring facts.

Re: Hard Rust requirements from May onward

#755

Post by LtWorf »

loeg wrote: post #674
LtWorf wrote: post #595

Earlier quoted context omitted.

You can only run the binaries if you have the libc to run them.

You say that like it is a higher or even comparable barrier to having alpha/m68k/sh4 hardware; it isn't.

Uh? I don't understand what you're saying.

Re: Hard Rust requirements from May onward

#756

Post by tsimionescu »

baobun wrote: post #335
tsimionescu wrote: post #57

Earlier quoted context omitted.

It's much more common to find businesses running on very old hardware in developed countries, not in developing ones. Developing nations basically didn't use computers 20-30 years ago, there's no random remnants from that era beyond some extreme tail end. And, given how the PC & server market evolved in the 2000s and 2010s, it was cheaper to buy a then-current x86 than to import some ancient Alpha system from whereve…

Are you speaking from experience? There's a non-negligble amount of "handed-down" refurbished hardware from developed to developing. PCs and servers that are already 5+yo and out of market at installation.

I'm sure that's true for 5-10 year old tech, as the market has changed significantly. But I'd bet you'll be very hard pressed to find any businesses running on Alpha or HP-PA or whatever other ancient architectures might not have a Rust compiler available. Especially so if you were to look for businesses running modern Debian on such systems...

Re: Hard Rust requirements from May onward

#757

Post by steveklabnik »

mgh95 wrote: post #752
steveklabnik wrote: post #726

Earlier quoted context omitted.

This is also just a matter of work, for example, the Buck folks have put in the work so that rust-analyzer works well with projects based on it.

That's good. I generally think these kinds of tools (lsp, analyzers, etc.) should be based upon CLI tools. I'll be more open to when either projects seeking to integrate rust utilize tools such as buck or these tools can be more easily integrated into make/cmake based projects. There is a lot of legacy code out there and I generally feel like many of the rust advocates forget how important it is to play well with leg…

For RA, it just needs a config file, Buck shipped a tool that writes it out for you.

Re: Hard Rust requirements from May onward

#758

Post by RustSupremacist »

pizlonator wrote: post #558
julian-klode wrote: post #520

Earlier quoted context omitted.

> > since it only supports amd64 at this time and is maintained by a single genius. > That's easily fixable. as easily as fixing Rust to work on the remaining 4 architectures? > > It also doesn't help you to attract new contributors. > I don't understand this point. C++ doesn't attract a lot of developers, Rust attracts many more. I want more community, particularly _young_ community. I don't wanna work on this alone…

> as easily as fixing Rust to work on the remaining 4 architectures? Easier, because you won't have to port Fil-C to all of the architectures in order to use it on amd64. > C++ doesn't attract a lot of developers, Rust attracts many more. C is #2 on TIOBE. C++ is #3 on TIOBE. Rust is #16 on TIOBE. So I don't know what you're talking about

Rust is #16 on TIOBE, down from #13.

GitHub also just published Octoverse 2025 and Rust still hasn't cracked the top 10: https://github.blog/news-insights/octoverse/octoverse-a-new-...

Meanwhile, C++ is steadfast and even C is on the edges.

Looking at these lists, Go is an interesting option. It's rising in popularity and there is also a young community interested in it. It also integrates much better with existing C projects. Are there requirements for manual memory management? Would porting to Go instead of Rust have noticeable impacts on performance? Thinking about it now, Go seems like a more prudent option than Rust that achieves all of the publicly stated goals.

Re: Hard Rust requirements from May onward

#759

Post by ok123456 »

jeroenhd wrote: post #743
bgwalter wrote: post #499

Earlier quoted context omitted.

If only a reason were given. This is the original: > Rust is a security nightmare. We'd need to add over 130 packages to main for sequoia, and then we'd need to rebuild them all each time one of them needs a security update. What has changed? Why is 130 packages for a crypto application acceptable?

That's not a Rust problem, that's a sequoia problem. As for why, probably the same reason the dependency tree for gnupg (generate with `debtree -R -b gnupg` but grepping out all the gcc/mingw dependencies) looks like this: https://static.jeroenhd.nl/hn/gnupg.svg There's probably a good reason why I need libjpeg62, libusb-1.0-0-dev, and libgmp3 to compile gnupg, though they're hidden away from the usual developer docs…

Is it? Rust, or rather its online acolytes, deems a simple linked list "too complicated" for mere mortals, and routinely tells people "just" to use a crate that does it for you.

To me, this sounds like "leftpad" but for CS1 data structures.

Re: Hard Rust requirements from May onward

#760

Post by throwaway2037 »

zahlman wrote: post #745
throwaway7356 wrote: post #688

Earlier quoted context omitted.

Debian doesn't ship files in /usr/local. You can of course add your own "apt" binary in /usr/local/bin/apt which can be written in any language you like, say COBOL, Java, Common Lisp or Python.

Ah, of course. I guess this wrapper is provided by Mint.

I am curious: What does the wrapper do? Can you share the source code here?
Post reply on HN