FWIW - last stage where the binary is produced takes the longest and is single threaded and that's the largest difference between release and debug.

```

> cargo clean && time cargo build

cargo build 713.80s user 91.57s system 706% cpu 1:53.97 total

> cargo clean && time cargo build --release

cargo build --release 1619.53s user 142.65s system 354% cpu 8:17.05 total

```

this is without incremental compilation. And it's not like you have to babysit a release build if you have a CI/CD system

I get the sentiment though, "He blew management's mind so much they made an exception for him".

But, Folklore.org is a bit less onanistic than ESR's jargon file.

For what it's worth, here's quicksort in 5 lines of haskell https://stackoverflow.com/questions/7717691/why-is-the-minim...

1 - GNU utilities is ancient crufty #IFDEF'd C that's been in maintenance mode for decades. You want code to handle quirks of Tru64 and Ultrix? You got it.

2 - Waving your hands around 'the community will take care of it' is magical thinking. C developers don't grow on trees. C tooling is kinda weird and doesn't resemble anything modern - good luck finding enough VOLUNTEER C developers to make your goals happen.

In OSS every hour of volunteer time is precious Manna from heaven, flavored with unicorn tears. So any way to remove Toil and introduce automation is gold.

Rust's strict compiler and an appropriate test suite guarantees a level of correctness far beyond C. There's less onus on the reviewer to ensure everything still works as expected when reviewing a pull request.

It's a win-win situation.

Three of my direct coworkers died from covid. One guy didn't get his sense of taste back for a year.

People just gasping to death in their bedrooms waiting for things to improve and only going to the overloaded ER when it's too late.

I'm an asthmatic, I've been close to that feeling where sub 90% oxygen saturation made me feel like death. Anything like 80% your lungs start to fail. You're dead in a hurry.

You do all this upfront design about how it's going to work and then "Oh god there's so many splinters and sharp corners, it's only getting worse and every new team onboarded to the framework needs to have their hands held, and management won't allocate time to address the tech debt."

Also the subtle flex of making the Donkey Kong girders on an angle when the 2600 is a 'race the beam' system where each scanline must be computed. Even modern homebrew remakes of Donkey Kong on 2600 have horizontal girders.

So - I'm guessing game logic of MECC Oregon was in Basic with some assembly routines to re-draw the screen. BTW original Oregon Trail was also 100% basic and a PITA to read. You're really getting to the edges of what applesoft basic is practically capable of with games like Akalabeth and Oregon

Or is it "You fool! Building your own kitbashed Gundam of an OS is the point."