If #git makes #Rust mandatory it will block future git versions to be ported to our niche platform. While this would not immediately lock us out of repos (the current version will likely continue to work fine some time) it eventually would complicate access (all git work would need to be circulated via some proxy setups or similar).

Needless to say I'm not thrilled by this idea.

I am not against Rust. I am against breaking change that leaves everyone not embracing Rust behind.

https://lore.kernel.org/git/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im/

@harrysintonen A platform that needs to run dev tools itself (rather than being a compilation target), but isn't supported by LLVM seems to be a niche of niches.

@harrysintonen There is Rust for m68k: https://doc.rust-lang.org/nightly/rustc/platform-support.html

Rust added PowerPC support 9 years ago. You can contribute whatever linker/ABI/libstd back-end is needed for MorphOS.

There is Rust for Dreamcast too: https://dreamcast.rs/setup.html

@kornel I appreciate the advice and the enthusiasm. However, there are problems that are not obvious to an external observer.

Currently, the only realistic way we ever get Rust is via gccrs. In fact, I can compile a working minimal binary with gccrs (while calling the C library runtime). This support is far from being ready for prime time. Also, considering the outright hostility towards the gccrs project, I don't feel much confidence it ever getting to truly usable state.

@harrysintonen What's stopping you from using LLVM's PPC codegen? rustc can emit .o files that GNU linkers usually understand. Are you blocked by ABIs, relocs, pre-main startup code?

I wasn't aware of hostility towards gccrs, but even in an ideal world a new front-end is a huge undertaking, and won't be ready anytime soon. But rustc+llvm and rustc+gcc backend are there already.

(BTW, I've had Pegasos 1 w/April, but I never needed to look into executable formats).

@kornel Our backend isn't vanilla PPC elf, so it requires a fair bit of massaging to get things going (gcc and binutils alone were a huge undertaking). We currently don't have modern llvm, and are stuck on a very old version.

@harrysintonen Do you need big changes on the codgen side? I imagined you would cross-compile from modern vanilla LLVM, using a custom rustc target (that lets you tweak ABIs, reserved registers, mangling, etc.), generate .o files, and then use your platform-specific gcc to make executables from them.

@kornel diff to gcc 15.2 is about 6000 lines and diff to binutils 2.45 is nearly 5000. So not insignificant by any measure.

@harrysintonen @kornel "upstream first" idea is not so popular in MorphOS team or something?

Maintaining such patchset must take some time...

@hrw @kornel Oh I wish we would live in a world where everything was that simple.

I know the patch would not be accepted by upstream, not by a long shot. The code is way too janky. Heck, I would not accept it, if I was in their position.

@harrysintonen @kornel

The usual "how to eat an elephant" applies?

Split to parts, triage, start with easier ones?

@hrw @kornel Sure. But once we have gcc / binutils upstreamed this translates into having rust how?

I think there's a disconnect in the discussion here.

@harrysintonen there is a GCC backend for Rust (a separate project from gccrs), so if you have codegen working in modern GCC, it could work there too.

For LLVM a custom r13-relative addressing seems like a harder problem. Maybe you could mark r13 as always reserved and live with less efficient code?

@kornel We of course employ cross-compiling. But still, being left out in that manner is still unfortunate, as we try to offer as complete and modern native SDK as possible.

I fully acknowledge that this is something we just have to live with. We are doing our own thing, and we can't possibly expect everyone else to cater for our platform quirks.

However, there are other platforms far from being this obscure that will be hit as well: Various legacy Debian platforms (alpha, hppa, m68k and sh4) and NonStop, AIX and Solaris come to mind at least. There are likely more.

@harrysintonen @kornel A couple of years back, there was a even proposal to change the m68k Linux ABI to cater for the internal limitations of Rust and LLVM that was ill equipped to deal with the requirements of this - admittedly, historic - architecture.

Being a compiler hacker myself, to me this meant: it is seriously immature, not ready for prime time. But for people pushing Rust, throwing away 4 decades of compatibility was completely justified, because fixing the world was more important.

@harrysintonen @kornel I think the problem was that it was a 32bit platform that had a less than 4 byte natural alignment - 2 byte in case of m68k - and this needed very deep changes to accommodate. But don't quote me on this. Maybe this was fixed since, no idea, I stopped caring.

We obviously do not speak the same languages nor share most values with these people. I tried to have an open mind, but the way it is pushed just makes me resent the whole thing. Maybe "I'm too old for this shit."

@chainq There's definitely a mismatch of values, and Rust is future-looking rather than backwards-looking.

Rust is 10 years past 1.0 release. The implementation is quite mature in what it targets.

Lack of obscure/legacy things is immaturity only if you assume having them is a goal, but Rust prioritized other things, like safe multithreading, early WASM support, modules, error handling, metaprogramming, UB prevention/detection. From Rust's perspective these are woefully immature hacks in C.

@kornel Spare me the buzzword bingo, please. I'm old enough to have heard a similar list from at least half a dozen "this is the future" tech/language advocacy group, over the past 3 decades.

Every revolution and their leaders in history thought the losses it causes are temporary, and justified for a better brighter future. And because they're building a better and brighter future, they're morally justified to make the choices for everyone. This is no exception, it seems.

@kornel @harrysintonen Sorry, but that’s bullshit. For me, this Git change is so catastrophic that I might have to move to something else. I run Git on a lot of old platforms. Because I support them. Which means I develop on them. Which means I use Git to track my changes.

PowerPC macOS, AmigaOS, MS-DOS, HP-UX, Irix, QNX to name just a few. And that is only a fraction of the list. These work perfectly well for editing source code, compiling natively, commiting the changes to Git and to push it. That all works today. And it will stop working for no reason other than that Rust people a.) have to infect every single project and b.) seem to get some weird pleasue out of dictating people what platforms they have to use. The “rewrite it in Rust for no reason” was bad enough (especially when it wasn’t even something security critical and would just introduce new logic bugs) - but apparently that did not force Rust on enough people so now it needs to be pushed into every single C project with as much force as possible and screw people on other platforms - how dare they use anything other than modern macOS, Linux or Windows? “It’s not what I use, so fuck those people!”

