> Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious.

I think any projects that are run by people that see themselves as "X-people" (like Python-people, Perl-people) always have a bit "ick" reaction to new languages being added to projects they might see as part of a language's community.

So say you're a C++ developer, contributed to APT over the years, see all of it linked to the C++ community which you are part of too, and someone wants to start migrating parts of it to Rust/$NewLang. I think it might sometimes affect more for these people than just the code, might even be "attacking" (strong word perhaps) their sense of identity, for better or worse.

> Shell (which probably means specifically bash)

Debian has ongoing efforts to make many shell scripts (like postinst Scripts in packages etc.) non-bash-specific.

A minimal Debian installation doesn't contain bash, but rather dash, which doesn't support bash extensions.

> there are approximately five languages that are presumed to be acceptable for core applications in the base system: [...] Python

I don't know if you've tried to get someone else's Python running recently, but it has devolved into a disaster effectively requiring containers to accurately replicate the exact environment it was written in.

Core system applications should be binaries that run with absolutely minimal dependencies outside of default system-wide libraries. Heck, I would go as far as to say applications in the critical path to repairing a system (like apt) should be statically linked since we no longer live in a storage constrained world.

Is X11/KDE considered part of the "base system"? If yes, then:

    > indeed, there's quite a few commenters here who I think would be surprised to learn that not only is C++ on this list, but that it's been on it for at least 25 years

I wish, but I get new security bugs in those components like every year or so, not all are tracked with security updates to be fair, some we say it's your own fault if you use the library to parse untrusted code.

After all the library wasn't designed around safety, we assumed the .debs you pass to it are trusted in some way - because you publish them to your repository or you are about to install them so they have root maintainer scripts anyway.

But as stuff like hosting sites and PPAs came up, we have operators publishing debs for untrusted users, and hence suddenly there was a security boundary of sorts and these bugs became problematic.

Of course memory safety here is only one concern, if you have say one process publishing repos for multiple users, panics can also cause a denial of service, but it's a step forward from potential code execution exploits.

I anticipate the rewrites to be 1 to 1 as close as possible to avoid introducing bugs, but then adding actual unit tests to them.

> But hasn't all that foundational code been stable and wrung out already over the last 30+ years?

Not necessarily. The "HTTP signature verification code" sounds like it's invoking cryptography, and the sense I've had from watching the people who maintain cryptographic libraries is that the "foundational code" is the sort of stuff you should run away screaming from. In general, it seems to me to be the cryptography folks who have beat the drum hardest for moving to Rust.

As for other kind of parsing code, the various archive file formats aren't exactly evolving, so there's little reason to update them. On the other hand, this is exactly the kind of space where there's critical infrastructure that has probably had very little investment in adversarial testing either in the past or present, and so it's not clear that their age has actually led to security-critical bugs being shaken out. Much as how OpenSSL had a trivially-exploitable, high criticality exploit for two years before anybody noticed.

There are none. This is a canonical employee trying to force Ubuntu's decisions (rust coretools) on the wider Debian community.

Additionally, the fact that this comes across as so abrasive and off-putting is on brand for online Rust evangelicalism.

> But hasn't all that foundational code been stable and wrung out already over the last 30+ years?

No: a little less than 5 years ago there was CVE-2020-27350, a memory safety bug in the tar/ar implementations.

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

Recently the rust coreutils had a bug and this essentially disabled auto-updates on Ubuntu. :)

Seeing this tone-deaf message from an Ubuntu employee would be funny if I didn’t actually use Ubuntu. Looks like I have to correct that…

I really like the idea of Fil-C for derisking legacy code, but

- It's not an option for debian core infrastructure until it supports at least the same platforms debian does (arm, riscv, etc) and it currently only supports x86_64.

- It doesn't turn C into a modern language, since it looks like there's active development here getting the productivity benefits of moving away from C is likely still worth it.

If you're single platform (Fil-C is x86-64 only), if the program is finished (Fil-C doesn't magically make maintaining a C project any easier to handle) and if performance isn't relevant (Fil-C is and despite its originator's confidence always will be bigger and slower than what you have today) then I agree.

Making core package infrastructure 10x slower doesn't seem especially pragmatic.

Inviting rank amateurs to established projects while expecting them to operate as free labor in the hopes of future relevance for employment has a distinctly different feel. Missives like the OP feel like preying on a desperate and young generation when paired with the commentary.

If all the entry-level jobs are C or C++, do you think companies would have a hard time filling them? Would the unemployed new graduates really shun gainful employment if Rust wasn't part of the equation?

