Why Systems Programmers Still Use C (2006)

template<class I, class C> void sort(I a, I b, C cmp);

Now, the concepts aren't 1:1; Haskell for obvious reasons doesn't represent the idea of operating on storage directly, so you can't have an iterator and need to return a "new" list. C++ makes you write out the types you are parametrizing instead of getting it implicitly. And there are no doubt some really good arguments why Haskell is terser and clearer than C++.

But this isn't one of them. Come on.

Database engines highlight some of the reasons that Java is a poor systems language relative to C/C++. High-performance database engines these days are usually bottlenecked by memory I/O performance and efficiency, or storage I/O if you under-provision the machine resources for the workload. This is why you see I/O optimizations applied to in-memory databases, for example. Java may be fast at many things, but it is much slower than C/C++ for codes that are bound by memory performance and efficiency. You have to start doing very awkward things in Java to even come close to what comes naturally in languages that explicitly manage memory behavior and structure. As someone who has written a lot of database engine-y code in both C++ and Java, the difference in absolute performance for nominally equivalent code is not small, and is generally easier to achieve in C++. So for low-level performance-oriented systems, there is a pretty strong bias toward C++, particularly now that there is a lot of experience trying to implement the same systems in Java.

For performance sensitive codes, systems programming is really about carefully managing resources to optimize for characteristics of the system. C makes this very easy because it exposes all of it. To the extent that CPU architectures are increasingly bound by memory performance, I would not be surprised to see C++ supplanting Java for certain purposes.

This makes sense. Java was designed more as an application language that works well for codes that are unlikely to make heavy use of the memory system. Its popularity and generality has caused it to be widely used but that does not always make it a good choice outside of its original design case (see also: Perl).

So writing a JVM is systems programming. Writing a Java-based data store is not, even though other stuff then sits on top of the store.

Probably the case, networked services represent an area where performance is at least somewhat a concern, but BitC is trying to address situations where one is writing a memory allocator, not building a server on top of a GC'd language known for having sloppy memory usage.

The fact is, C is broken, and we all suffer every day because of it. From a security perspective, C is a nightmare. It is not just an unsafe language (in the PL sense of having undefined behavior), but a rampantly unsafe language. Null pointers (which C.A.R. Hoare famously called his "billion-dollar mistake"), buffer overruns, unrestricted pointer arithmetic, arbitrary casting, manual memory management; all of these are the cause of innumerable bugs in real code, often critical security vulnerabilities. C is also not the nicest of languages to code in. It is terribly verbose. There is no good way of writing generic code in it. The preprocessor is a gigantic ugly hack. Writing portable C is a pain in the ass, and building it portably is doubly so.

The worst part is, we know reasonable ways to solve most of these problems. In many cases we have known them for decades. Unfortunately, how to best integrate these solutions into a language and still keep it useful for systems programming was (and is) an open problem. I can't speak for Shapiro, but as I see it this is what BitC was aimed at doing.

All of that (and everything else C is attributed with) can be accomplished without using an arcane preprocessor/include system and you can have niceties such as a saner type system, generics/macros, namespaces, etc.

C is a language stuck with the design decisions that reflected the programming environments in the 60's and 70's but make absolutely no sense in modern context and now we are just stuck with it because of inertia.

Maybe in 1979, it did. Modern C compilers alter and modify code quite radically, to the point where it's quite difficult these days to go back from optimized assembly back to the original C code. These days, C gives you a good illusion of control, but all too often, C programmers mistake illusion for reality.

His answer was of course EROS.

Microsoft explored Singularity.

Some of his colleagues went and wrote Go as a systems language (if not a kernel-side language).

But if you're looking for a replacement for the entire software stack we use today, one that tries to shun complexity (20k LOC for everything from kernel to common GUI apps), here you go: http://www.vpri.org/pdf/tr2011004_steps11.pdf

More info (see previous STEPS reports): http://vpri.org/html/writings.php

(Although having been a voyeur of his work for over a decade now, I'm sure he would be quick to point out that much of EROS was based on formalising ideas from GNOSIS and KeyKOS, and the work of Hardy, Franz, Landau et al. over 20-30 years earlier.)

BitC evolved out of a need to prove that the implementation of the confinement mechanism (prototyped in EROS) matched the model (proven in his PhD thesis), and so the CapROS system (built in BitC) was born (well that plus some architectural changes based on lessons learned from EROS). From that perspective it's much more than just another systems programming language - it has a definitive purpose to advance the state of the art in practical and theoretical computer science. (FWIW, they never did accomplish this goal [http://www.bitc-lang.org/docs/bitc/bitc-origins.html]).

You probably don't want that either because the cost of moving data between cores will be so high from both a performance and a power consumption POV. The days of free coherency between cores will eventually come to an end; you can already see evidence of that in multi-socket Intel and AMD machines (if you try to ignore the NUMA nature of memory, you swamp the link between sockets and perf tanks in a variety of apps).