I am sure there will now be mentions of gccrs. Rust people love to point out that this will fix all these portability issues. Meanwhile, Rust people outright bully and harass gccrs people for “how do you dare to add fragmentation to the ecosystem?”.

Sorry if I sound bitter. It’s because I am. I liked Rust when it was new. But then Rust people decided to make half of my computers unusable. First by introducing Rust to librsvg, so I can no longer run a desktop. Then by forcing it into python-cryptography, so I could not run server stuff there anymore, either. And now they’re trying to make the few remaining computers I have that Rust people left usable also unusable by forcing it into Git. I really wanted Rust to take off in the beginning and liked the language. But this constant and repeated behavior has made me fight it with everything I’ve got.

If you want an SVG library in Rust, write a new one.
If you want a cryptography library for Python in Rust (for some reason), start a new one.
If you want a DVCS in Rust that is Git compatible, write a new one. (The OpenBSD people did exactly that, so it’s not impossible. They did not try to force their world views on others.)

@js Yeah, I see that it is terrible for your chosen platforms. But they _are_ niche and discontinued (except QNX, which also has Rust). That's a tough spot to be in. Projects weigh costs/benefits. When supporting old platforms and old compilers costs devs' time or productivity, it is an opportunity cost affecting all users, but a benefit for vanishingly few.

You prefer using retro computers, but Git devs prefer having benefits of a modern language.

@kornel @chainq

Lack of obscure/legacy things is immaturity only if you assume having them is a goal, but Rust prioritized other things

You illustrate the problem perfectly here: thinking that it’s either / or is a broken way of thinking.

Even if it were the case that prioritizing certain things precludes others (which it most certainly isn’t, unless you’re doing things incorrectly), this is precisely why Rust is inappropriate for universal adoption.

If a certain corporate led group gets to decide what is “obscure/legacy”, then people either have to maintain their own forks of Rust, or we just have to blindly accept that things that aren’t popular enough or that don’t get enough attention by corporations will be deemed, “obscure/legacy”.

