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

21–30 of 64 posts

Re: Why Systems Programmers Still Use C (2006)

#21

Post by psykotic »

javascriptlol wrote: post #18
ehsanu1 wrote: post #16

Earlier quoted context omitted.

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.

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

I'm an unbounded admirer of Charles Moore. But courageous? He's a software solipsist. His approach is certainly bold but I doubt he sees himself as courageous.

Re: Why Systems Programmers Still Use C (2006)

#22

Post by javascriptlol »

jedbrown wrote: post #20
javascriptlol wrote: post #17

Earlier quoted context omitted.

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,…

You are completely misunderstanding me. I am not saying "let's all move to this new utopian system". I am suggesting that we move away from the idea of making universal systems entirely. Write software that is small enough that complete rewrites can be accomplished without trouble. The current situation is to build ourselves a problem that gets harder and harder to undo as time goes on.

You can't call something that's been around for less than 100 years "tried and true". I'm not saying we can't have "virtual CPUs" for tasks that can handle a performance hit. But it is becoming an unavoidable impediment. "Simple" doesn't mean "easy". It means predictable, small and undoable. The exact opposite to where we are heading.

Re: Why Systems Programmers Still Use C (2006)

#23

Post by javascriptlol »

psykotic wrote: post #21
javascriptlol wrote: post #18

Earlier quoted context omitted.

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.

> Yes! Charles Moore has been essentially living this since the 1970's. No many have his level of courage though. I'm an unbounded admirer of Charles Moore. But courageous? He's a software solipsist. His approach is certainly bold but I doubt he sees himself as courageous.

Call it bold or courageous. He's doing something few are willing to do. I'm not saying he's a hero in the same sense as a soldier or anything here, but he's worth 100x more than the drones who just keep piling mess upon mess without even being able to admit what they are doing.

Re: Why Systems Programmers Still Use C (2006)

#24

Post by smcdow »

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…

How do you handle DMA and other I/O in your system?

Re: Why Systems Programmers Still Use C (2006)

#25

Post by smcdow »

edwinnathaniel wrote: post #5

These days Java seems to become one of the choices to do system programming in a different area/level: HBase, Hadoop, Cassandra, GWT tools, MQ, App Servers (Jetty, Tomcat, GlassFish, etc), EhCache. Unless if people categorized the above software as non-system-programming.

Curious as to how you would set up a DMA transaction in any of those languages? If you're doing system programming, you'll need to do DMA.

Re: Why Systems Programmers Still Use C (2006)

#26

Post by quanticle »

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…

>Only C gives you precise control of what the machine is doing all the time.

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.

Re: Why Systems Programmers Still Use C (2006)

#27

Post by jedbrown »

javascriptlol wrote: post #22
jedbrown wrote: post #20

Earlier quoted context omitted.

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,…

You are completely misunderstanding me. I am not saying "let's all move to this new utopian system". I am suggesting that we move away from the idea of making universal systems entirely. Write software that is small enough that complete rewrites can be accomplished without trouble. The current situation is to build ourselves a problem that gets harder and harder to undo as time goes on. You can't call something that'…

I write a lot of code that runs in funny environments like the Compute Node Kernel running on Blue Gene systems, with offset-mapped memory (no TLB) and no over-subscription. It's fantastic for reproducible performance, but it's a specialized environment and people want to do things like run Python (as "glue" for some scientific applications) which needs dynamic loading. Since all IO is exported to separate IO nodes, and due to file system consistency semantics, dynamic loading is a tremendous bottleneck. This has escalated to the point where people burn a quarter million core hours to load Python (plus C extension modules) once on a large machine. To really solve the scalability problem, we needed to make dlopen() avoid touching the file system (by patching ld.so and implementing the POSIX file API with collective semantics served over the fast network).

The point here is that there are good reasons to want to use different systems together and then you end up putting in lot of effort working around the limitations of the specialized environments.

Re: Why Systems Programmers Still Use C (2006)

#28

Post by andrewflnr »

javascriptlol wrote: post #18
ehsanu1 wrote: post #16

Earlier quoted context omitted.

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.

You mean this one? http://en.wikipedia.org/wiki/Charles_H._Moore

Can you give some more detail? What does he use?

Re: Why Systems Programmers Still Use C (2006)

#29

Post by tmurray »

javascriptlol wrote: post #22
jedbrown wrote: post #20

Earlier quoted context omitted.

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,…

You are completely misunderstanding me. I am not saying "let's all move to this new utopian system". I am suggesting that we move away from the idea of making universal systems entirely. Write software that is small enough that complete rewrites can be accomplished without trouble. The current situation is to build ourselves a problem that gets harder and harder to undo as time goes on. You can't call something that'…

It sounds like you're basically proposing Plan 9--lots of very small, single-purpose components with one standardized way of passing data between them used across the entire system.

Also, you can ask a lot of people to give up binary compatibility and be okay, but asking people to give up source compatibility and change applications is a much, much harder pill to swallow. Specialized environments (like the syscall-shipping CNK on Blue Gene like jedbrown mentions) are usually seen as something to work around because they are impediments to productivity. A more robust system wouldn't be considered useful if everyone has to start from scratch.

Re: Why Systems Programmers Still Use C (2006)

#30

Post by andrewflnr »

We are starting to get alternatives, though. Besides Rust and D, there are Clay (http://claylabs.com/clay/), ATS (http://www.ats-lang.org/), and Deca (http://code.google.com/p/decac/). I'm sure there are more. I unfortunately haven't had time to play with them, and they're in various stages of development. But at least people are thinking about improving systems programming.
Post reply on HN