5

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.

  • 10
    Kinda depends what you mean by "infrastructure", doesn't it? – user16764 Aug 12 '13 at 19:03
  • 3
    What is your definition of infrastructure? Do you mean hardware access or what? – EL Yusubov Aug 12 '13 at 19:04
  • 2
    I think that if a language is going to displace C, the most important thing is not features or safety, but timeliness. For example, the PIC32MX came out in 2007; there wasn't even a C++ compiler for it until five or six years later. If you were a manufacturer, you get to choose two of: get to market ASAP, more sophisticated language than C, use fancy new chip features. – detly Aug 13 '13 at 0:40
  • I would guess that "Infrastructure" in this case is referring to the whole telecom branch, rather than general "close-to-the-metal embedded systems". Since AT&T Bell Labs was were the C story begun. – user29079 Aug 13 '13 at 6:55
9

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.

  • 20
    At sufficiently low levels (kernel, device drivers, etc) having garbage collection might be viewed as a bad thing. – Dan Pichelman Aug 12 '13 at 19:22
  • 1
    @DanPichelman: Exactly. – Robert Harvey Aug 12 '13 at 19:29
  • @DanPichelman: Indeed. This includes games on mobile phones, were garbage collection during gameplay is to be wholly avoided if smooth frame rates are desired. – Macke Aug 14 '13 at 5:59
  • @Macke: that's one option, another is to make garbage collection run really quick, e.g. to avoid complex object graphs. – Den Aug 22 '13 at 10:03
  • It should be noted that while garbage collector prevents unreleased resources to which you don't have reference any more, it can have related problem where forgetting to break some reference keeps a lot of objects alive. I am using a web app in python where I had to set the thread to restart every 10 requests, because it is leaking tens of megabytes in each request. – Jan Hudec Aug 23 '13 at 5:51
4

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 :)

  • 2
    By that reasoning, all features introduce overhead. It's a necessary consequence of doing anything. There's also an argument that experts solving the problems once in the language/libraries will be much more effective than people of varying experiences creating countless solutions for the same problem. These theoretical features will have no overhead versus good hand written solutions and much more compelling properties versus bad hand written solutions. I take your point of "never fast enough," but feel that the conclusion doesn't follow from the supporting statements. – Joel Aug 13 '13 at 12:56
  • 2
    sure, all features introduce overhead, its just that some introduce more than others and encourage even more layering on top - the problem there is that once you get a certain distance from 'the metal', efficiency becomes much less important to the programmer that's now working with ease of use. solutions. There is just a sweet spot (as always) between low-level efficiency and high-level ease that I think has to be quite close to the low-level. – gbjbaanb Aug 14 '13 at 18:51
4

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.

  • Well, C++ contains all of C with some minor differences, so you can use various subsets of C++ as appropriate to avoid overheads and take advantage of it's benefits. – Jan Hudec Aug 13 '13 at 6:31
  • 3
    Google Go can't compete in this space, because it hardcoded the garbage collector too deep. There is no "unsafe go" and without that you can't implement the lowest layers. – Jan Hudec Aug 13 '13 at 6:33
  • @Jan -- I agree you could not use it for device drivers, or, to implement a garbage collector (how can you implement a garbage collector in a language which has garbage collection?). However its good for compression/decompresion, interpreter implementation etc. Also its well within the capabilities of Pike et. al. to implement a non garbage collecting version for low level coding if they saw a need. – James Anderson Aug 13 '13 at 7:28
  • You can write compression/decompression in about anything with similar efficiency (heavily templated C++ probably being the fastest) and best language for interpreter implementation is said to be Haskell. And for virtual machines with JIT or at least computed goto runcores, Go is of no use, because it does not support calling random calculated addresses. – Jan Hudec Aug 13 '13 at 7:33
  • 1
    @MarcDefiant: It does not seem to allow to call that memory though. And it's the wrong way around. The unsafe part has to be built into the language, because you can build the safe part on the unsafe, but you can't build the unsafe part with just the safe part. – Jan Hudec Aug 13 '13 at 8:38
3

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.

  • There is the "unsafe" package that does allow unsafe access to "raw metal" (or, at least as raw as you get with C). – Vatine Aug 22 '13 at 15:01
  • @Vatine: But it does not really allow avoiding the garbage collector like it does in D and rust. And it is a library, which needs to be separately implemented and needs to use C or other lower level language. – Jan Hudec Aug 23 '13 at 5:45
  • At the moment, yes, although I can see Go becoming self-hosting in some sort of future. – Vatine Aug 23 '13 at 13:29
  • C is not a subset of C++. There is a lot of valid C code that's not valid C++. That's mainly due to the different handling of implicit conversions involving void* (as in Foo* p = malloc(sizeof(*p));), but C is also a lot more powerful than C++ when it comes to variable length arrays (as in void foo(int n, double (*bar)[n][n] {...}). – cmaster Jun 19 '15 at 20:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.