Meanwhile, hiring managers left and right are reporting that within hours of a job being posted, they are flooded with hundreds of applications. And you can't find a single person because of the programming language of your stack? And to remedy this, you're going to rewrite your stack in an unproven language? Have you considered that if you can't find anyone that it might not be a programming language or tech stack problem?

My experience in working in C++ was that the salary wasn’t as good as what I could get elsewhere. That was a big part of why I left, I didn’t hate the job.

Wow, I've never considered this aspect of it but you're right. If you want widespread access to incoming developers that can contribute to your project, that really does mean Rust by default at this point if you want a low level language regardless of what you prefer.

A pity the banks didn't do that with COBOL....

Is the pay good at your job? Rust jobs are few and far between, so I think Rustafarians are willing to take lower pay to work in their dream language. Companies will of course abuse this.

Yes, which is why in 2025 it is a good idea to use Rust with python bindings for your performance sensitive code.

A lot of the C code used in python is calling out to old, battle tested and niche libraries so it is unlikely that someone is going to replace those any time soon but Rust is definitely increasing as time goes on for greenfield work.

Not really.

All (current) languages eventually have a compiler/runtime that is memory unsafe. This is basically fine because it's a tiny amount of surface area (relative to the amount of code that uses it) and it exists in a way that the input to is relatively benign so there's enough eyes/time/... to find bugs.

There's also nothing stopping you from re-implementing python/ruby/... in a safer way once that becomes the low hanging fruit to improve computer reliability.

I think this is a you problem

as in that "isn't the style of code you are used too"

I don't think "how well people not familiar with you language can read it" is a relevant metric for most languages.

Also IMHO while C feels readable it isn't when it matters. Because it very often just doesn't include information you need when reading. Like looking at function header doesn't tell you if a ptr is nullable, or if a mut ptr is a changeable input value or instead is a out ptr. which is supposed to point to unitialized memory and if there is an error how that affects the state of the validity of any mutable ptrs passed in. To just name some example (lets not even get started about pre processor macros pretending to be C functions). In conclusion while C seems nice to read it is IMHO often a painful experience to "properly" read it e.g. in context of a code review.

As a side note: The seemingly verbose syntax of e.g. `chrono::DateTime` comes from there being 2 DateTime-types in use in the module, one from the internationalization library (icu) and one from a generic time library (chronos). Same for Sender, etc. That isn't a supper common issue, but happens sometimes.

I think the Rust example’s biggest readability sin is using the full names of things like foo::bar::Baz instead of just Baz, but I get why they did that. When you import a lot of things into a file the latter way, it’s easy to get lost in “was that a foo Baz or a wiz Baz?” Sometimes it’s easier just to use the long names everywhere to be explicit.

If I wanted to tweak the Rust project, I’d feel pretty confident I was calling the right things with the right params.

That's an apples to oranges comparison.

Most of the code in that module is dedicated to the gui maintenance. The parts that do deal with time are perfectly legible.

> pretty much unreadable

I disagree. Both seem perfectly readable, assuming you know their preferred coding styles. As a non-C programmer, I absolutely despise running into #ifndef SOME_OBSCURE_NAME and `while (n) { if (g) {` but C (and in the latter case Go) programmers seem to love that style.

Comparing a bunch of small, barely integrated command line programs to a UI + calendar widget doesn't seem "of similar complexity" to me. Looking at a C clock widget (https://gitlab.freedesktop.org/xorg/app/xclock/-/blob/master...) the difference seems pretty minimal to me. Of course, the XClock code doesn't deal with calendars, so you have to imagine the extra UI code for that too.

https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/sr...

I beg to differ.

To be fair GUI code is going to be harder to read than a non-interactive utility, in any two languages

Actually I agree. I wish Rust kept the basic C syntax for function etc. I really hate def, fn, and other such keywords.

It’s been ten years since Rust 1.0, if that were to happen, we’d be seeing it now. But we don’t.

C's been around for over 50 years. Yes, I would hope that something does replace replace Rust after 50 years.

> Memory safety is mostly an issue of the past.

Can you provide some evidence to support this? There’s a large body of evidence to the contrary, e.g. from Chrome[1].

> But we have tools to prevent that. The new security issues are supply chain attacks.

Speaking as a “supply chain security” person, this doesn’t really hold water. Supply chain attacks include the risk of memory unsafety lurking in complex dependency trees; it’s not an either-or.

