No, it has nothing to do with Rust.

gwd an hour ago | parent | next [-]

But it might have something to do with the "rewrite" part:

> The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive.

> Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

> Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

> When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

From https://www.joelonsoftware.com/2000/04/06/things-you-should-...

▲

windward an hour ago | parent | next [-]

A lot of words for a 'might'. We don't know what caused the downtime.

▲

gwd an hour ago | parent [-]

Not this time; but the rewrite was certainly implicated in the previous one. They actually had two versions deployed; in response to unexpected configuration file size, the old version degraded gracefully, while the new version failed catastrophically.

	▲	perching_aix 22 minutes ago \| parent \| next [-]
		Both versions were taken off-guard by the defective configuration they fetched, it was not a case of a fought and eliminated bug reappearing like in the blogpost you quoted.
	▲	42 minutes ago \| parent \| prev [-]
		[deleted]

▲

perching_aix an hour ago | parent | prev [-]

[dead]

▲

zwnow an hour ago | parent | prev [-]

The first one had something to do with Rust :-)

▲

kortilla an hour ago | parent [-]

Not really. In C or C++ that could have just been a segfault.

.unwrap() literally means “I’m not going to handle the error branch of this result, please crash”.

▲

mike_hearn an hour ago | parent [-]

Indeed, but fortunately there are more languages in the world than Rust and C++. A language that performed decently well and used exceptions systematically (Java, Kotlin, C#) would probably have recovered from a bad data file load.

▲

koakuma-chan an hour ago | parent [-]

There is nothing that prevents you from recovering from a bad data file load in Rust. The programmer who wrote that code chose to crash.

▲

mike_hearn an hour ago | parent [-]

That's exactly my point. There should be no such thing as choosing to crash if you want reliable software. Choosing to crash is idiomatic in Rust but not in managed languages in which exceptions are the standard way to handle errors.

	▲	koakuma-chan an hour ago \| parent [-]
		I am not a C# guy, but I wrote a lot of Java back in the day, and I can authoritatively tell you that it has so-called "checked exceptions" that the compiler forces you to handle. However, it also has "runtime exceptions" that you are not forced to handle, and they can happen any where and any time. Conceptually, it is the same as error versus panic in Rust. One such runtime exception is the notorious `java.lang.NullPointerException` a/k/a the billion-dollar mistake. So even software in "managed" languages can and does crash, and it is way more likely to do so than software written in Rust, because "managed" languages do not have all the safety features Rust has.