@kornel @chainq This is bad for the planet. We should make good use of our computing resources and not intentionally landfill them. m68k is an example of how we can maintain support for non-mainstream if we want, yet people who know nothing about m68k would love to kill it for emotional reasons. We don’t need this at all. We’re already seeing this with Debian and i386.

So when people want to lump things in to an “obscure/legacy” category and suggest that the problem isn’t Rust, that just means you’re cheerleading for reducing sustainability.

@AnachronistJohn I agree about making good use of existing hardware in general, but the platforms in question are extreme outliers. They have less compute than a smartwatch, but use relatively way more energy. Eventually extra energy used technically exceeds ecological impact of making new efficient hardware.
Enjoy retro platforms if you like, but please don't stretch it into a moral obligation.

I've used 68k Amiga as my main computer until ~2005. I know very well what I'm leaving behind.

@chainq @kornel Here’s a good example. How many people are even aware of the existence of SuperH? Do you know about SuperH? People who advocate for the dropping of i386 make claims of “cost” and “developer time” - of course they’d advocate for dropping support for processors they’re not even aware exist. Yet if you have a working (non Rust) toolchain, you can compile thousands of open source packages that were written by people of whom a vast majority probably know little or nothing of SuperH:

https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/sh3el/

It’s somehow viable in 2025 to have something like this with a modern toolchain, a modern OS, and thousands of compiled packages. So should people like you, who would most certainly consider SuperH to be “obscure/legacy”, be listened to when you advocate for Rust and the exclusion of what you somewhat dismissively consider to be “obscure/legacy”?

Rust is fine, but the advocacy is a bit exhausting, especially from people who show little awareness of the implications of getting what you claim to want.

@AnachronistJohn @chainq @kornel It should be noted that there are people using Rust on SuperH: Specifically for the dreamcast: https://dreamcast.rs/