[1]: https://www.chromium.org/Home/chromium-security/memory-safet...

What part of C package management defends against supply chain attacks?

Does it audit third-party code for you?

As GvR famously reminded everyone in 2011, a language and its packaging system are separate things.

But Rust, you know, has one.

> If coding is careful and the code is review - there is no technical debt, or perhaps I should say no more than the unsafe parts of a rust codebase or the standard libraries. And the safety of critical infra code written in C gets _better_ over time, as such technical debt is repaid.

How many decades have we tried this? How many more to see that it just hasn't panned out like you describe?

> If coding is careful and the code is review - there is no technical debt, or perhaps I should say no more than the unsafe parts of a rust codebase or the standard libraries.

History shows again and again that this statement is impossible..

Name a large C application that’s widely used, and I’ll show you at least one CVE that’s caused by a memory leak from the project

While I get your view, I think examples would help to move the conversation along in a more constructive manner

> it's factually just better, am I right?

so cool to see people getting it!

There is a pure-Rust compiler backend in the works, but that's going to take a long time to mature so it's just pragmatic to use LLVM in the meantime. Especially since the exploitation potential is pretty contrived in this case - if you compile compromised code then you're probably owned anyway, regardless of the backends memory safety.

What is the concern with LLVM? I'm asking because I genuinely don't know.

> There is no standard. It's accidentally designed.

Are you really claiming that you can't design a language without an official standard? Not to mention that C itself has been designed long before its first ISO standard. Finally, the idea that a standard committee is a preconditionfor good language design is rather bold, I have to say. The phrase "design by committee" isn't typically used as a compliment...

> You've solved one class of bugs outside of "unsafe {}".

It's "only" the single most important class of bugs for system safety.

This kind of deflection and denialism isn't helping. And I'm saying this as someone who really likes C++.

I find Rust much easier to write than C. Its types let me be reasonably sure I’ve written appropriate code before I even get to the point of running tests, and I don’t have to memorize the flow of the whole program to have that assurance.

For instance,

  struct Feet(i32);
  struct Meters(i32);
  
  fn hover(altitude: Meters) {
      println!("At {} meters", altitude.0);
  }
  
  fn main() {
      let altitude1 = Meters(16);
      hover(altitude1);
      let altitude2 = Feet(16);
      hover(altitude2);
  }

   12 |     hover(altitude2);
      |     ----- ^^^^^^^^^ expected `Meters`, found `Feet`
      |     |
      |     arguments to this function are incorrect

That’s one example. It’s not unique to Rust by a long shot. But it’s still a vast improvement over C, where that same signed 32 bit data type is the number of eggs in a basket, the offset of bytes into a struct, the index of an array, a UTF-8 code point, or whatever else.

This really shows up at refactoring time. Move some Rust code around and it’ll loudly let you know exactly what you need to fix before it’s ready. C? Not so much.

> Especially coming from the world of memory managed languages.

If people from that world complain about Rust, I surely wouldn't want them around a C codebase.

There's nothing wrong about memory-managed languages, if you don't need to care about memory. But being unfamiliar with memory and complaining about the thing that help you avoid shooting your foot isn't something that inspires trust.

The hardship associated with learning rust isn't going to go away if they do C instead. What's going to happen instead is that bugged code will be written, and they will learn to associate the hardship with the underlying problem: managing memory.

> It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried

I think this is more true of C than it is of Rust if the bar is "code of sufficient quality to be included in debian"

Anyone capable of programming and willing to invest enough time will be able to learn Rust, in my opinion.

It might take some people months rather than days, but I think that is a desirable outcome.

Important low level software should be written by competent developers willing to invest the effort.

> It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried.

That could also be applied to C and C++ …

Assuming you're right about the language being too hard for most people, the outcome I'd expect given the history of computing is that the language will fail or be stuck in a niche

Time and time again, theoretically worse solutions that are easily accessible win

Debian just cut i386, Wikipedia says the i386 was discontinued in 2007. These systems are all of the same vintage, so it does not seem a huge leap to be culled from the support list.

[0] https://en.wikipedia.org/wiki/I386

> Who is still using these machines? Genuine question, not trolling.

Either legacy systems (which are most certainly not running the current bleeding-edge Debian) or retro computing enthusiast.

These platforms are long obsolete and there are no practical reasons to run them besides "I have a box in the corner that's running untouched for the last 20 years" and "for fun". I can get a more powerful and power efficient computer (than any of these systems) from my local e-waste recycling facility for free.

