Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Systems Programmers Still Use C (2006)

bitc-lang.org

Post reply on HN
Print view View original

11–20 of 64 posts

Re: Why Systems Programmers Still Use C (2006)

#11

Post by eli_gottlieb »

javascriptlol wrote: post #9

The problem with systems design is that it's all so complex. Multitasking has become an excuse to run everything as some absurd daemon. Badly designed hardware has to be papered over with undocumented binary drivers. Everything is optimised for throughput benchmarks, so we get warm ups and unpredictable pauses visible to the user. And it's all full of security holes. The plain truth of the matter is that none of thes…

But that would break the backwards compatibility with previous systems and architectures. The markets can't have that.

Re: Why Systems Programmers Still Use C (2006)

#13

Post by chipsy »

moonchrome wrote: post #4
alpad wrote: post #2

Interesting article, but he misses the right answer: if it isn't broken, don't fix it. C may not be the easiest language to learn, but you wouldn't want newbies messing with systems programming anyway. Higher level languages give you a more abstract view, but when you are doing systems programming that's not what you want, you need to be in full control. Only C gives you precise control of what the machine is doing a…

>You don't want a garbage collector to kick in unexpectedly, you don't want data structures to be allocated in mysterious ways. 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 programmi…

I would agree and would elaborate that the major weaknesses of C are a combination of build system issues and an overly weak type system.

It wasn't realistic to have the whole compile process done in memory in the early 70's, and OS virtual memory wasn't realistic either; but we've long surpassed those concerns, and that means that all the thinking about the program namespace, modules, linking, pre-processing, etc. is worth re-evaluating.

As well, we can do better static checking now, without including any notion of GC; in an imperative execution model, leakage of memory, handles, processes etc. remains orthogonal to type safety. C has heavily bottlenecked program control logic from the beginning - a callstack, looping constructs, etc. - and allowing some equivalents to exist in its data structures would make user code tremendously more reliable.

These changes, often paired with some more attention to concurrency, show up in all the newer system language designs - D, Go, Rust, Clay, BitC, etc.

Re: Why Systems Programmers Still Use C (2006)

#14

Post by CJefferson »

moonchrome wrote: post #4
alpad wrote: post #2

Interesting article, but he misses the right answer: if it isn't broken, don't fix it. C may not be the easiest language to learn, but you wouldn't want newbies messing with systems programming anyway. Higher level languages give you a more abstract view, but when you are doing systems programming that's not what you want, you need to be in full control. Only C gives you precise control of what the machine is doing a…

>You don't want a garbage collector to kick in unexpectedly, you don't want data structures to be allocated in mysterious ways. 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 programmi…

Anyone who tries building a better C (for example Go) seems to end up going "too far", and as well as fixing the things you mention, ends up adding garbage collection, and various other things which are not suitable for very low level systems programming.

I teach C, and I would love a "cleaner C" mode, which just got rid of lots of the bizareeness of C, several of which you mention. The fact that many compilers will warn with '-Wall' about code which is clearly incorrect, but due to the rules of C they cannot simply reject, is irritating.

Re: Why Systems Programmers Still Use C (2006)

#15

Post by tmurray »

javascriptlol wrote: post #10

Also, this paper suggests that the answer to multi-tasking problems is to move the complexity out into the language. It's funny how PL researchers will always spin the situation so that it demands more PL research. If we're really moving into a many cores future as people suggest, then we should have architectures that give each application a dedicated core. No context switching. Of course, you'd need a simple system…

"If we're really moving into a many cores future as people suggest, then we should have architectures that give each application a dedicated core. No context switching."

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

Re: Why Systems Programmers Still Use C (2006)

#16

Post by ehsanu1 »

javascriptlol wrote: post #9

The problem with systems design is that it's all so complex. Multitasking has become an excuse to run everything as some absurd daemon. Badly designed hardware has to be papered over with undocumented binary drivers. Everything is optimised for throughput benchmarks, so we get warm ups and unpredictable pauses visible to the user. And it's all full of security holes. The plain truth of the matter is that none of thes…

