What do other languages offer when it comes to infrastructure technology that could indicate its advantage over C in the future?

Question

I have been going through interview questions and I saw one which made me stop and think for a while. It starts with a quote and asks about your interpretation and whether you agree or not.

"For infrastructure technology, C will be hard to displace." - Dennis Ritchie

From a bit of background reading you can find that he was the mastermind behind C language as well as the UNIX OS. At the time it was a phenomenal improvement and at the forefront of cutting edge techniques. I feel that C++ and Java are becoming increasingly popular languages, but C will always be an important language.

What do other languages offer when it comes to infrastructure technology that could indicate its advantage over C in the future. On a side note, does anybody know which year this quote was made? I just want the opinions of people who use these languages a lot, I myself use python language and would love to learn a bit more about the framework around C and it's importance firsthand.

Answer 1

For all of its advantages, C is an unsafe language; it lacks many of the safety guarantees that other languages have, such as:

• Array bounds checking
• Type safety
• Garbage collection (to avoid memory leaks)

Despite these disadvantages, C is "closer to the metal," making it a very high-performing language, and offering real-time performance guarantees. This is why it is often used to write kernels and device drivers, where performance really matters.

In reality, the most important part of an operating system (it's "kernel") is quite small; it can be written in C, while most of the other parts of the OS could be written in a more "modern" language.

Answer 2

You have to understand why C is useful for low-level systems, its mainly because it offers a compromise between how the computer works, and how humans can understand the same. Assembler would be a better systems language, if us meatbags could understand it and be productive in it.

So the key is that the level of abstraction fits a sweet spot between not slowing things down from the computers perspective, and keeping things understandable from ours.

In keeping with this, a hypothetical new language would do exactly the same things as C, with as few abstractions.

There are some things that the compiler, or tools could help us with - though, note some tools like, say garbage collection, are useful to us and theoretically make the system work more efficiently, but in practice slow things down and make them unpredicatable and sometimes more difficult to work with. I can imagine the areas that an improved C would be RAII (I love this in C++, it is awesome, the compiler puts your de-allocation routines in where you would put them!), and a better string routines - making strings null delimited made sense when memory was very expensive, but in systems where we use 2 bytes per character, this limitation is no longer around. I'd have a string prefixed with a dword for length that should improve a lot of performance. Note I wouldn't go further than that - no referenced counting string classes or anything similar, and I probably wouldn't do "classes", though I would introduce some form of mini module that helps to encapsulate related code (and compiler-generated routines like for RAII). You might want to have some memory location routines built in, that helps with CPU cache coherency, and maybe a primitive form of threading - not so people can abuse it by spawning off threads and locks willy-nilly, but so they have to think what they are doing.

I think the latter aspect is important in C, while we can add a load of features to make life easier for the programmer, they all introduce overhead, that gets compounded by people creating more abstractions using those abstractions where you end up with seriously in-efficient code, that people use because its "fast enough". Its never fast enough for low-level systems programming :)

Answer 3

For infrastructure tasks (device drivers, embedded systems, compression algorithms, encryption algorithms, core OS functions) C will remain unbeatable.

In these areas type safety is a nuisance you need to be able to address arbitrary areas of memory, you need twiddle bits in data that may not be defined as a bit twiddling type.

Ada and native assembly do actually compete in this space and are both viable alternatives.

Java etc. is completely unfeasible as these low level functions use structures to pass data to and fro, Other than "walking" along a buffer and laboriously pulling out each data element Java does not handle structures.

C++ is possible but does not really confer enough advantages is these areas to justify the performance overhead, or, the "comprehension" overhead ( the language is just to complex for casual reading of code.).

So far the only candidate language which could possibly compete in this space is Google's "Go" but it is still relatively immature, and, many companies would be nervous about betting the farm on something from a major competitor.

Answer 4

C is the lowest common denominator and for some things, mainly glueing different languages together, you need just that. Only another language with straightforward translation to assembly could replace it here. And there is not much demand anyway, because the key infrastructure is already written in C and nobody wants to rewrite just for sake of using new language.

C++, containing C as it's subset, can be used anywhere C is, but has to be used with care because one must control where the ++ features may get and where not. Still it is now being used for things like writing micro-controller software and operating system kernels because of the added safety (mainly via RAII) and the improved performance of templates compared to "generic" C code taking void pointers.

D and rust are two languages written to advance on the safety while still containing C-compatible subset and allowing direct unsafe access where needed. Go ruled itself out of this set because it does not provide the unsafe part.