It’s usually a loud minority of trolls or hobbyists. It just takes one to spark a doubt.

Here is one famous example of a dude who’s managed to get PRs merged in dozens of packages, just to make them compatible with ancient versions of nodejs https://news.ycombinator.com/item?id=44831811

There’s hobbyists using m68k Macs, Amigas, and Atari STs. Definitely a small niche, and those running Linux on those machines more so.

> Who is still using these machines? Genuine question, not trolling.

Well, there are so many things were you could argue about the relevance of a userbase.

If the size of a userbase would be the only argument, Valve could just drop support for the Linux userbase which is just 2-3% of their overall userbase.

Think about any time a computer is used in something designed to last 30+ years.

Cars, airplanes, construction equipment, etc.

people enjoy running vintage stuff, and running modern stuff on some vintage thing is kinda cool.

But yeah, those can figure out how to keep their own port

They’re not going to fall to the wayside, we’re eventually getting Rust support on these.

It’s just a bit annoying that Rust proponents are being so pushy in some cases as if Rust was the solution to everything.

I was running Debian unstable on my 64-bit SPARC up until I moved a few months ago and haven't set the system back up again while unpacking.

It's been somewhat useful for finding weird edge cases in software where for whatever reason, it doesn't reproduce easily on AArch64 or x86, but does there. (Or vice-versa, sometimes.)

I don't know that I'd say that's sufficient reason to motivate dozens of people to maintain support, but it's not purely academic entertainment or nostalgia, for that.

Shouldn't the codegen_gcc project[1] theoretically allow Rust to target backends that only GCC supports?

[1] https://github.com/rust-lang/rustc_codegen_gcc

As far as I understand it, the m68k LLVM port is not ABI-compatible with GCC on Linux because the alignment is wrong: https://wiki.debian.org/M68k/Alignment (page says that the LLVM packages are FTBFS because of this)

While that seems like it would be true, is that really relevant to Debian? :)

more relevant they are all "unofficial" supported architectures and non in a "might get official support" context, so they all have been of very limited interest of Debian as a whole for quite a while

Most don't need to be rebranded. Alpha and hppa are retro computing and haven't been available to buy for 18 and 15 years respectively. Sh4 died this year. Only m68k is still holding on, but is a rounding error in the number is users.

I don’t think the language is unprofessional, it’s direct and it states his opinion.

The one demanding it is the maintainer of keepassxc it would’ve been better to just close the issue that this is a Debian only problem and he should install it like that and just close it.

Browser integration is a completely basic feature I expect from any password manager. It is absolutely useless for most people without it.

In fact not having it encourages copy and paste which reduces security.

Whats next? Strip javascript support from browsers to reduce the attack surface?

I don't get how this is even a discussion. Either he is paid by canonical to be a corporate saboteur or he is completely insane.

mainly people have issues with clear, precise and concise language about intend of action instead of idk. a request of discussion

now this is separate from being open for discussion if someone has some good arguments (which aren't "you break something which isn't supported and only nich used") and some claim he isn't open for arguments

and tbh. if someone exposes users to actual relevant security risk(1) because the change adds a bit of in depth security(2) and then implicitly denounces them for "wanting crap" this raises a lot of red flags IMHO.

(1): Copy pasting passwords is a very bad idea, the problem is phsishing attacks with "look alike" domains. You password manager won't fill them out, your copy past is prone to falling for it. In addition there are other smaller issues related to clip board safety and similar (hence why KC clears the clipboard after a short time).

(2): Removing unneeded functionality which could have vulnerabilities. Except we speak about code from the same source which if not enabled/setup does pretty much nothing (It might still pull in some dependencies, tho.)

but yes very unnecessary drama

The level of knee-jerk reaction to anything Rust into traditionally C projects borders on the pathological. That email is about as polite as it gets without being coddling.

> Removing features is not the most secure option possible.

If I have a program that encrypts and decrypts passwords, then the surface area is way smaller than if it also has browser integrations and a bunch of other features. Every feature has the potential to make this list longer: https://keepass.info/help/kb/sec_issues.html which applies to any other piece of software.

At the same time, people can make the argument that software that's secure but has no useful features also isn't very worthwhile. From that whole discussion, the idea of having a minimal package and a full package makes a lot of sense - I'd use the minimal version because I don't use that additional functionality, but someone else might benefit a bunch from the full version.

Some people don't have actual understanding of the meaning of security.

Security is there to keep the features usable without interruptions or risks.

E.g. plugging the computer off the network is not about security if the service needs to be accessible.

It’s called openBSD :) (don’t get me wrong, openBSD is awesome, but the default install which is secure out of the box is a bit spartan heheh)

