3 ms·

Off the top of my head, big important projects written in C, which are still actively developed: * Linux * GNU * Apache * Ruby * Python * nginx * mysql

Off the top of my head, big important projects written in C, which are still actively developed: * Linux * GNU * Apache * Ruby * Python * nginx * mysql * posgresql * Redis * VMWare * OpenSSL * Almost everything "embedded" Because C allows extreme control and performance. Anecdotally, a lot of people write in higher level languages, then rewrite critical bits in C for that speed boost. In many cases they just start at C if they know it requires certain levels of performance, for instance code on massive super computers or super low latency communications packages.

st3fan 15y ago
'GNU' is not a project. At least not like the others in your list.
- Turing_Machine 15y ago
  Sophacles probably meant http://www.gnu.org/software/software.html#allgnupkgs http://www.gnu.org/software/software.html#allgnupkgs Looks projecty to me. :-)
- sophacles 15y ago
  Nor is one about embedded systems. The core GNU tools are written in C and actively maintained, and are commonly referred to as the "GNU project". I'm not sure why you are pointing this out.
octopus 15y ago
As a side note a lot of codes ported to C for running on HPC clusters will end up re-implemented in Fortran (I'm talking about Fortran 95/2003/2008 ... ).
Aedan 15y ago
I'm aware of almost all of that, but my point wasn't about things already written in C, I'm talking about why keep writing in C. Extreme control and performance are unique traits of C? Being a relic of the past, it lacks greats thing modern languages take for default (like, I don't now, memory management, for example). That's where my point was heading. Can't new languages in the multicore age address this issue in a more elegant, modern and less "protocolary" way?
- sophacles 15y ago
  When every bit of speed and space management actually counts, C (or it's derivatives like C++ or objective C) are still king. Half of those above projects were written when JVM, .Net and python/ruby/etc were mature widely used solutions. Think about what a gc pause would do to an OS - it could kill performance for every single process on the system, cause issues with input buffers overflowing, and other related issues. A microsecond here and there in call latency may not matter most of the time, but in thousands of syscalls or in low level network processing have large cumulative effects. Don't get me wrong, I love my high level languages and modern GC runtimes, but there are days and places when microseconds and bytes still matter, and for those, I still grab C. Just like the nailgun hasn't fully replaced the hammer, or the vacuum hasn't fully replaced the broom, there is a good reason C still exists and finds acceptance. Maybe Go or Rust will start to creep even more into the C space than JVM etc already have, but I really don't see it fully going away, it is just too useful and a well understood proper tool for some jobs.

st3fan 15y ago

'GNU' is not a project. At least not like the others in your list.

Turing_Machine 15y ago
Sophacles probably meant http://www.gnu.org/software/software.html#allgnupkgs http://www.gnu.org/software/software.html#allgnupkgs Looks projecty to me. :-)
sophacles 15y ago
Nor is one about embedded systems. The core GNU tools are written in C and actively maintained, and are commonly referred to as the "GNU project". I'm not sure why you are pointing this out.

octopus 15y ago

As a side note a lot of codes ported to C for running on HPC clusters will end up re-implemented in Fortran (I'm talking about Fortran 95/2003/2008 ... ).

Aedan 15y ago

I'm aware of almost all of that, but my point wasn't about things already written in C, I'm talking about why keep writing in C. Extreme control and performance are unique traits of C? Being a relic of the past, it lacks greats thing modern languages take for default (like, I don't now, memory management, for example). That's where my point was heading. Can't new languages in the multicore age address this issue in a more elegant, modern and less "protocolary" way?

sophacles 15y ago
When every bit of speed and space management actually counts, C (or it's derivatives like C++ or objective C) are still king. Half of those above projects were written when JVM, .Net and python/ruby/etc were mature widely used solutions. Think about what a gc pause would do to an OS - it could kill performance for every single process on the system, cause issues with input buffers overflowing, and other related issues. A microsecond here and there in call latency may not matter most of the time, but in thousands of syscalls or in low level network processing have large cumulative effects. Don't get me wrong, I love my high level languages and modern GC runtimes, but there are days and places when microseconds and bytes still matter, and for those, I still grab C. Just like the nailgun hasn't fully replaced the hammer, or the vacuum hasn't fully replaced the broom, there is a good reason C still exists and finds acceptance. Maybe Go or Rust will start to creep even more into the C space than JVM etc already have, but I really don't see it fully going away, it is just too useful and a well understood proper tool for some jobs.