@AnachronistJohn it's cool that it's possible, and I don't have anything against it. But if I'm forced to choose between writing software that might run on SuperH (but probably won't due to speed & RAM requirements) vs being able to write more reliable software that runs better on still-manufactured CPUs, I choose the latter. I also gain access to thousands of new libraries, with better interfaces, and painless support for Windows. I can do more things in practice, and find them more valuable.

@kornel @chainq You remind me of myself when I was on my "Oberon! Let's all do Oberon!" rants in the 1990s. You do you. And in about 35 years you'll be going "Hey, why did you cut Rust off? That's mean, we worked hard on that!" and someone in theirs 20s will say "Get with the program grandpa!" 🤷

@phf The goal isn't to stick to one language forever, but to enable writing better software, easier.

There are switching costs, network effects, and many trade-offs, so replacing languages is a complex issue.
IMO it makes sense to switch from C to Rust now (in many, not all cases). It's also possible that in 35 years there will be something new that obsoletes Rust, and it will be a good thing.

@kornel That’s the thing - you’re not asked to choose between “writing software that might run on SuperH (but probably won’t due to speed & RAM requirements) vs being able to write more reliable software that runs better on still-manufactured CPUs”.

You invented those limitations. If you received a problem report about running on SuperH, it sounds like you’d focus more on how “irrelevant” it is, how support is a waste of time, perhaps, rather than focusing on the idea that fixing something, even something that’s an edge case, generally means code is better.

The Rust ecosystem is nice and all, and nobody is saying that anyone should abandon it. Of course you’ll all have your npm moment when crates get backdoored, but that’s just how these things work.

The real issue is that people in the Rust community want to replace everything with Rust versions while dismissing fallout as unimportant because “obscure/legacy”.

Sorry, but no.

@kornel To clarify - you’re making the example as though Rust refers to, “being able to write more reliable software that runs better on still-manufactured CPUs”, and C refers to, “might run on SuperH (but probably won’t due to speed & RAM requirements)”.

Nobody should tell you that you shouldn’t choose to write Rust. If that makes you happy, great!

But just think about how you shouldn’t tell others that they need to adopt Rust or consider themselves a “niche of niches” or “obscure/legacy”.

@AnachronistJohn There's a conflict here, but it's not that obvious to me whose wants/needs should be prioritized over the others.

Git devs decided they prefer Rust (maybe it makes them happy). Git has other users who benefit from what Rust offers.

You end up forced to have Rust to continue getting new git versions.

OTOH supporting all old platforms forces Git devs to keep writing C.

Why is it right for you to tell Git devs to use C? Why should your git use-case override other users' needs?

@kornel You do realize that you're re-making the point, which is that arbitrary metrics are arbitrary.

"the platforms in question are extreme outliers. They have less compute than a smartwatch, but use relatively way more energy."

That could be said about older amd64, or modern Intel systems. That's already said about 32 bit x86. You're advocating for a popularity contest, really.

"Eventually extra energy used technically exceeds ecological impact of making new efficient hardware.

The amount of recources needed to create the things in the first place is huge. Who is to say that someone that only has access to older hardware but also has access to solar panels should landfill their hardware and waste the resources necessary to create new hardware because someone else is gatekeeping?

@AnachronistJohn Details vary depending on context and what you measure, e.g. from CO2 emissions perspective, in data centers using fossil energy sources, the effect is large enough that it may make sense to upgrade immediately, even new amd64.

There's a whole range of scenarios where the break-even point shifts. '90s hardware has 100×-100000× worse compute/Watt, but the impact (or savings potential) is also small in absolute terms, because so few units exist.

@kornel "Enjoy retro platforms if you like, but please don't stretch it into a moral obligation."

That's the exact emotional reasoning we constantly see from people who want to end support for all sorts of things - end everything big endian, end everything that doesn't have huge corporations behind them, and so on.

Is this the business you want to be in? Do you want to be the person coding based on popularity contests and corporate worth? Because by taking a stand to defend the practice of arbitrary deprecation, that's basically what you're doing.

Perhaps consider programming without value judgements, without telling others that their stuff is obsolete.

@kornel "I've used 68k Amiga as my main computer until ~2005. I know very well what I'm leaving behind."

Funny you should bring up Amiga. It's 2025 now, and we have new, updated versions of AmigaOS. We have modern SSL and browsers that can browse the web comfortably in 16 megs of memory. We have systems with single or double digit MHz processors that have less latency than brand new Windows computers.

They are a perfect example of what some of us strive for, of what's possible in spite of all the people who swear that we literally need 8 gigs of memory to load and run a web site or participate in a multi-person chat.

If the emotional people who just repeat what they're told had their way, modern AmigaOS and modern software on the Amiga would just be a "waste" and wouldn't happen. Isn't it great that we don't listen to those people? Isn't it nice to have examples of how wasteful modern computing and modern programming can be? I know you don't think so, but the very fact of their existence is enough to show that not everyone and not everything needs to go down the same incredibly wasteful paths.

@AnachronistJohn I know, I've learned web dev on iBrowse and AWeb, and worked professionally on website performance optimization for years.

There's always bloat, and you can always optimize better if you want. It's not necessary to have old hardware to do that, unless you want to *force* it. Do you?

I recently commented about Wirth's “A Plea for Lean Software” who dissed computers with 16MB of RAM as having too much. He'd have written a multi-person chat in 32KB: https://lobste.rs/s/g9z6o4/death_utilitarian_programming#c_6gpyxx

@kornel You bring up the central issue: Who gets to say whether something is written in a certain language?

If you want to write your own software, then you do, obviously :)

The thing is that if a project wants to switch from a universally accessible language to one that’s not quite as accessible, they can do that, but if that project has made itself a part of other projects in ways that make it difficult for those other projects to change, then that’s a bit of a dick move.

That is, if you’ve made yourself indispensable, then you want to make large changes that’ll negatively affect other projects who trusted your project enough to depend on it, nobody would be in the wrong to call you out on that.

@kornel The reason I'm writing here is because you're basically towing the party line: you think that if something is, as you put it, "obscure/legacy", it's fine to just dismiss it.