Just annoys me that he calls features "crap" just because he likely doesn't use them personally and ends that post with a random sentence claiming such a version "increases the risk of drive-by attacks" with zero evidence. The developer explains the features aren't plugins and aren't even enabled by default. Arrogance from maintainers like this from within Debian is what will hurt it far more than any external entity.

You misunderstand, see; these people are corporate saboteurs.

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.

There are like 1000 Debian maintainers, right? This person doesn't speak for the project as a whole, and as far as I can tell he is telling Debian folks they will be accepting rust whether they want it or not, and whether their preferred architecture is supported or not. Maybe there was some organizational vote on this, but if so it isn't referenced in the thread. It says "I plan", not "Debian decided to".

And regardless, my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.

Exactly! People love ripgrep because of its clear advantages, and had the developers been interested in making posix mode for it, I'm certain at least some distros would have made it the default by now.

Applications vs Infrastructure: When stand-alone applications are in completely different languages, that is normal and reasonable and fine. When it takes 5-10 different programming languages just to build and manage the base system, that is an engineering failure and a mess.

Yeah I get point for attracting young blood. But I wonder if the core utils which have been rewritten got rewritten by the original maintainers? And again the question why not simply write something new. With a modern architecture etc rather than drop in replacements.

On your second part. I wonder how aviation and space and car industry do it. They rely heavily on tested / proven concepts. What do they do when introducing a new type of material to replace another one. Or when a complete assembly workflow gets updated.

Inviting inexperienced amateurs to wide-reaching projects does not seem to be a prudent recipe. Nay, it is a recipe for disaster.

So a change to the worse.

The GPL protects the freedom of the users while MIT-licensed software can be easily rug-pulled or be co-opted by the big tech monopolists.

Using GitHub is unacceptable as it is banning many countries from using it. You are excluding devs around the world from contributing. Plus it is owned by Microsoft.

So we replaced a strong copyleft license and a solid decentralized workflow with a centralized repo that depends on the whims of Microsoft and the US government and that is somehow a good thing?

2 GNU coreutils maintainers, including myself, monitor the issues and PRs on a GitHub mirror that we have [1]. Generally the mailing list is preferred though, since more people follow it.

[1] https://github.com/coreutils/coreutils

changed the wording a little, thanks

Based on this, and many other similar threads, it's the anti-Rust zealots insulting Rust users.

They have the backing to doing the right thing, because their language is memory safe and this everytime means absolutely secure. Irony off.

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?

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.

Let me assure you it was my own decision. The final paragraph is my paraphrasing of a fellow Debian developer and CTTE member's stated opinion.

What do people find objectionable about the above comment? I'm genuinely at a loss.

No, it’s a valid question, and one that I’m sure will get some answers in the coming days and weeks as the discussion on adding this requirement continues, but in some sense, it’s beside the point.

The cost of supporting this old hardware for businesses or hobbyists isn’t free. The parties that feel strongly that new software continue to be released supporting a particular platform have options here, ranging from getting support for those architectures in LLVM and Rust, pushing GCC frontends for rust forward, maintaining their own fork of apt, etc.

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 wherever. Especially so since software licenses didn't really exist in those days in developing countries - even government institutions often ran pirated software without a second thought.

Those businesses usually have very purpose-built machines. Like USG machines running windows xp in hospitals. You normally don't touch them, just isolate. You definitely don't update them to the latest OS version.

These architectures were for were high end machines at the time, universities and government agencies would indeed been the only ones buying these, and they probably migrated to commodity hardware long ago; if migrating to a PC-compatible architecture had been off the table for them, so had been keeping these things running after their EOL.

(In my second-tier university at my developing country, the Sun workstation hadn’t been turned on in years by the late 2000s, and the the minicomputer they bought in the 1980s was furniture at the school)

Edit: As for big businesses, they have support plans from IBM or HP for their mainframes, nothing relevant to Debian.

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.

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

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

We're really talking about alpha, hppa, m68k and sh4

> I think the spin that Rust is necessarily the way forward is what is wrong.

I haven't seen this from Rust. Obviously lots of us think that Rust is the way forward for us but I think the problem you're talking about is that nobody offered any alternatives you liked better and that's not on Rust.

