I like that go feels sort of quaint and outdated. It makes it easy for pretty much everyone to jump in and contribute to a code base without having to learn too much. Rust is great, but it is not a language you can just jump into.

Author here.

>The main fallacy of this blog post is that he wants it to be one single programming language that replaces C.

That's not at all what I'm suggesting. In fact I thought this part of the article makes it clear that I feel the opposite way:

>C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex. Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible. It hasn’t completely replaced C, but it has made a substantial dent in its problem space - more than I can really say for Rust (which has made similar strides for C++, but definitely not for C).

> It hasn’t completely replaced C

The keyword here is completely. Rust doesn't need to completely replace C, it only needs to cover those usecases other languages haven't already covered. Or maybe just some and a completely different language takes what is left.

You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être.

If you dismiss this outright, you could have written a much shorter article or at least written a much more interesting article by starting with this admission and from that working your way through Rust's feature and explaining how this doesn't alleviate the warts of Rust.

> But now you know why we are still writing C

I wonder who this "we" is?

I'm also still writing C but for quite different reasons. Mostly because of legacy code and to some degree even just to be able to claim that I'm working on 35 year old code.

> You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être.

Rust is still young. I think it's a bit naive to proclaim the language of the future is here. Why?

That was also the point of Ada until people realized that unhandled Constraint Errors could still crash missiles.

https://itsfoss.com/a-floating-point-error-that-caused-a-dam...

That was the point of Java until people realized that JRE's were full of security holes.

https://www.cvedetails.com/vulnerability-list/vendor_id-93/p...

So, what's the point of Rust again? To protect us from all these security holes? Wasn't that also the goal of other languages?

> I wonder who this "we" is?

TIOBE says C is second most popular language after Java even with all the security holes. So there's a lot of "we" (though I don't code in C).

https://www.tiobe.com/tiobe-index/

> Rust is still young. I think it's a bit naive to proclaim the language of the future is here.

I never claimed that Rust is the language of the future. I didn't say it directly but I think you can deduce it from my comments that I consider a multi language approach more sensible than using the same programming language for everything.

Using Rust is more safe than using C. That's valuable.

> So, what's the point of Rust again? To protect us from all these security holes? Wasn't that also the goal of other languages?

Are you saying that just because Rust doesn't solve all problems it isn't worth having? You're also conflating stuff.

The Ariane 5 explosion was not a programming error, it was a testing and specification error. The code worked exactly to the spec but the spec was for another piece of hardware. You can't use a fork and complain that it's not a good spoon.

How about quantifying the bugs in the JRE against all the buffer overflows in similar C code? 600 CVE worthy bugs in 10 years doesn't sound like that much if you put it that way.

https://www.cvedetails.com/product/19117/Oracle-JRE.html?ven...

> TIOBE says C is second most popular language after Java even with all the security holes. So there's a lot of "we" (though I don't code in C).

The TIOBE index has some issues. It is essentially counting hits for a search engine query for a specific language. I would rephrase it as "C has the second most webpages on the internet."

On PYPL it is only the 6th popular language, although coupled with C++.

Nevertheless there is still demand for C. Otherwise we wouldn't even have this discussion at all. But most people would rather see this demand decrease as we haven't been able to fix the language in the last 30 years.

> The Ariane 5 explosion was not a programming error, it was a testing and specification error.

What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.

It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening.

> What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.

That's immensely different actually ... One is undefined behavior, the other is defined but crash. In the first case the problem can stay unnoticed almost forever until somebody exploits it. In the second case, if you actually test and cover your code, you will catch the problem.

Short for using a proof technology (which Ada enables and makes easy because of the large palette of constraints you can add on types), there is NO language that can statically guarantee that your program won't crash at runtime. Yes, Ada is not special in that regard. What Ada guarantees is that it will crash, so you can actually catch those kind of bugs in testing. Also nowadays you can use SPARK Ada to formally prove your code correct. https://en.wikipedia.org/wiki/SPARK_(programming_language)

Blaming on the language what is actually bad testing/architecture is pretty unfair.

> It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening.

Do you have any source for that ? From my sources, Ada got less and less traction because of various reasons, one of them being the price of compilers at the time. I have never seen anybody saying that it was because Ada was "not safe enough", and even today it stays one of the safest languages out there in many aspects.

> Blaming on the language what is actually bad testing/architecture is pretty unfair.

I think we can both agree that a SEGFAULT and an unhandled CONSTRAINT_ERROR lead to program termination.

Your right in that at least Ada raised a CONSTRAINT_ERROR. But -- the cause for a CONSTRAINT_ERROR and a SEGFAULT in this case are the same: bad handling of inputs to a function.

So in this case the results would have been the same as well. In either case it comes down to design and proper handling of inputs.

So I don't buy your argument that it is different because of undefined behavior vs. defined behavior. Ada 83 had undefined behavior, too. It's just that Ada coders (well the good ones) knew to avoid it.

> Do you have any source for that ? From my sources, Ada got less and less traction because of various reasons, one of them being the price of compilers at the time.

Having worked in a Large Defense Corp(TM) during the height of the Ada popularity, it became pretty clear that the cost of a compiler for a $100mm program wasn't really the issue.

The GNAT Ada compiler came out in 1995, and I know smaller defense contracts used that as a viable solution to write software.

The primary issues with Ada were:

1. Ada was oversold and underperformed. The Arianne-5 was the kind of tragedy that Ada was supposed to prevent. Interfacing with external systems was a pain. Tooling was a pain. The resulting executables were HUGE at the time.

And then the development itself was expensive. Towards the end of my time writing Ada, our group was coding at the rate of 2 lines of Ada code / developer hour. Compiling took hours, running and testing took hours, etc. So a 20 line code change might easily result in 10 hours of a compiling/testing cycle.

2. No code reuse across defense contractors. Ada didn't have a package manager at the time, and while there were software libraries, there weren't a lot of them. Not like the C/C++ or later the Java world would have. So if you needed something, most likely you had to write it from scratch.

3. Java got popular around 2000ish and showed what a great software ecosystem looked like. Around 2005ish most new successful defense development was on java.

> What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.

That's completely wrong. It was an integer overflow. One that could not happen on Ariane 4 but because of different hardware specs. But that was only the end of the chain of fails that lead to the crash.

Ada is of course completely able to handle such a problem. But the programmers evaluated this and consciously decided not to handle it for performance reason and because it shouldn't happen anyway. But it could happen, just only on the Ariane 5.

Sorry to be blunt but I don't think you know as much as you think you do. You should read up more on the incident. You could even read the post mortem report. It is available on the net.

in 90's single core golang probably won't be invented the way it is today :-p

> But nowadays it already feels outdated on arrival

Why? What do you prefer?

That's certainly an opinionated opinion but Go feels like dragging C half-way to the 21st century. But unfortunately not all the way.

Besides the very good concurrency support it doesn't feel much different than a polished and somewhat modernized C.

Of course, depending on what you want that will be considered a feature not a bug. There's a reason so many C programmers jumped on it because even hardcore C programmers couldn't really ignore the language anymore.

Also look at the project management. The drama about the package manager was hilarious bad PR. I wouldn't want to invest too much time into a programming language that can't even agree on a package manager and needs 4 different tries to arrive at a solution with potential security implications.