You're entitled to your opinion, but expect to be called out when your opinion is based on inexperience. Instead of coming across as someone who understands what it might mean to be "obscure" and/or "legacy", you just come across as someone who naively has this idea that what's normal for you is normal for everyone, neatly ignoring what these things mean to people with limited resources (that is, who live in poorer parts of the world, or who are just simply poor), or what they mean to devices with limited resources (that is, embedded and embedded adjacent applications, and/or devices that have no reason to be replaced).

In other words, advocate for Rust all you like, but don't be so naive in your assumptions about everyone else that you think it's OK to be dismissive of their wants and needs.

@kornel So one should ask: why shouldn’t git be forked if some of the developers really want to use Rust? I think it should be forked. Unless there’s some intractable problem with functionality, scaling or implementation that can only be fixed by switching to Rust (which, let’s be honest, there isn’t), there should be an accessible version, and at the same time there can be a Rust version, and if the git team don’t want to maintain separate C and Rust codebases, the fork can be completely separate.

But does the official git project get to switch to Rust, sunset the C version, then tell people they can’t call a fork that sticks with C git? This is the problem with project stewardship, and is another issue altogether.

When people depend on you (“you” being the git project here), and when you’ve cultivated that dependency, then there really is an obligation to consider the impacts of large changes.

@AnachronistJohn But *the* git developers wanted to adopt Rust themselves, and the project has reached a consensus about it.

Whether this Ship of Theseus should have been called a fork or not doesn't really change the reality of where the development is going.

They have considered the negative impact on niche platforms, but weighed it against benefits of Rust, and burdens of continuing with C, and the other factors won.

There's no rule that everyone has to use C unless absolutely necessary.

@AnachronistJohn You're making inaccurate assumptions about my experience & background. I think it's quite possible that we differ in opinion not due to ignorance, but due to judging situations differently.

For example, I don't think real Amiga hardware can help people in poverty. Even if they happen to have one already (with rare accessories it needs), they'd better of selling it to hobbyists, and getting RPI or old 64-bit PC instead, which are much faster and more capable.

@js @harrysintonen @kornel why should most people who aren't using ancient software deal with segfaults so that people can use MS-DOS in 2025? i love to retrocompute, but it's also a niche hobby.

mentioning i.e. QNX is disingenuous considering almost all usage of it is embedded cross-compilation contexts. BB or their customers can pay develop a port if it matters to them, same as i.e. IBM is doing for AIX.

rust is IMHO, a canary for if things actually have active communities or if it's just inertia. besides, there's always libgit2.

@libc @harrysintonen @kornel How many times did Git segfault for you? How many times however did you have logic bugs? If we have seen anything from all those Rust rewrites, it’s that there is no improvement in stability, but a high increase in logic bugs. The mindset of “Rust code can’t have bugs” isn’t helping either, as it makes people sloppy and hence even results in MORE bugs. The results of all “Rewrite it in Rust” projects so far have turned out a failure.

QNX is not disingenious as you can use QNX 6.5.0 as a desktop system. It’s a really nice and fast desktop with it’s Photon UI. I support that on pkgsrc, for example. And I’ll let you guess what tool I use to manage patches I create for it.

@js Git releases are mostly fine, but it's not apparent how much effort it takes to get there, and what needs to be sacrificed (typically multithreading is kept to minimum due to C risks).

Nobody seriously claims Rust can't have bugs, that's a strawman. It eliminates certain classes of bugs, helps with reliability, but nothing is absolute.

Rewrites are risky indeed, but e.g. librsvg fixed tons of bugs. Dropbox, Android report major successes. Fish, Firecracker, Stylo/Webrender, sudo-rs worked.

@kornel Well, the thing is that Git people were even cautious about using C99(!) so far, because they really cared about portability. Until the Rust people came.

@js Nobody came. Project members decided themselves. They've tried Rust, liked what it does, and became the "Rust people".

C upgrades are tricky, not for strictly technical reasons, but expectations that any crappy compiler anyone has should work, and cause annoying busywork. I've had these pains in my C99 projects too. Users don't like being told to use a modern C compiler as much as they don't like being told to use Rust.

@phf @kornel if all Rust accomplishes is being the on-ramp for another, better tool chain, it will have been worth it. Even then, I have my suspicions that Rust is here to stay.