If Bob is ordering pizza for everybody who wants one, it is not the case that "Pizza is necessarily the way forward", and it's not Bob's fault that you can't have sliders, I think if you want sliders you're going to need to order them yourself and "Pizza is the way forward" is merely the default when you don't and people are hungry.

Dave Abraham's Hylo is an example of somebody offering to order sushi in this analogy. It's not yet clear whether Dave knows a Sushi place that delivers here, or how much Sushi would be but that's what having another way forward could look like.

In C++ they've got profiles, which is, generously, "Concepts of a plan" for a way forward and in C... I mean, it's not your focus, but nobody is looking at this right? Maybe Fil-C is your future? I note that Fil-C doesn't work on these obsolete targets either.

This whole it used to be different thing is looking back with rose tinted glasses. It’s always been the case that project maintainers were able to make choices that the community didn’t necessarily agree with, corporate backed contributors or not, and it’s still a possibility to fork and try to prove out that the other stance is better.

Nobody is being forced out of the community, you can fork and not adopt the changes if you want. Thats the real point of free software, that you have the freedom to make that choice. The whole point of free software was never that the direction of the software should be free from corporate control in some way, the maintainers of a project have always had the authority to make decisions about their own project, whether individual or corporate or a mix.

> if you wanted something changed and there was no agreement, you created a fork and if it was truly better it was eventually adopted by the majority.

This assumes there wasn't agreement.

And if so, what would 'eventually adopted by the majority' mean. Is this announcement not that?

> The whole point of free software should be that I do not have to adapt to some companies's idea of what is modern, if I do not want to.

This hasn’t changed.

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

> IMHO Rust has severe problems and what is considered "modern" is mostly taste.

Really? As opposed to e.g. C or C++ (as the most important languages which Rust is competing with)? Sure, taste plays into everything, but I think a lot of people work with Rust since it's genuinely a better tool.

I hear you on free software being controlled by corporate interests, but that's imo a separate discussion from how good Rust is as a language.

Name me another language that offers the memory safety and deterministic runtime guarantees that Rust does, eliminating entire classes of bugs, the same integration with existing C code that Rust does, and enjoys the same community and pool of eager contributors that Rust does.

I'll wait.

For me it actually is the language. While a little pushy at times I think the arguments for rewriting certain things in a safer language is well founded. If the apt tool chains is one of those places I'll leave for the Debian developers to determine, but for decompression tools I can see a benefit.

If Rust should be the language of choice, preferably not. The syntax is awful, the language is complicated and Rust programs seems to collect dependencies at the same rate as JavaScript. Where I might agree with you is that Rust seems to attract a certain type of people. They write absolutely brilliant software, but like the Rust compile, they are rather particular with what input they'll accept.

In the end I don't really care what apt is written in, I'm not the one writing the code. I just use the tool. It would be sad if some platforms are left behind, because the Rust developers don't care about them and not because they're no longer useful.

Ironically, the people hating on it (and usually without any technical arguments) act way more cultish.

At least it looks that way to my not-rust-using self

Tell me you haven't used Rust without telling me you haven't used Rust.

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

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 if you need the language or ecosystem to move in some direction will hail from. In turn, the community will naturally get to impose its own values and aesthetic preferences onto you, whether by proactively using the position of relative power they have over you, or simply by osmosis. As it happens, the community surrounding Rust does largely consist of American progressives, which should not be surprising - after all, the language was created by an American company whose staff famously threatened mutiny when its own CEO turned out to offend progressive sensibilities.

As such, it is natural that bringing Rust into your project would over time result in it becoming more "woke", just like using Ruby would make it more likely that you attract Japanese contributors, or targeting Baikal CPUs would result in you getting pulled into the Russian orbit. The "woke" side themselves recognises this effect quite well, which is why they were so disturbed when Framework pushed Omarchy as a Linux distribution.

Of course, one needs to ask whether it is fair to insinuate premeditation by calling a mere expected effect an "agenda". Considering the endlessly navel-gazing nature of the culture wars, I would find it surprising if there weren't at least some people out there who make the same observation as above, and do think along the lines that driving Rust adoption is [also] a good thing because of it. Thus, Rust adoption does become, in a sense, part of the "woke agenda", just as Rust rejection becomes, perhaps even more clearly so, part of the "chud agenda".

Reading loaded adjectives for programming languages is waste of time. I would skip that kind of social media.

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.

Please, don't use loaded, provocative, and most importantly, irrelevant terms in these discussions. It helps nothing and serves nobody.

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

