5 ms·

Why does anything need to replace C? It's been fine for years and still does exactly what it needs to do.

by flashm 11y ago

grabcocque 11y ago
The endless, eternal, continual stream of catastrophic security flaws in every C program of note begs to differ.
beering 11y ago
I think this is not a serious question, but I'll bite. We're paying a hefty price for C in the form of buffer overflows, memory leaks, slow development, and other problems and will continue to do so as long as we run software written in C. If we instead switch to a language that doesn't have these problems, then we'll come out better in the long run.
- flashm 11y ago
  It was slightly tongue in cheek - C is good at what it does, but I agree that there are plenty of good options going forward. I just don't think C will be 'replaced' across the board though, but I suppose that's obvious. Of the languages mentioned, I've only got experience with Go (which I use for APIs). Rust looks interesting though, I need to have a proper look at it.
- EliRivers 11y ago
  We won't come out "better". We'll have made a trade-off. For some situations, it will have been a trade-off that benefits. For others, it will have been the wrong choice. Just use the right tool for the job given the circumstances.
- arihant 11y ago
  These aren't problems of the language. These are a result of having a design choice of full programmer control. Having automatic cars is convenient and has its uses. But the argument that not using a manual cars will cause less road accidents is misinformed. It looks like that because common sense dictates that as it's easier to drive, more people will drive it easier. But usually the result is that now you have people on road who could not drive a stick! Some things are meant to be written in lowest level possible. Programming languages are tools and it helps us to have tools for entire spectrum of abstractions. Electronic screwdrivers haven't replaced manual ones in 2 decades. That's not how tools work. As far as direct comparisons go, these isn't any indication that raising the level of abstraction actually helps with more secure, bug-free code. Compare Java code written (in FOSS setting) with C code written in last 15 years. I bet you'd find C code more secure, more fast, more faster to refactor than a lot of Java code. So if Java was a systems language, would the world be better off if it replaced C? Probably no. Which shows that it's our infatuation with new shiny toys (languages like Go) that's driving our opinion rather than evidence.
  - jerven 11y ago
    C is like running around with scissors in your hand because it allows you to cut paper faster when needed. Yes, its true but it is also likely to cost your eyes. Java FOSS code is often faster, more secure, and a lot easier to reason about than equivalent C code. This is not really a language thing but a standard library thing. The use of char array with a null termination for human readable strings is a terrible 'C' ism. And glibc standard String struct would have saved us all a lot of (security) issues. The second is a community thing. Java uses defined behaviour to drive optimisation. C tends to use undefined behaviour to drinve optimisatio. The C case really trips programmers up. Most of these things are not actual technical but more social issues. Computers don't care, it is us humans who do.
    - z92 11y ago
      > Java FOSS code is often faster, more secure But uses significantly more memory and requires a VM. The VM probably is written in C, too.
      - pjmlp 11y ago
        There are AOT compilers for Java, some of them actually written in Java. The reference JVM uses a mix of Java and C++, with code being migrated from C++ to Java and replaced with intrisics in each release. Java 9 will bring Graal/Truffle plugins, which are a JIT compiler framework, written in Java.
      - jerven 11y ago
        > But uses significantly more memory and requires a VM. Do they really use more memory for equivalent code. e.g. Is jetty that much worse than apache? I don't really think so. Even if the intrinsic memory consumption of a java object is more than one for a C struct that does not mean it will in practice actually use more memory, or that it has too be that way due to unassailable theoretical grounds. See Realtime java for an example. > The VM probably is written in C, too. Historical reasons only. It could have been fortran or pascal. Its not that C is magical in its low level. There are a whole bunch of other options as well. C was easy to get and it came with the OS for many developers when computers became more accessible due to lower costs in the late 70's and 80's. C is slow is not an uncommon opinion among fortran programmers, for good reasons. In practice the C++ parts of the different JVMs are getting smaller each release. And there have been JVMs that are written in Java with a bootstrap interpreter in ASM. As an OS with just java and assembly. After all, the language is turing complete... Don't take me wrong Java is not some promised land without issues, its got plenty of those. I am just refuting the idea that just because it written in C it is fast claim. GCC/XLC/ICC are not magic, neither is HotSpot or Vuze or J9 or any other JVM system. In many ways C and Java are alike, crap languages introduced in a time when other, better alternatives where available. Only saved by industry adoption and decades of engineering work to make them fly. Rust is so interesting as it has industry attention and is also academically interesting as bringing something new to the programming world. (at least I am not aware of any pl with the borrow checker concept worked out).
