Well, there is also the difficulty that there has not been, save Ada, a serious and concerted effort to replace C and C++ for so many of the things that they are used for. Except for Ada, no other modern language is suitable for writing things like kernels, drivers, emulators, etc; except for Ada, basically all modern languages are dependent on garbage collection.

So if you want to complain about C, remember that the only serious alternative is and has been Ada, and ask yourself why you're not using Ada, why operating systems and window managers, mupen64plus and Wayland, et cetera don't use Ada, and the truth is: people like C more than Ada.

Ada is the anti-C++. It's the answer to every criticism. It's also basically unheard of outside of situations where people really, really need safety cf. airline industry. In fact most of the people who complain about C++ would never even consider Ada. The author of the article seems to be unaware it even exists, which says a lot.

The takeaway is that safety is overrated, consistency is overrated, reliability is overrated, because if we really cared about these things... we'd use Ada. And we don't, because "Ada is annoying!".

There is another attempt at it. That language has been in development for a few years and is almost ready. Rust combines the best features of C and functional programming and through a very clever pointer system manages to eliminate race conditions, null pointers and dangling pointers at compile time. It has a powerful type system and smart type inference. It's possible to have some memory be garbage collected, but by default it isn't so it can be used for tasks that prohibit garbage collection. The compiler ensures that freed memory will never be accessed. It's built for modern parallel hardware and offers tons of concurrency features, like lightweight tasks, actors, async, etc. Its structs are compatible with C and Rust can integrate seamlessly with C code and librairies. It compiles to native using LLVM. It's backed by a major non-profit, Mozilla. It's a fantastic project and it seems to have all the right cards to be the perfect alternative to C++.