Rust is already pretty successful adoption wise. It’s powering significant parts of the internet, it’s been introduced in 3 major operating systems (Windows, Linux, Android), many successful companies in a variety of domains have written their entire tech stack in it. Adoption as measured by crates.io downloads has doubled every year for the last 10 years.

Now I’m imagining how much more widely Rust would be used if they had adopted your visionary approach of never saying anything positive about it.

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.

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

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.

The unfortunate reality is that you must write almost all of your drivers from scratch if you want to rust in embedded. There is no OEM driver support, and as you said the open source drivers are all crap and written for arduino-level hobby projects.

Lack of drivers is prohibitive if your are a small/medium team or are using a lot of complicated peripherals or SoC. Compare to C where any MCU or embedded SoC or moderately complex peripheral normally comes with C driver code.

Well, at Microsoft, plenty of people have thought about and discussed C#, with some products/features using it. Not that it's gone away, but it has not won the hearts and minds of the general (software-developing) public.

You can absolutely use rustc without Cargo and there's frankly plenty of arguments for doing so in the context of embedded.

> a cultural basis of "there are people who want this so and it changes things therefore it is bad". But never on the merits.

In this mindset, arguing against change is an argument on the merits. Because everything you spend time on has the opportunity cost of everything else you could spend time on.

> This is entirely the wrong lens.

Telling people they need to take their ball and go home if they're incapable or unable to maintain an entire compiler back-end seems like a, shall we say, 'interesting' lens for a major distro such as Debian.

Just to parse some files?

> since it only supports amd64

Sorry to double-reply, but this is actually a super important point in favor of Fil-C.

If you adopted Fil-C for apt, then you could adopt it optionally - only on ports that had a Fil-C compiler. Your apt code would work just as well in Fil-C as in Yolo-C. It's not hard to do that. I think about half the software I "ported" to Fil-C worked out of the box, and in those cases where I had to make changes, they're the sort of changes you could upstream and maintain the software for both Fil-C and Yolo-C.

So, with Fil-C, there would be no need to ruffle feathers by telling port maintainers to support a new toolchain!

> since it only supports amd64 at this time and is maintained by a single genius.

That's easily fixable.

> It also doesn't help you to attract new contributors.

I don't understand this point.

Right. I do have some nostalgia for installing Linux on a brand new PC which had less total RAM than my computer today has cache, but we need to be clear eyed about what makes sense for a maintained piece of software. I also have feelings about steam trains, but burning coal is not a sensible way to power a train in 2025.

A nostalgia-fuelled Linux distro, maybe using a deliberately slimmed down or retro kernel, and chosen software could make a lot more sense than keep trying to squeeze Debian onto hardware that was already obsolete at the turn of the century while also promoting Debian as a viable choice for a brand new laptop.

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.

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"

And if it is it absolutely is indicative of their opinion and absolutely deserved.

I meant, that email literally ask the fellow developer to either finish the Rust port or sunset the debian port in 6 months.

I am asking if the former option is a practical one

> The instability of Rust would not affect users in any way.

Sure it would. Suppose a rust-based package has a security bug. Upstream has fixed it, but that fix depends on some new rust language feature that the frozen version of rust in Debian doesn't have yet.

If you're designing an OS distribution, you would have your base system written adhering strictly to language standards and without relying on flakey extensions (not that GCC C extensions are flakey, I'm guessing most/all of them are stable since the 1990s), and minimizing reliance on additional tools.

For example, IIUC, you can build a perl interpreter using a C compiler and GNU Make. And if you can't - GCC is quite bootstrappable; see here for the x86 / x86_64 procedure:

https://stackoverflow.com/a/65708958/1593077

and you can get into that on other platforms anywhere along the bootstrapping chain. And then you can again easily build perl; see:

https://codereflections.com/2023/12/24/bootstrapping-perl-wi...

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.

Motivated people seem to prefer rewriting using a 13 years old programming language. Crazy.

TBH most “false positives” that I investigate are wishful thinking or the result of ignorance of what is really happening. It looks like you are using Debian. That probably doesn’t help. Here is a typical Debian “bug” report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802778

10 years old. It never was a false positive. It was fixed a good few years ago. The fix did not involve suppressing the error.

Valgrind does need a lot of work, especially for missing CPU features and for Darwin. I’m not aware of many memcheck bugs that aren’t relatively obscure corner cases.

If you have encountered bugs please report them to https://bugs.kde.org.

I'm pretty sure many other companies are going to use it in production before mine does. I'll just ask around...