damienkatz 11y ago
Agree. The unstated conclusion is nothing is close to being a C replacement. A good analysis of the languages anyway.
moonshinefe 11y ago
Because a large portion of massive security holes in recent history have been due to archaic C libraries that have security holes a-plenty. A lot of these issues that plague C don't happen in modern languages. It's 43 years old (times have changed), and while I'm sure C still has its places, I think it's time to come to terms with the fact that people suck at handling memory manually and making sure type conversions are safe & a host of other security risks. Other, safer languages can accomplish many of the same things C does these days. Again, I'm not calling for the end of C, but in a lot of situations, it's just asking for it now.
- cwoac 11y ago
  There is a slightly disingenuity here. "a large portion of massive security holes in recent history have been due to archaic libraries that have security holes a-plenty". The fact they are also C libraries is because that was the only real option of the time when they were written; rather like saying most car accidents were caused by black ones when the only option was a model T.
  - pjmlp 11y ago
    It is not true. Before C escaped UNIX there were other systems programming languages available.
    - ArkyBeagle 11y ago
      The manner in which it escaped Unix was through Microsoft and Borland, and I spent oodles of time evaluating other choices at the time. I could not get the boss to buy Ada, and everything was a compromise. Borland 'C' was super cheap and 100% available, as was Microsoft 'C' before it.
      - pjmlp 11y ago
        I kind of disagree. Turbo Pascal and Apple Pascal ruled back then, at least in Europe. On Apple's case it was even the main OS language. However with UNIX being adopted at work and universities, many wanted to be able to transport their work between home and work/uni. So people started to slowly adopt C. I followed the same pattern with C++. Eventually Turbo Pascal wasn't no longer an option, so started using Turbo C++, C was just too primitive and unsafe already back then, vs TP. At least C++ had some of the safety features I was used from TP, as long as one stayed away from C style coding.
xenadu02 11y ago
You're right. It keeps on giving us heartbleed, slammer, sasser, kernel null check eliding holes, and literally thousands upon thousands of other memory exploiting, remote executing, security breaking bugs. But I'm sure, Real Soon Now(TM), if teams just adopt (best practices / better libraries / better code reviews / better static analysis tools / better testing) all those problems will be solved and C will be a great language to keep using. After all, saving a few extra CPU cycles is totally worth breaking all SSL encryption and leaking private keys, quite literally putting the security of EVERY SINGLE FUCKING HUMAN WHO HAS EVER TOUCHED THE INTERNET in jeopardy. So sure, let's just keep using C. It's fine, why change anything amirite? (Sarcasm aside: In the general case it is not possible for humans to write security-critical code in C. So far the history of the internet has proven me 100% correct.)
- thrownaway2424 11y ago
  Every one of those problems you mentioned occurred in C code, not C++. That might seem like quibbling, but many of those bugs are caused by C memory management bullshit like malloc(that) if (error) goto: free(that), which isn't a problem that C++ has. A scratch reimplementation of OpenSSL in C++ would probably be 1/3rd the lines of code and entirely devoid of both goto and malloc.
  - rvense 11y ago
    And a Rust implementation might be half the code and entirely devoid of classes of bugs that might be in the C++.
    - quotemstr 11y ago
      Rust's standard library aborts on OOM. That's completely unacceptable. More generally, I find Rust's error handling awkward --- the most common excuse for Rust's OOM handling is "Otherwise, you'd need to cart Result everywhere." Of course. That's why we invented exceptions decades ago. The designers should have used traditional exceptions instead of trying to create something new --- the designers (just like Go's designers) had to go back and add exception support anyway. I'd have liked Rust more if it'd focused on memory safety and less on being different for the sake of being different. I want a memory safe, non-GC language with traditional curly brace syntax, traditional types, and exceptional error handling. Modern C++ is a much better approximation of that language than Rust is.
signa11 11y ago
> Why does anything need to replace C? It's been fine for years and still does exactly what it needs to do. well, for one the h/w model for one has far progressed beyond what the state of the art was during C's genesis. for example with the advent of multicore machines trying to use C's facilities to exploit available h/w resources becomes quickly unwieldy. witness the rise of event based approaches f.e. libevent and friends, or the rise of lockfree mechanisms etc. etc.