The problem with that is "Worse is Better". And there's just so much momentum behind current technologies, that switching seems almost unimaginable to most. Can you imagine not having Unix-like systems, and not being able to use C and all the languages built around that ecosystem?

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

Re: Why Systems Programmers Still Use C (2006)

#17

Post by javascriptlol »

tmurray wrote: post #15
javascriptlol wrote: post #10

Also, this paper suggests that the answer to multi-tasking problems is to move the complexity out into the language. It's funny how PL researchers will always spin the situation so that it demands more PL research. If we're really moving into a many cores future as people suggest, then we should have architectures that give each application a dedicated core. No context switching. Of course, you'd need a simple system…

"If we're really moving into a many cores future as people suggest, then we should have architectures that give each application a dedicated core. No context switching." 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 eviden…

Why would you be moving data between cores? I'm talking about an arrangement where each core is dedicated to a single program. No sharing of memory, even via the kernel. Each hardware devices talks to a single core only. Multiplexing of hardware would be done in.. hardware. For all intents and purposes the "core" could be out on the network.

All this throughput nonsense is benchmrk lies. Websites are not as a general rule highly responsive. They have huge variability in response times. Who cares if it costs a bit more to run the system if it means having a nice predictable system built for simplcity and safety from the ground up?

Re: Why Systems Programmers Still Use C (2006)

#18

Post by javascriptlol »

ehsanu1 wrote: post #16
javascriptlol wrote: post #9

The problem with systems design is that it's all so complex. Multitasking has become an excuse to run everything as some absurd daemon. Badly designed hardware has to be papered over with undocumented binary drivers. Everything is optimised for throughput benchmarks, so we get warm ups and unpredictable pauses visible to the user. And it's all full of security holes. The plain truth of the matter is that none of thes…

The problem with that is "Worse is Better". And there's just so much momentum behind current technologies, that switching seems almost unimaginable to most. Can you imagine not having Unix-like systems, and not being able to use C and all the languages built around that ecosystem? 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 everyth…

Thanks for the link. I will check this out later.

>Can you imagine not having Unix-like systems, and not being able to use C and all the languages built around that ecosystem?

Yes! Charles Moore has been essentially living this since the 1970's. No many have his level of courage though.

Re: Why Systems Programmers Still Use C (2006)

#19

Post by rntz »

alpad wrote: post #2

Interesting article, but he misses the right answer: if it isn't broken, don't fix it. C may not be the easiest language to learn, but you wouldn't want newbies messing with systems programming anyway. Higher level languages give you a more abstract view, but when you are doing systems programming that's not what you want, you need to be in full control. Only C gives you precise control of what the machine is doing a…

You misunderstand his argument. He's not arguing that we should replace C with "higher-level languages" that don't give you precise control of the hardware; in fact, he bemoans the fact that the PL community at large seems interested only in such high-level languages. Nor is he complaining that C is hard to learn (I'm not sure where you got that impression). In fact, the paper mostly takes for granted that C needs to be replaced, and discusses the challenges in doing so, which may be why you assumed that BitC is (was, really) just another typical research-community high level programming language project.

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.

Re: Why Systems Programmers Still Use C (2006)

#20

Post by jedbrown »

javascriptlol wrote: post #17
tmurray wrote: post #15

Earlier quoted context omitted.

"If we're really moving into a many cores future as people suggest, then we should have architectures that give each application a dedicated core. No context switching." 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 eviden…

Why would you be moving data between cores? I'm talking about an arrangement where each core is dedicated to a single program. No sharing of memory, even via the kernel. Each hardware devices talks to a single core only. Multiplexing of hardware would be done in.. hardware. For all intents and purposes the "core" could be out on the network. All this throughput nonsense is benchmrk lies. Websites are not as a general…

You need an event-driven system because the number of "tasks" rarely matches the number of physical cores available. One tried and true, fault-tolerant event-driven interface is provided by the kernel: processes (and threads). It has interfaces for binding to NUMA regions and such.

Any system you design will have to tackle a lot of the hard problems that kernels deal with. Now maybe you have a simpler system in mind, but it has to be drastically better for anyone to consider giving up binary compatibility.

Post reply on HN