It's rather that GnuPG is ill-regarded for its code immaturity tbh. You don't even need to read the code base, just try to use it in a script:

It exits 0 when the verification failed, it exits 1 when it passed, and you have to ignore it all and parse the output of the status fd to find the truth.

It provides options to enforce various algorithmic constraints but they only work in some modes and are silently ignored in others.

GnuPG has protected Snowden and he speaks positively of it.

Does Sequoia-PGP have similar credentials and who funds it?

For C, once I learned that types are best read right-to-left, they became much more scrutable.

        int[] foo
        |   |  |
        |   |  foo 
        |   is an array  
        of ints

I find it surprising hearing statements like this from a developer of a tool for, well, C programmers mostly I guess? "Skill is all that is needed to prevent bugs and produce bug-free software" is a phrase I've never heard from an actual C programmer, but have heard plenty of times from detractors.

The C programmers I know are certainly not deluded or overconfident. They don't even think "their" language is a perfect one, or even a very good one. They just avoid black-and-white thinking. They take a practical approach about memory issues, seeing them more like any other kind of bug. It's a different aesthetics than you would maybe see from many Rust folks. They want to be productive and want to be in control and want to understand what their code does. In turn, they accept that in some cases, bugs (possibly memory bugs) creep in, some of which could go unnoticed for some time. They tend to not see that as a huge issue, at least in general, because an issue that has gone unnoticed (or didn't manifest) is often less of a problem than one that is immediately obvious. (In case of data corruption, it _can_ be a huge issue, and you have to add safeguards to prevent it, and have to be accepting some residual risk).

They understand that everything is a trade off and that with experience and practice, good architecture, good tooling etc. you can prevent many bugs early, and detect them early. They have tried many approaches to prevent bugs, including fancy languages and constructs, and have concluded that in many cases, perfect safety is not possible, in particular it's not possible without seriously hurting other requirements, such as productivity.

As to valgrind, I can say that it was a bit of a mixed bag for me. It did help me finding bugs a number of times, but I also had to configure it a bit because it was producing a lot of noise for some external libraries (such as libc). I don't really understand the underlying issues.

Their spec just happens to describe whatever the compiler decided to implement, it's not a source of truth.

Considering the number of provers and statistical analysers and given C is the only mainstream language with a formally verified compiler, I would say fairly well thank you.

Honestly, I am not even opposed to Rust. It has cool ideas. I do think it should care a lot more about being portable and properly defined and should have done so a lot earlier and I do deeply disagree with the opinion of some core team members that specification is meaningless.

C obviously always was a questionable choice for a tool like apt but Rust seems even worse to me. Apt has absolutely no need to be written in a low level language. At least you could argue that C was chosen because it’s portable but I don’t see what Rust has going for it.

The only spec you need meet to get Perl or Python running on a new platform is the C spec. A compiler meeting that spec is enough to port and compile the interpreter for a new platform.

RISC-V is well on its way to be a challenger to both, with (eventually) full support for Rust.

Don't feed egregious comments by replying; flag them instead. If you flag, please don't also comment that you did.

https://news.ycombinator.com/newsguidelines.html

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 implementation-defined hidden complexities.

[flagged]

Ubuntu is built on top of Debian

Yes, but we're not making a push to make everything a bilingual c/lisp code base.

Rust people for some reason are.

I have similar feelings about the go community. I like go on the whole, but certain aspects are atrocious. The 'go community' is strangely cult-like and complaining about the language is generally poorly received. As a result I very rarely interact with them and just do my own thing.

If the value proposition is internet drama, then it certainly does.

Rust isn't 'delivering value', people are just drinking the koolaid. CL has its niches, and it still fills them well: it's never been that successful as a general-purpose language.

As a GC language Common Lisp is slow as molasses. However, in the realm of languages which are slow as molasses it's got quite acceptable performance. I suppose it's in part because it's alien technology from beyond the bounds of the multiverse, but also in part due to the fact that we had really interesting tech back in the '70s and '80s that kinda got lost during the so-called AI winter.

To add on to that, with declarations the programmer can tell the Lisp compiler that (for example) a variable can be stack allocated to help improve performance. The fact that Lisp code is just data is another benefit towards performance as it means macros are relatively easy to write so some computation can be done at compile time. There are also various useful utilities in the spec which can be used to help profile execution of a program to aid in optimization, such as time and trace.

Well, so far this thread has 0 people shilling Rust, a couple shilling Common Lisp and a bunch complaining about Rust shills (you included).

Makes you think, huh?