@kornel What evidence do you have that there is a significant amount of segfaults before Git hits a release? And no, multi-threading is not more risky in C than in other languages. Multi-threading is inherently more challenging to the human brain, no matter what language, so if it’s not necessary, it reduces complexity to avoid it.

Well, there are plenty of people who claim that just by rewriting software in Rust, it has fewer bugs. So far I’ve only seen the opposite.

@js There is a colossal difference between ease and reliability of multithreaded code in Rust vs C.

In Rust, the type system enforces shared XOR exclusive access precisely, prevents non-tread-safe data from being shared with threads, prevents UAFs due to operations finishing in a different order, and enforces use of mutexes or atomics for global or shared data. This works reliably, at compile time, globally even across 3rd party code and dynamic callbacks.

@kornel Great demonstration of the typical Rust fanboy’s attitude of “I don’t need to be careful because the compiler will take care of it for me”. This is not enough for multi-threading. Proper locks-free algorithms need proper care, no matter which language. How is the atomics situation in Rust, even? Did they even define a proper memory model for this? (Granted, C and C++ took until 11 for that, too). Just throwing a lock at everything and enforcing that is something C++ can also easily do. But that is not how you get performant multi-threaded code.

@js Even if you assume that having a hard to avoid risk forces extra diligence:
1. humans are fallible, even the smartest ones, even when maximally careful.
It's especially hard for humans to reliably gather program-wide info and uphold invariants across time and teams. Compilers can help do this reliably.
2. amount of time/effort spent on software is finite. If everything in the program can be catastrophically dangerous, the effort is spread thin across the whole program, but still has to […]

@js …still has to be infallible. OTOH when the compiler can reliably check majority of the code, and prevent the most tedious and pervasive issues, the effort can be focused on the parts that the compiler can't guarantee. This gives overall higher reliability, because the compiler-checked invariants are perfect, and the dangerous parts get extra eyes on them.

It's like changing "Where's Wally?" game with a large map into a couple of "Is *this* Wally?" mugshots to identify.

@kornel 1.) I agree that tooling to help catch human errors is useful. However, this is not exclusive to Rust, and other languages have static analyzers, too. Rust just runs the static analyzer during compile time.
2.) Exactly. So it makes more sense to keep what is already there and debugged. And yet, the Rust community demands - very loudly - existing, perfectly working software to be rewritten in Rust. Because it is a religion, not a language. The outcome or whether it makes sense is irrelevant, it’s just fundamentalism that everything needs to be Rust.

@js Rust has ability to provide these guarantees only because of coding patterns it doesn't support (e.g. no reference cycles), and annotations it always requires (Send/Sync and lifetimes on everything).

