But the people who use the language have an amazing talent to make people on the fence hate them within half a dozen sentences.

They remind me of Christian missionaries trying to convert the savages from their barbarous religions with human sacrifice to the civilised religion with burning heretics.

What would really be scary would be a distro that won't even boot unless a variety of LLM's are installed.

Boo!

I struggle to believe that this is really about a call to improve quality when there seem to be some other huge juicy targets.

That doesn’t change that both rustc and programs that use rust have been packaged for a very, very long time.

Citation needed.

Or, what can be asserted without evidence can be dismissed by pointing to ripgrep.

Back to my original point - I don't think Rust is going to fix this.

As for preventing XSS and SQL injections, that's what good web frameworks do. If your framework encourages you to write raw unescaped SQL, or doesn't provide sensible defaults around content policies, then no matter what language it's in, there are going to be issues (and maybe if we called these frameworks "unsafe" then we'd get somewhere with fixing them).

My feeling is in the specific instance of using rust in apt, this is most likely a good thing (though I hope existing well tested rust libraries are used rather than NIHing them and introducing new bugs), but so far Ubuntu's rustification has not gone smoothly, so I'm more wary of the changes that e.g. improvements to Firefox via rust.

Use Rust for evergreen projects by all means, just leave mature tested systems alone, please.

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

Because that saves a lot of headaches down the line.

By Sequoia, are they talking about replacing GnuPG with https://sequoia-pgp.org/ for signature verification?

I really hope they don't replace the audited and battle-tested GnuPG parts with some new-fangled project like that just because it is written in "memory-safe" rust.

Loved this statement on the state of modern software using the backbone of C (in linux and elsewhere)

  > Be careful.  Rust does not support some platforms well.[0]  ANything
  > that is not Tier 1 is not guaranteed to actually work.  And
  > architectures like m68k and powerpc are Tier 3.
  > 
  > [0] <https://doc.rust-lang.org/beta/rustc/platform-support.html>.