Why does anything need to replace C? It's been fine for years and still does exactly what it needs to do.

by flashm 11y ago

Why does anything need to replace C? It's been fine for years and still does exactly what it needs to do.

grabcocque 11y ago

The endless, eternal, continual stream of catastrophic security flaws in every C program of note begs to differ.

beering 11y ago

I think this is not a serious question, but I'll bite. We're paying a hefty price for C in the form of buffer overflows, memory leaks, slow development, and other problems and will continue to do so as long as we run software written in C. If we instead switch to a language that doesn't have these problems, then we'll come out better in the long run.

flashm 11y ago
It was slightly tongue in cheek - C is good at what it does, but I agree that there are plenty of good options going forward. I just don't think C will be 'replaced' across the board though, but I suppose that's obvious. Of the languages mentioned, I've only got experience with Go (which I use for APIs). Rust looks interesting though, I need to have a proper look at it.
EliRivers 11y ago
We won't come out "better". We'll have made a trade-off. For some situations, it will have been a trade-off that benefits. For others, it will have been the wrong choice. Just use the right tool for the job given the circumstances.
arihant 11y ago
These aren't problems of the language. These are a result of having a design choice of full programmer control. Having automatic cars is convenient and has its uses. But the argument that not using a manual cars will cause less road accidents is misinformed. It looks like that because common sense dictates that as it's easier to drive, more people will drive it easier. But usually the result is that now you have people on road who could not drive a stick! Some things are meant to be written in lowest level possible. Programming languages are tools and it helps us to have tools for entire spectrum of abstractions. Electronic screwdrivers haven't replaced manual ones in 2 decades. That's not how tools work. As far as direct comparisons go, these isn't any indication that raising the level of abstraction actually helps with more secure, bug-free code. Compare Java code written (in FOSS setting) with C code written in last 15 years. I bet you'd find C code more secure, more fast, more faster to refactor than a lot of Java code. So if Java was a systems language, would the world be better off if it replaced C? Probably no. Which shows that it's our infatuation with new shiny toys (languages like Go) that's driving our opinion rather than evidence.
- jerven 11y ago
  C is like running around with scissors in your hand because it allows you to cut paper faster when needed. Yes, its true but it is also likely to cost your eyes. Java FOSS code is often faster, more secure, and a lot easier to reason about than equivalent C code. This is not really a language thing but a standard library thing. The use of char array with a null termination for human readable strings is a terrible 'C' ism. And glibc standard String struct would have saved us all a lot of (security) issues. The second is a community thing. Java uses defined behaviour to drive optimisation. C tends to use undefined behaviour to drinve optimisatio. The C case really trips programmers up. Most of these things are not actual technical but more social issues. Computers don't care, it is us humans who do.
  - z92 11y ago
    > Java FOSS code is often faster, more secure But uses significantly more memory and requires a VM. The VM probably is written in C, too.
    - pjmlp 11y ago
      There are AOT compilers for Java, some of them actually written in Java. The reference JVM uses a mix of Java and C++, with code being migrated from C++ to Java and replaced with intrisics in each release. Java 9 will bring Graal/Truffle plugins, which are a JIT compiler framework, written in Java.
    - jerven 11y ago
      > But uses significantly more memory and requires a VM. Do they really use more memory for equivalent code. e.g. Is jetty that much worse than apache? I don't really think so. Even if the intrinsic memory consumption of a java object is more than one for a C struct that does not mean it will in practice actually use more memory, or that it has too be that way due to unassailable theoretical grounds. See Realtime java for an example. > The VM probably is written in C, too. Historical reasons only. It could have been fortran or pascal. Its not that C is magical in its low level. There are a whole bunch of other options as well. C was easy to get and it came with the OS for many developers when computers became more accessible due to lower costs in the late 70's and 80's. C is slow is not an uncommon opinion among fortran programmers, for good reasons. In practice the C++ parts of the different JVMs are getting smaller each release. And there have been JVMs that are written in Java with a bootstrap interpreter in ASM. As an OS with just java and assembly. After all, the language is turing complete... Don't take me wrong Java is not some promised land without issues, its got plenty of those. I am just refuting the idea that just because it written in C it is fast claim. GCC/XLC/ICC are not magic, neither is HotSpot or Vuze or J9 or any other JVM system. In many ways C and Java are alike, crap languages introduced in a time when other, better alternatives where available. Only saved by industry adoption and decades of engineering work to make them fly. Rust is so interesting as it has industry attention and is also academically interesting as bringing something new to the programming world. (at least I am not aware of any pl with the borrow checker concept worked out).

