You are conflating "new and cool language" with a "language that eliminates ton of possible bugs from the get go".

These two terms are far from identical.

You might be masquerading your conservative approach to new languages by hiding behind "C is mature". No it's not. Right now somebody on the planet is introducing a buffer overflow without knowing it, while coding in the "mature C".

Get real already, please. It's high time.

Random example: I dislike Go's error handling but the explicit nature of it has saved me from working half-asleep 50+ times already. Another one: one meager if/else in a supervised Elixir worker saved a server from infinite repeating of a bugged task that would otherwise keep crashing forever. There are others, lots of them. I am sure people can give plenty of examples for Rust as well.

I think you're overreacting. The GP wasn't being conservative about new languages for new projects. S/he was merely warning that rewrites carry their own risks, which might outweigh the benefits of better languages (or for that matter other infrastructure). If you avoid 100 bugs in the new version but add 101 because you didn't completely understand the old code and the environment it runs in, you haven't come out ahead. This phenomenon has been too well known for too long to be blithely ignored.

Me over-reacting is most likely true. Been dealing with people dismissing unquestionably life-improving tech for far too long lately.

Sorry.

I do believe most of Linux userland has to be rewritten though. Be it Go, Rust, Nim, D, doesn't matter much as long as it's a memory-safe language.

> I do believe most of Linux userland has to be rewritten though

Why? I'm sympathetic to the argument that 2017 computing shouldn't be on the basis of 1970s UNIX limitations and mindset, but changing that would require a lot more than just rewriting the user land applications, and would require a bigger re-think.

But assuming that the shell's functionality is OK as it is, what's to be gained in a re-write?

For one thing, piping being mostly text-friendly is limiting in many scenarios I stumbled upon. A modern shell should allow arbitrary objects to be piped and processed, much like the functional programming paradigma. The UNIX idea was and still is wonderful, but we're past the text-only thing.

In any case, I feel (and I don't have tens of facts, I admit) we're dragged by the past for far too long. Others have documented their gripes with the current incarnation of Ops / sysadmin problems much better than I could. Here in HN (but I think years ago).

That makes no sense. There has been a ton of research. C, needing to be backwards-compatible, can only implement a subset of that research. More modern languages, not having this burden, are free to implement the entirety of this research. Therefore, C can only be at most equal to new languages, and overwhelmingly likely worse.

Makes a lot of sense. You have 2 scenarios; 1) old code base in C, rewrite in language du jour. 2) new functionality in either C or spiffy lang 2.0 (SPIFFY).

For scenario 1, all that functionality has to be duplicated, including "defects". Are you sure that the functionality is 100% there or did you miss any use cases? Decision for leaving it.

Scenario 2, new widget. Most likely, coding in SPIFFY will be a better choice.

Run old anomalous traffic on old codebase that can handle the corner cases. Run the new traffic over the safe code that covers 80% of the use cases.

Slowly expand the percentage of traffic coverable by the new safe code.

The 80 percent case can be written and coded in a small amount of time. In curls example, it is fetching a file over http 1.1 using an encoding, possibly following some redirects. Then post and put requests, then chunked uploads, downloads, then?

Need gopher and ftp? Run the old codepath.

If you had a list of all the corner cases from the start, wouldn't it be easy to just cover them in the new code? I thought the point of corner cases was that they introduce bugs because we don't think of them when we design the system.

If you could infer a spec from the existing code, you have at least a 100M product on your hands.

And probably solved the halting problem too ;)

Is that because C is a "good language", or just because rewrites are error prone?