C doesn't enforce code to be compatible with this static analysis. It has no machine-readable information about thread safety. This isn't solvable by writing a better static analyzer (Rice's theorem, Halting problem).

@js "Already there and debugged" is code that has already been written and tested.
When adding new code, you keep risking breaking assumptions in the existing code, thus creating bugs. The more assumptions are explicit and enforced automatically, the harder is to break them by accident when adding new code, which reduces rate of defects introduced.

@kornel I might agree with you here that in C, such annotations are a bit clunky (but possible!) to aid a static analyzer, and that it’s much easier with C++’s templates. However, the only thing Rust is different here is that the static analyzer is MANDATORY. Everything else can be done with any other languages as well. Everything can be annotated so it can be checked by a static analyzer. Heck, mrustc is the perfect example that all that is not so much part of the langauge and it IS possible for Rust too to compile it without the static analyzer pass.

In fact, I’d argue the static analyzer pass should only be used during development. Static analyzers are slow. In any language. And always running it, even when the developers already did it, is what leads to those ridiculously atrocious build times with Rust.

@js There are hard limits of static analysis. This is a well-studied topic, with many cases having logic proofs that they are literally impossible to ever solve, and even those that are solvable in theory end up having exponential compute or memory cost.
I know "halting problem" seems abstract and irrelevant, but questions like "is this field of this object ever accessed from another thread?" can easily end up hitting the same problems. This affects most code in most languages.

@js Cases where it's possible to give whole-program guarantees are an exception, not the norm. It requires program to have certain simple-to-analyze "shape" of its data flow, and/or guarantee to have dynamic checks in all the places that may be missed statically.
mrustc is Rust -> C, but this loses information. Proving properties of C code is more like going in the other direction C -> Rust, and that's asymmetric, like generating a hash is easy, generating preimage is hard.

@kornel Rust cannot solve the halting problem either. So you are moving the goal posts. Nobody ever claimed static analysis could do this, Rust cannot do this, but now you demand C can do it or bow to Rust. All the static analysis performed during the Rust compilation can be done in another language just as well if you add annotations for the static analyzer.

@js Rust doesn't solve the halting problem, but Rust does forbid code patterns that would lead to halting problem dead-ends.
Rust famously doesn't support making doubly-linked lists from references, because that creates cycles and shared mutable ownership, which makes it a much much harder problem. Rust allows only "easy" code. C is much more flexible, and doesn't draw the line at easy-to-analyze code, and you can't expect existing C codebases to happen to fit the "easy" shape of code.

@js Maybe it will be easier to understand this way: we don't have tools that reliably add static types to dynamically-typed languages.
We have types for them, but adding them to a codebase is not always possible without changing the code, if the code actually uses duck typing, monkey patching, reflection, or is undecidable or O(2^n) expensive to evaluate.
You may need to remove/redesign the too-dynamic properties of code before you can give them non-ridiculous static types.

@js and similar problems arise in C, where you could see it as having dynamically-typed ownership and lifetimes. The dynamism may be an easy case, or a hard case, or may be dynamic to the point it's impossible to express in a reasonable way (where type annotation doesn't explode to being just as complex as the code it describes).

@kornel And just as much as Rust limits what you can do, you can have a static analyzer for C, too, that limits what you can do, and only allows you to do it if you add proper annotations to proof to the static analyzer that it’s safe.

Again. The only innovation Rust here has is that it made the static analysis and the annotations for it mandatory in the default compiler. It doesn’t even go into proving code for correctness, which can be done in other languages. If you want a language where you can proof everything, Rust is even the wrong language for you, and I’d suggest to look at languages such as Haskell and Ada. Languages way older than Rust, having way more research about proving code is ACTUALLY correct.

But, that’s not the hype, so, obviously nobody is pushing for projects to migrate to those languages. Because, again, the entire push to Rust is not because of real outcomes. Those could be achieved by other languages just as well. No. It’s because it’s a religion. A cult.

@js The analysis Rust can provide depends on things like lifetime annotations, traits, generics. C users generally reject that level of complexity and inflexibility, and existing code bases aren't written using these design patterns with such annotations.
Maybe this could be solved in C, but it wasn't. Rust has 200K+ packages written with these annotations and restricted patterns. How many C has?

Rust doesn't claim to be novel or first at this. See pages 6-7 http://venge.net/graydon/talks/intro-talk-2.pdf

@js In a Modern Art Gallery, you may see a canvas with a lame splatter of paint on it, and think "I could have done that!"

*But you didn't!*

It's not your canvas on the wall. Whatever it took to get there, easy or hard, someone had to do.

Maybe any language could have added the annotations and build tooling that achieve such robust thread safety guarantees, *but they didn't*. Rust already has a 10-year head start on this, and a whole ecosystem written this way.

@js Regarding speed of static analysis, this is one of C's own problems. C doesn't have good aliasing information, no ownership info, no thread safety info, weak const, it ends up requiring expensive analysis, usually whole-program, just to discover this information.

In Rust this is available locally in the source code, no search required.

Rust is known for slow compile times, but the static analysis part of it is surprisingly small. Negligible compared to LLVM optimization times.

@js When you reduce the whole issue to a "cult" or "religion", it's a dead-end for understanding. You get to call people names and feel superior, but you gain no insight this way.

*You don't have to agree* with the reasons people have, but terminating your reasoning at "it's a cult", just leaves you baffled, and it's not helping you make a convincing argument.