damienkatz 11y ago

Agree. The unstated conclusion is nothing is close to being a C replacement. A good analysis of the languages anyway.

moonshinefe 11y ago

Because a large portion of massive security holes in recent history have been due to archaic C libraries that have security holes a-plenty. A lot of these issues that plague C don't happen in modern languages. It's 43 years old (times have changed), and while I'm sure C still has its places, I think it's time to come to terms with the fact that people suck at handling memory manually and making sure type conversions are safe & a host of other security risks. Other, safer languages can accomplish many of the same things C does these days. Again, I'm not calling for the end of C, but in a lot of situations, it's just asking for it now.

cwoac 11y ago
There is a slightly disingenuity here. "a large portion of massive security holes in recent history have been due to archaic libraries that have security holes a-plenty". The fact they are also C libraries is because that was the only real option of the time when they were written; rather like saying most car accidents were caused by black ones when the only option was a model T.
- pjmlp 11y ago
  It is not true. Before C escaped UNIX there were other systems programming languages available.
  - ArkyBeagle 11y ago
    The manner in which it escaped Unix was through Microsoft and Borland, and I spent oodles of time evaluating other choices at the time. I could not get the boss to buy Ada, and everything was a compromise. Borland 'C' was super cheap and 100% available, as was Microsoft 'C' before it.
    - pjmlp 11y ago
      I kind of disagree. Turbo Pascal and Apple Pascal ruled back then, at least in Europe. On Apple's case it was even the main OS language. However with UNIX being adopted at work and universities, many wanted to be able to transport their work between home and work/uni. So people started to slowly adopt C. I followed the same pattern with C++. Eventually Turbo Pascal wasn't no longer an option, so started using Turbo C++, C was just too primitive and unsafe already back then, vs TP. At least C++ had some of the safety features I was used from TP, as long as one stayed away from C style coding.

xenadu02 11y ago

You're right. It keeps on giving us heartbleed, slammer, sasser, kernel null check eliding holes, and literally thousands upon thousands of other memory exploiting, remote executing, security breaking bugs. But I'm sure, Real Soon Now(TM), if teams just adopt (best practices / better libraries / better code reviews / better static analysis tools / better testing) all those problems will be solved and C will be a great language to keep using. After all, saving a few extra CPU cycles is totally worth breaking all SSL encryption and leaking private keys, quite literally putting the security of EVERY SINGLE FUCKING HUMAN WHO HAS EVER TOUCHED THE INTERNET in jeopardy. So sure, let's just keep using C. It's fine, why change anything amirite? (Sarcasm aside: In the general case it is not possible for humans to write security-critical code in C. So far the history of the internet has proven me 100% correct.)

thrownaway2424 11y ago
Every one of those problems you mentioned occurred in C code, not C++. That might seem like quibbling, but many of those bugs are caused by C memory management bullshit like malloc(that) if (error) goto: free(that), which isn't a problem that C++ has. A scratch reimplementation of OpenSSL in C++ would probably be 1/3rd the lines of code and entirely devoid of both goto and malloc.
- rvense 11y ago
  And a Rust implementation might be half the code and entirely devoid of classes of bugs that might be in the C++.
  - quotemstr 11y ago
    Rust's standard library aborts on OOM. That's completely unacceptable. More generally, I find Rust's error handling awkward --- the most common excuse for Rust's OOM handling is "Otherwise, you'd need to cart Result everywhere." Of course. That's why we invented exceptions decades ago. The designers should have used traditional exceptions instead of trying to create something new --- the designers (just like Go's designers) had to go back and add exception support anyway. I'd have liked Rust more if it'd focused on memory safety and less on being different for the sake of being different. I want a memory safe, non-GC language with traditional curly brace syntax, traditional types, and exceptional error handling. Modern C++ is a much better approximation of that language than Rust is.

signa11 11y ago

> Why does anything need to replace C? It's been fine for years and still does exactly what it needs to do. well, for one the h/w model for one has far progressed beyond what the state of the art was during C's genesis. for example with the advent of multicore machines trying to use C's facilities to exploit available h/w resources becomes quickly unwieldy. witness the rise of event based approaches f.e. libevent and friends, or the rise of lockfree mechanisms etc. etc.