[ The rustic book > Target Tier Policy: https://doc.rust-lang.org/beta/rustc/target-tier-policy.html... ]

  Thank you for your message.

  Rust is already a hard requirement on all Debian release
  architectures and ports except for alpha, hppa, m68k, and
  sh4 (which do not provide sqv).

- 2.5pro: "Rust Compiler Target Porting Plan" https://gemini.google.com/share/b36065507d9d :

> [ rustc_codegen_gcc, libcore atomics for each target (m68k does not have support for 64-bit atomics and will need patching to libgcc helper functions), ..., libc, liballoc and libstd (fix std::thread, std::fs, std::net, std::sync), and then compiletest will find thousands of bugs ]

So, CI build hours on those actual but first emulated ISAs?

"Google porting all internal workloads to ARM, with help from GenAI" (2025) https://news.ycombinator.com/item?id=45691519

"AI-Driven Software Porting to RISC-V" (2025) https://news.ycombinator.com/item?id=45315314

"The Unreasonable Effectiveness of Fuzzing for Porting Programs" (2025) https://news.ycombinator.com/item?id=44311241 :

> A simple strategy of having LLMs write fuzz tests and build up a port in topological order seems effective at automating porting from C to Rust.

It's quite surprising and it takes days to weeks to debug each of these, going down to the assembler level and verifying that by hand.

Do you think that it was made up from whole cloth in the abstract machine and implemented later? No, it was based on the available implementations of its time.

On top of that, languages like Python do not have a specification and yet have multiple implementations.

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 virtues of standardization don’t seem compatible with accepting that.

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.

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"

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.

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

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

The GCCRS project can't even build libcore right now, let alone libstd. In addition, it is currently targeting Rust 1.50's feature set, with some additions that the Linux kernel needs. I don't see it being a useful general purpose compiler for years.

What's more likely is that rustc_codegen_gcc, which I believe can currently build libcore and libstd, will be stabilised first.

The rustc version will be fixed for compaibility at every release and all rust dependencies must be ported to apts.

In the debian context, the burden imposed by rust churn and "cargo hell" falls on debian package maintainers.

First, Debian is not a distro where users have to compile their software. The packages contain binaries, the compilation is already done. The instability of Rust would not affect users in any way.

And second, as a developer, I never had a more unpleasant language to work with than Rust. The borrow checker back then was abysmal. Rust is not about developer happiness - Ruby is - but its memory safety makes it a useful option in specific situation. But you can be sure that many developers will avoid it like a plague - and together with the breakage and long compile times that's probably why moves like the one dictated here are so controversial.

From experience with this type of code you typically end up with a load of functions that take in a numpy array and its length/dimensions to a C function that works on that array in place or an output array that was also supplied. In terms of getting this wrong, it’s usually a crash caused by out of bounds memory access which would still be a runtime crash in Rust. So I’m not sure there’s a massive benefit for these types of code other than the fun of learning Rust. Other than that, you’re typically writing C/C++ to interface with C and Fortran libraries that are really battle tested, and for which it will take decades for Rust to have equivalents. So moving to Rust will just cause you to have lots of unsafe statements - not a bad thing necessarily if you are doing a lot of work at the C level in existing code but less of a benefit if you are doing a straight wrap of a library.

On the flip side, things on the web side of Python like uWSGI which is written in C are important for the security aspect but they’re a very small part of the Python ecosystem.

The easiest way to see this is in US locales, which use 12-hour clocks in GNU 'date' but not other implementations:

  $ date -d '13:00'
  Sat Nov  1 01:00:00 PM PDT 2025
  $ uu_date -d '13:00'
  Sat Nov  1 13:00:00 2025

[1] https://github.com/coreutils/coreutils/commit/1066d442c2c023...

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.

apt is so late in the process that these bootstrapping discussions aren’t quite so relevant. My point was that at the same layer of the OS, there are many, many components that don't meet the same criteria posted, including perl.

Please don't make up wrong facts that would be trivial to check first.

All minimal Debian installations include bash as it is an essential package. Where essential is used in the sense of https://www.debian.org/doc/debian-policy/ch-binary.html#esse...

For clarity, 'sh' is what is softlinked to dash. Not bash.

But even so - what price correct & secure software? We all lost a tonne of performance overnight when we applied the first Meltdown and Spectre workarounds. This doesn't seem much different.

In all seriousness though, let me assure you that I plan to take a very considerate approach to Rust in APT. A significant benefit of doing Rust in APT rather than rewriting APT from scratch in Rust means that we can avoid redoing all our past mistakes because we can look at our own code and translate it directly.

(not relevant to Debian, but cool that it's already possible)

yes, from a pure code generation aspect

no, as all conditional-compiled platform specific code is missing.

So using it with #[no_core] should work (assuming the WIP part of the backend isn't a problem). But beyond that you have to first port libcore (should be doable) and then libstd (quite a bunch of work).

We should really hold more value to keeping existing user setups working. Breakages are incredibly damaging and might very well have a bigger impact than insecure defaults.

"All of these features are superfluous and do not really belong in a local password database manager" seems to me like a pretty clear explanation of what is "crap" about them, and it seems pretty clearly not to be about personal taste.

Some people care about modularity.

How many type confusion 0 days and memory safety issues have we had in dynamic language engines again? I've really lost count.

The average C project has at most a handful of other C dependencies. The average Rust, Go or NodeJS project? A couple hundred.

Ironically, because dependency management is so easy in modern languages, people started adding a lot of dependencies everywhere. Need a leftpad? Just add one line in some yaml file or an "Alt-Enter" in an IDE. Done.

In C? That is a lot more work. If you do that, you do it for advanced for stuff you absolutely need for your project. Because it is not easy. In all likelihood you write that stuff yourself.

Java can potentially have the same problem. But because everyone uses an IDE and because it's rarely really an issue, everyone will simply import `Baz` rather than worry about the Foo::Baz and Bat::Baz collision. It does happen in java code, but I can't stress how infrequently it's actually a problem.

Solved problem:

United States Patent Application 3127321 Date of Patent March 31, 1964 NUCLEAR REACTOR FOR A RAILWAY VEHICLE

We'll have to see how this plays out but it's not super plug and play.

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 in the form of transitive dependencies; complex software just tends to include external dependencies rather than reinventing the wheel.

Another likely thing is understanding that the unit of "package" is different in Rust/Cargo than traditionally in C and Debian, so 130 crates aren't as much code as 130 Debian packages would have been.

The same amount of code, from the same number of authors, will end up split into more smaller packages (crates) in Rust. Where a C project would split itself into components internally in a way that's invisible outside (multiple `.h` files, in subdirectories or sub-makefiles), Rust/Cargo projects split themselves into crates (in a Cargo workspace and/or a monorepo), which happen to be visible externally as equal to a package. These typically aren't full-size dependencies, just a separate compilation unit. It's like cutting a pizza into 4 or 16 slices. You get more slices, but that doesn't make the pizza bigger.

From security perspective, I've found that splitting large projects into smaller packages actually helps review the code. Each sub-package is more focused on one goal, with a smaller public API, so it's easier to see if it's doing what it claims to than if it was a part of a monolith with a larger internal API and more state.

(*) random number

You don't want the core cryptography implemented in Rust for Rust's sake when there's a formally verified Assembler version next to it. Formally verified _always_ beats anything else.

(New cryptographic software can also be developed by all sorts of people. In this case I'm not familiar, but we do know that GnuPG worked for the highest profile case imaginable.)

For other architectures currently unsupported by Rust, I doubt it'll happen. The CPU architectures themselves are long dead and often only used for industrial applications, so the probability of hobbyists getting their hands on them is pretty slim.

People still using these old architectures for anything but enthusiast hacking will probably not be using Debian Trixie, and if they do, they can probably find a workaround. It's not like the .deb format itself is changing, so old versions of apt and dpkg will keep working for quite a while.

I do think it’s down to personal preference. With the fully qualified names, I can look at the screen and follow the flow without having to mouse over the various names in play. For that matter, I could print it out if I wanted to and still have all the information.

I don’t think you’re objectively wrong. It’s more that we have different approaches to managing the complexity when it gets hairy.

We could now pretend their position is: "Oh, we got this shiny new language that magically makes everything 100% safe and thus we need to rewrite everything." But that is not the position. Most of them are aware that a rewrite is always a trade-off. You could reintroduce old bugs etc.

As I said, I program languages on both sides on the divide and if I had to write and maintain secure software that my life depended on I would certainly prefer to write it in Rust. Memory safety would be just a tiny part of that. The other factors would be the strict type system (can be used to enforce certain guarantees that contributers cannot easily fuck up) and the tooling (the builtin testing is stellar).

The future of tooling is going to be written in the language people of the coming generations like to write. There was a time when C++ or even C was the new shiny thing. Why can't we just write all software in assembly like in the good old days? Because there were some actual tangible benefits to doing it in C and that's the language people with the ability of doing the job chose.

I am not saying a Rust rewrite makes sense in every case, but if you check the past decade of CVEs on a project and half of them would have been prevented by the vanilla Rust compiler maybe that's the rational thing?

It's cool that you can run modern Debian on an Amiga or whatever, but it's not particularly important that that be the case.

No, just that it's not 1968 anymore, and if you want to claim your language has learned lessons from the past, then this is one that clearly got missed.

> The phrase "design by committee" isn't typically used as a compliment...

While the phrase "emergent incompatibilities" is only known as a detriment.

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

Again, I ask for a reference, "according to what?" I understand this is the zeitgeist. Is it actually true? It seems to me this great experiment is actually proving it probably isn't.

> This kind of deflection and denialism isn't helping.

Once again, I asked for proof that the claim was true, you've brought nothing, and instead have projected your shortcomings onto my argument.

> And I'm saying this as someone who really likes C++.

Have you ever pushed for C++ to replace C programs because you assume they would be "better" according to some ill defined and never measured metrics?

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 all the time :D

I think this analysis is basically accurate - there's no conspiracy or even deliberate agenda going on, it's just that the community surrounding Rust happens to have (at the moment, anyway) a relatively high number of American progressives, many of whom are openly interested in imposing American progressive ideological norms in spaces they care about (which is basically what we mean by the term "woke").

I think Rust is a good software tool and I would like to see it be as widely adopted and politically-neutral as C is, and used in all sorts of projects run by all sorts of people with all sorts of other agendas, political or otherwise. Consequently, I would like to see people and projects who do not agree with American progressive norms adopt the language and become active users of it, which will help dilute the amount of Rust users who are progressives. I myself am not an American political progressive and I have lots of issues with the stated politics of many well-known Rust developers.

That is not at all true. If someone were to change the license of a project from MIT to something proprietary, the original will still exist and be just as available to users. No freedom is lost.

There is also another crowd that completely aligns with the US foreign policy and also has the same animosity towards those countrie's citizens (I 've seen considerable amount of examples of these).

For the license part I really don't get the argument how can a coreutils rewrite can get rugpulled this is not a hosted service where minio [1] [2] like situation can happen and there is always the original utils if something like that were to happen.

[1] http://news.ycombinator.com/item?id=45665452 [2] https://news.ycombinator.com/item?id=44136108

This is not intended to bash you or anyone else who’s working on it - I think it’s a cool project (I have in the recent past got an 86duino ZERO to run Gentoo, just to see if an obscure old-ish piece of hardware can be useful with modern Linux on it - and it can). I do understand the reason a project like Debian might not want to have to spend resources even just to make it easier to do though.

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.

Very concrete example, the whole Log4j vulnerability issue was basically just a direct implication of a feature that allowed for arbitrary code execution. Nearly no user of Log4j intentionally used that feature, they were all vulnerable because Log4j had that feature.

The fix to the CVE was effectively to remove the feature. If someone had the foresight to try to reduce Log4j to only the features that ~everyone actually used, and publish a separate Log4j-maximal for the fringe users that intentionally use that feature, it would have prevented what was arguably the worst vulnerability that has ever happened.

In the case this thread is about, no one seems to be deny that there should be a 'minimal' and 'full' versions and that the 'minimal' version is going to be more secure. The entire flame war seems to be over whether its better to take a preexisting package name and have it be a minimal one or the full one.

That is simply a tradeoff between "make preexisting users who don't use ancillary features be as secure as possible by default going forward" or "make preexisting users who do use ancillary features not broken by upgrades".

This is literally the same as helping a relative to make their computer more secure by turning it off. Problem solved I guess?

If you made a mistake by shipping insecure defaults you could fix it e.g. by including a banner to use the minimal version to users that don't use the extra features. But simply rug-pulling everybody for "security" and doubling down by insulting the affected users? I really do not understand people that act like this.

I'm pretty suspicious of demands for communities to hold people accountable, especially when the community in question is a loose group of people who mostly communicate online and are united by their shared use of a specific programming technology; and who probably disagree on all sorts of other issues, including contentious ones.

If some form of speech is illegal in your country it does automatically mean it should be illegal for the whole world or that it is wrong or that the world-wide community should adhere to standards specific to your country. Even if that country is USA.

In other words, nobody should give a flying f about open source developers porn preferences.

Your abhorrent personal opinion of another individual has no place in a technical discussion.

If he was asking for C/C++ contributors, he'd be asking for help maintaining a mature project. That's less fun. It mature, grown-up work for serious people. Those serious people probably already have serious jobs. So, fewer people will show up.

Take BLAKE3 as an example. There's asm for the critical bits, but the structural parts that are going to be read most often are written in rust like the reference impl.

It seems that for reasons I don't understand this idea isn't popular and people really like hand rolling assembly.

And the answer to "why now" is quite simple - Because of the whole Rust in kernel debate, people started scrutinizing the situation.

If APT were a hardcore C++ project surely we'd have like adopted namespaces everywhere by now.

I would say that Pythonistas are quite accustomed to "(other) languages being added" to the Python ecosystem. After all, NumPy relies on Fortran, as well as C.

Asserting that kind of "ownership" over code seems rather distasteful to me. Maybe there would be less acrimony if developers got paid for it somehow.

How is language relevant here? If someone just rewrote it in the same language instead of a different one, do you feel the reaction would be significantly better?

What you're seeing now is developers who are interested in writing a better version of whatever they're already working on, and they're choosing Rust to do it. It's not a group "Rust enthusiasts" ninjas infiltrating projects. It's more and more developers everywhere adopting Rust as a tool to get their job done, not to play language wars.

That's not how open source software development works.

I wasn't asked by Linus whether ipchains should become the default over ipfirewall nor whether iptables should become over ipchains.

I wasn't asked whether GCC should use C++ instead of C as the language to build GCC itself.

I can go on with lots of examples.

Why should APT be different and require the maintainers to fork their own project do introduce changes? Why should an undefined "community" (who is that? apparently not the APT developers...) decide? Does this have to be done for every code change in APT?

Please show me a project where you believe you "effectively require containers" just to run the code, and I will do my best to refute that.

> since we no longer live in a storage constrained world.

I think you do care about the storage use if you're complaining about containers.

And I definitely care, on principle. It adds up.

For reasons I can only assume have to do with poorly configured CI, pip gets downloaded billions of times annually (https://pypistats.org/packages/pip), and I assume those files get unpacked and copied all the time since there would be no good reason to use uv to install pip. That's dozens of petabytes of disk I/O.

The world isn't black or white. Some people write Rust programs with the intent to be drop-in compatible programs of some other program. (And, by the way, that "some other program" might itself be a rewrite of an even older program.)

Yet others, such as myself, write Rust programs that may be similar to older programs (or not at all), but definitely not drop-in compatible programs. For example, ripgrep, xsv, fd, bat, hyperfine and more.

I don't know why you insist on a word in which Rust programs are only drop-in compatible rewrites. Embrace the grey and nuanced complexity of the real world.

There is a ton of new stuff getting written in Rust. But we don't have threads like this on HN when someone announces a new piece of infra written in Rust, only when there's a full or partial rewrite.

Re automotive and other legacy industries, there's heavy process around both safety and security. Performing HARAs and TARAs, assigning threat or safety levels to specific components and functions, deep system analysis, adding redundancy for safety, coding standards like MISRA, etc. You don't get a lot of assurances for "free" based on time-proven code. But in defense there's already a massive push towards memory safe languages to reduce the attack surface.

Because of backwards compatibility. You don’t rewrite Linux from scratch to fix old mistakes, that’s making a new system altogether. And I’m pretty sure there are some people doing just that. But still, there’s value in rewriting the things we have now in a future-proof language, so we have a better but working system until the new one is ready.

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?

They are all various attempts at solving the same fundamental problem, which I broadly referred to as containerization (dependency isolation between applications). I avoided using the term "virtual environment" because I was not referring to venv exclusively.

As teh64 helpfully pointed out in https://news.ycombinator.com/item?id=45784445 some hours ago, 4ish years ago my position on this was a total 360 and I'd have had the same reaction to now-me's proposal.

I’m not in the Debian world, but those do seem to me like the types of systems that could use their own specialized distros rather than being a burden to the mass market ones. It’s not as if you could run a stock configuration of any desktop environment on them anyway.

We didn't talk about your gcc-to-c++ example, but if you read up on it you will know they took the pulse of affected developers, started experimental branches, made presentations, and made sure no architectures were left behind. All of which this Debian developer is failing to do.

Look I don't even disagree with the ultimate result... I don't think Debian needs to indefinitely support every strange port it has built up over the years. The way it's being done, though, doesn't sit right. There are far more mature ways to steer a big ship. Your own examples are showing the way.

I dislike the tone of the evangelism and the anti-C attitude but I'm not anti-rust. I purchased a computer with an oversized amount or RAM in part so I could experiment with rust. But determining how to write, edit and compile small programs, from the ground up, without cargo appears exceedingly difficult, and feels like going against the tide

It stands to reason that the embedded programmer commenting was unable to determine how to avoid using cargo and pulling in unnecessary dependencies. Otherwise he would not have encountered this problem

Once you take out cargo, rusts development environment becomes quite poor.

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.

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

Can't you see how much more thought and care went into this, than is on display in this Debian email (the "if your architecture is not supported in 6 months then your port is dead" email)?

For a language to be memory safe it means there must be no way to mishandle a function or use some object wrong that would result in an "unsafe" operation (for Rust, that means undefined behavior).

That is to say the default is safe, and you are given an escape hatch. While in something like c/c++ the default is unsafe.

I'd also like to add that program correctness is another separate concept from language safety and code safety, since you could be using an unsafe language writing unsafe ub code and still have a correct binary.

EDIT: from a brief search: it doesn't.

No it is not. We have a lot of amazing and rock solid software written in C and C++. Stuff mostly works great.

Sure, things could be better but there is no reason why we need to act right now. This is a long term decisions that doesn't need to be rushed.

> What is left is pretty much only Zig and Rust.

We had Ada long before Rust and it is a pretty amazing language. Turns out security isn't that important for many people and C++ is good enough for many projects apparently.

There is also D, Nim, Odin and so on.

> Garbage collection is a huge dealbreaker

It isn't. We had Lisp Machines in the 80s and automatic garbage collection has vastly improved these days. So I wouldn't rule those out either.

In short, no the ship is not sinking. There are many options to improve things. The problems is once you depend on rust it will be hard to remove so it is better to think things through because rushing to adopt it.

you see, GP did not speak in relative terms, but absolutely: They believe Rust has problems. They did not suggest that problems with programming languages are basically all fungible, that we should sum up all problems, compare different languages, and see which ones come out on top.

Of course most people aren't smart enough for the language so they have to use inferior algol languages like rust.

> Why is the "free time" of the original developer more sacrosanct than the "free time" of the re-implementer?

This has nothing to do with free time. It has to do with the fact that the former actually went through a ton of pain to get the project from its original conception and past bugs & design flaws into its current useful state, and the latter is merely translating the solution right in front of them. And not only is the latter going to deprive the former of the ability to even say "this is my project" (despite them having spent years or decades on its design etc.), but they're also probably going to be able to take the whole thing in a different direction, effectively leaving the original author behind.

Whether you feel this is a good or a bad thing for society aside, it should be obvious why this could be genuinely upsetting in some situations.

I’m actually the person who added the m68k target to the Rust compiler and was also one of the driving forces of getting the backend into LLVM.

Generally speaking, getting a new backend into the Rust compiler is not trivial as it depends on LLVM support at the moment which is why asking someone to just do it is a bit arrogant.

Luckily, both rustc_codegen_gcc and gccrs are being worked on, so this problem will be resolved in the future.

``` #include <stdio.h>

typedef struct { int value; } Feet;

typedef struct { int value; } Meters;

void hover(Meters altitude) { printf("At %i meters\n", altitude.value); }

int main() { Meters altitude1 = {.value = 16}; hover(altitude1); Feet altitude2 = {.value = 16}; hover(altitude2); } ```

``` error: passing 'Feet' to parameter of incompatible type 'Meters' 20 | hover(altitude2); ```

Coming from a dynamically typed language (Python, etc), this might seem like a revelation, but its old news since the dawn of programming computers. A C language server will pick this up before compile time, just like `rust-analyzer` does: `argument of type "Feet" is incompatible with parameter of type "Meters"`.

Did you not know this? I feel like a lot of people on message boards criticizing C don't know that this would fail to compile and the IDE would tell you in advance...

In C++ you can even add overloaded operators to make using math on such structs ergonomical.

Compilers know of the idiom, and will optimize the struct away.

> An investigation attributed the failure to a measurement mismatch between two measurement systems: SI units (metric) by NASA and US customary units by spacecraft builder Lockheed Martin.[3]

IIUC, rust would NOT let you do a type checked m/s * s => m, so using the type system for these kinds of games is silly and dangerous (I presume you would have to do the dumb thing and typeconvert to the same type -- e.g.

    (m) (speed * ((m/s) seconds))

[1] https://github.com/helsing-ai/sguaba

I haven't written rust, but my impression is the benefit is more about deeper introspection of things like lifetime than basic typesafety, which already exists in C/C++ (and is likewise occasionally bypassed for convenience, so I wonder how often the same is done for Rust)

/s

I don’t actually mind Rust when I was able to write in safe user land, but for embedded projects I’ve had a much better time with Zig.

The fact that users have to keep up with multiple PEPs, error messages, --single-version-externally-managed, --break-system-packages, config files everywhere, stealth packages in .local and uv to paper over all of this shows that Python packaging is completely broken.

Yes well, glad to hear there’s no one bullying people there!

Yes, and I'm trying to point out why your argument is weak. You said things like this:

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

And it honestly just comes across as rather rude. People do write things that are new. People also write things that re-implement older interfaces. Sometimes those people are even the same people.

Like, why are you even questioning this? What does it matter to you? People have been re-implementing older tools for decades. This isn't a new thing.

> Nor did I claim that a rewrite is fine when it’s changing to a license I like.

When I pointed it out, your response was, "oh yeah but they did this other thing that made it all okay."

Hostile according to who? According to the haters, maybe. I’m sure the Go community was called “hostile” by haters back in the day.

Look at the drama created by Linux maintainers who were being insanely hostile, coming up with spurious objections, being absolute asshats - to the point where even Linus said enough was enough. The Rust for Linux members conducted themselves with dignity throughout. The Linux subsystem maintainers acted like kindergarteners.

But of course, haters will read the same emails and confirmation bias will tell them they’re right and Rust is the problem.

Keep hating.

John Deere, Caterpillar, etc are leaning heavily into the “connected industrial equipment” world. GE engines on airplanes have updatable software and relay telemetry back to GE from flights.

The embedded world changed. You just might have missed it if your view is what shipped out before 2010.

Kinda like how the purpose of creating LLVM was to create a more extensible compiler framework, not to create a permissively licensed compiler. As it happens the license of LLVM has not really led to the proprietary hellscape that some people suggested it would, and in any case the technical benefits vastly outweigh the drawbacks. Companies like Apple that do have proprietary compilers based on LLVM are difficult to describe as "freeloaders" in practice because they contribute so much back to the project.

> Okay so to create a five line script... For my five line script.

I can guarantee that your "five line script" simply does not have the mess of dependencies you imagine it to have. I've had projects run thousands of lines using nothing but the standard library before.

> Then I have to activate and deactivate it whenever using it.

No, you do not. Activation scripts exist as an optional convenience because the original author of the third-party `virtualenv` liked that design. They just manipulate some environment variables, and normally the only relevant one is PATH. Which is to say, "activation" works by putting the environment's path to binaries at the front of the list. You can equally well just give the path to them explicitly. Or symlink them from somewhere more convenient for you (like pipx already does for you automatically).

> And I have to remember to update the dependenceis regularly.

No, you do not in general. No more so than for any other software.

Programs do not stop working because of the time elapsed since they were written. They stop working because the world around them changes. For many projects this is not a real concern. (Did you know there is tons of software out there that doesn't require an Internet connection to run? So it is automatically invulnerable to web sites changing their APIs, for example.) You don't have to remember to keep on top of that; when it stops working, you check if an update resolves the problem.

If your concern is with getting security updates (for free, applying to libraries you also got for free, all purely on the basis of the good will of others) for your dependencies, that is ultimately a consequence of your choice to have those dependencies. That's the same in every language that offers a "package ecosystem".

This also, er, has nothing to do with virtual environments.

> Seems to me the companies managing mloc-codebases pushed their tradeoffs on everyone else.

Not at all. They are the ones running into the biggest problems. They are the ones who have created, or leveraged, massive automation systems for containers, virtualization etc. — and probably some of it is grossly unnecessary, but they aren't putting in the time to think about the problem clearly.

And now we have a world where pip gets downloaded from PyPI literally billions of times a year.

  fn sub(a:LeftOp, b:RightOp)

[1] https://github.com/johnperry-math/AoC2023/blob/master/More_D...

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, on a very specific set of hardware and in a rather specific case. Its basically the ideal set of conditions for a rewrite. But there are plenty of cases where attempts to swap in Rust aren't being done in ideal conditions like this. I doubt switching to Rust is never a good idea. I also doubt switching to Rust is always a good idea.

PS The problem is partly the way you write. I criticize ideas. You criticize me. That's a big part of why you get pushback.