Check it out. My only disappointment (and the reason why I'm not using it seriously at the moment) is that because the language is still in development, it changes extremely fast and 80% of the documentation online is wrong and won't compile. Even the official documentation contains a lot of outdated syntax. Hopefully that will change once the language reaches version 1.0, in the next 3-6 months.

I haven't tried Rust, but what about considering Python for embedded targets?

Is it that the language won't fit, or us embedded people are just too masochistic to find something easier.

You can use something like py2llvm to compile using the same system that Rust uses and get fairly good performance. I am working on this project actually.

Rust[1] is aimed squarely at this use case. The GC and runtime are optional. A toy kernel[2] and Linux kernel module[3] have already been written in it. The language is young and still unstable, but it's being designed by veteran C++ programmers with the goal of using it for a safer, faster, more maintainable successor[4] to the browser engine in Firefox. Worth checking out!

[1] http://www.rust-lang.org/

[2] https://github.com/charliesome/rustboot

[3] http://thechangelog.com/rust-ko-a-minimal-linux-kernel-modul...

[4] https://github.com/mozilla/servo

"Except for Ada, no other modern language is suitable for writing things like kernels, drivers"

I think the existence of Lisp machine OSes is a prominent counterexample to this claim. I understand your point, and I would not try using modern Lisp compilers to write an OS, but there is nothing about Lisp that makes it a bad language for low-level code.

> Well, there is also the difficulty that there has not been, save Ada, a serious and concerted effort to replace C and C++ for so many of the things that they are used for.

Except Ada is older than C++, so it cannot be an effort to replace it.

Around the time C was still UNIX only we also had Modula-2.

An advantage C and C++ have over many other languages is that they are part of the standard tooling from OS vendors.

The only way to get people to use other, safer systems languages, is when OS vendors push for them.

For example, Objective-C would be dead if it wasn't the only language to fully explore iOS and Mac OS X capabilities.

Sure you can write bindings in other languages, but Objective-C will remain the language to go to.

The same with any language that would be targeted to replace C or C++. Without OS vendor support, no chance.

> For example, Objective-C would be dead if it wasn't the only language to fully explore iOS and Mac OS X capabilities.

It's a symbiosis. Cocoa would be much worse and harder to program if it wasn't for Objective-C.

Objective-C gives a stable, object-oriented ABI without requiring a VM.

Objective-C runtime is as powerful and dynamic as Python or JavaScript, e.g. you can replace any method of any instance of a class, even ones you haven't defined yourself, and Cocoa uses this for UI bindings.

I haven't said otherwise, just that hadn't Apple not decided to push it, the language would be dead.

This was the reason behind the Cocoa Java support in the early versions, as Apple was not sure if mainstream developers were willing to pick up Objective-C, even with them pushing for it.

It is funny, from what I understand one of the old complaints about Ada was how verbose it was in comparison to C at the time.

Comparing modern Ada to modern C++, C++ has tried its best to equal Ada in verbosity, although C++11 fixed a good deal of C++03's excesses.

From what I can tell, Ada is still missing a good way to do really primitive bit operations in a simple matter. Then again, bit ops destroy Ada's type safety, so I can see why they were made difficult. Still, if one needs to start poking around the individual bits of arbitrary data, C makes that easy-ish. (I mean it could be a lot better, it isn't hard to come up with a better syntax than C's for bit-wise access)

But everything I have read about the latest Ada spec makes it seem like a nice language.

I also believe another problem is that Ada has always been a rather academic language in many ways. Where as for the longest time no one in the C community really talked about pointer aliasing (and I'm guessing if you took a random cross sample of programmers in the late 80s/90s, many of them wouldn't know what the term even meant), Ada requires you know about pointer aliasing just to use pointers at all!

Then there is the fact that the language syntax is defined in BNF, and the main reference pointed to for Ada is the official reference manual. On one hand, hey awesome, the language spec is freely available for all! On the other hand, it is about as readable as any other official spec. The experts who can easily understand the spec end up just pointing to it (after all it is so easy for them to read) and thus simplified explanations don't get created.

> In fact most of the people who complain about C++ would never even consider Ada.

If I had tooling and other people in my group had more familiarity with it, I sure as heck would. Holy crap am I sick and tired of being limited to just straight C and a very tiny subset of C++. And 90% of the new stuff in C++ is not targeted at the embedded market (quite the opposite!) where as Ada has stayed closer to its roots.

It's also difficult to find a compiler, programming tutorials, or a community for. I think there are a LOT of reasons programming languages are chosen by developers and that most of those reasons aren't all that rational or well informed.

Good compiler support, a wealth of documentation, an active community, and a number of well-maintained libraries are all rational and informed reasons to choose a programming language. Network effects matter.

> Unix is the reason C is popular and Windows is the reason C++ is popular.

I never understood why people say C++ is popular because of Windows.

C++ was already popular before Windows mattered.

My first C++ applications were targeted at MS-DOS, back in the days most PC compatibles were still sold with 1 MB of RAM and almost no one has Windows installed.

Before Java was created, many of us were already doing C++ with CORBA in commercial UNIX systems.

Microsoft compilers only mattered to us around the time Windows NT started to enter the enterprise and the 32 bit version of Visual C++ was introduced.

C++ got popular due to its almost 100% C compatibility and as with C, UNIX also contributed to its spread in the enterprise, not Windows.

I think the actual argument was "C/C++ is not great, but others are worse". :)

Pretty much all languages have handy OS API calls, usually a lot more portable than C/C++ - so that's not a compelling reason.

Yet somehow a lot of new code is still written in C/C++: Redis, Memcached, Nginx, MongoDB, Android, Chrome etc

I am speaking from experience here. The only language I have used where this does not apply is F#, and only if you count .NET support.

I love CL, I never want to go back to C or C++, but the most annoying aspect is the lack of good system call support. Sure SBCL has a posix compatibility layer, but anything beyond basic system calls becomes a drag. In the worst case you wind up having to write a C function to wrap a system call just to expose an easier-to-use interface for the FFI. It is a complete mess, and it becomes a maintenance nightmare.