9 ms·

Let’s sunset C/C++

31 points by vu3rdd 11y ago

just4once 11y ago
Absurdly absurd ideas and ramblings. I suppose we can write our "safe languages" in "safe languages" then we'll never have need of really programming anything ourselves. We can simply pat together what ever is "safe" for us to do in our little play sandbox and act like we're adults who understand the problems faced when programming in "real" languages. This would be similar to replacing all automobiles with stuffed animals because, who in the world ever heard of stuffed animals getting into pile-up wreaks on the freeway and causing death misery and misfortune.
- fiedzia 11y ago
  Rule 20.4 (required): Dynamic heap memory allocation shall not be used. Good luck writing misra-compliant web browser. And yes, safe languages can be written in safe languages. See rust and servo.
  - sklogic 11y ago
    > Good luck writing misra-compliant web browser. I'd be delighted to see one. Statically pre-allocating a large continuous chunk of memory for the whole browser process lifetime would have been great.
    - quonn 11y ago
      And then, what do you do with that chunk? Since the amount of memory you need depends on the website (e.g. some might need memory for a canvas, others might display large tables, etc.), presumably you take parts of it and allocate them for the various tasks you need to do? So you just write your own dynamic memory allocator.
      - sklogic 11y ago
        > So you just write your own dynamic memory allocator. If the entire pool is reclaimed once page is rendered (and there is a way to handle the running out of space condition) it may not count as a rule violation, no more than incrementing an array index counter. And, browser is hardly a mission-critical appliance.
  - huhtenberg 11y ago
    This MISRA - https://en.wikipedia.org/wiki/MISRA_C https://en.wikipedia.org/wiki/MISRA_C ?
  - Nashenas 11y ago
    Rust and servo are great projects, but I would say there's still some time before Rust can completely replace C/C++. The language is stable, but there's still a lot of tooling that needs to be built up, and the compiler needs to be more performant. I also think it needs a few more small features in order to truly compete with C++ (it's already on par with C, in my opinion), e.g. being able to specify sized traits as return types. Once that's all done I think starting new projects in C/C++ wouldn't make sense anymore.
  - deleted 11y ago
    [deleted]
  - JustSomeNobody 11y ago
    "... misra-compliant web browser." Surely this is a joke.
    - RotsiserMho 11y ago
      I so wish it were.
sklogic 11y ago
C still got a right to exist even in the very sensitive mission-critical environments, as long as MISRA requirements are followed (and, the good thing is that they can be automatically enforced).
- pjmlp 11y ago
  MISRA makes C look like Ada with C syntax.
Timmons 11y ago
This is quite ignorant of why C/C++ is used. It is used for that exact memory control and access that this article demonizes so that we can have efficient and thought out systems. When those systems aren't well thought out or secure you have security issues. C/C++ lets you build a wobbly treehouse _and_ a secure fortress. It is up to the developer which one is made...
- peterwaller 11y ago
  A place where your reasoning breaks down is when one comes to define "the developer". There are a few legendary developers in the world I would trust to write secure C/C++. Others may be able to do so, by luck. Would I trust an organization of 2000 people all developing the same large code base? I know there are processes that can be adopted, such as using clever static analysis tools and rigorous review by security professionals. But time and time again, the community says "Yay, we've invented X, this makes a huge class of security bugs obsolete". Then Y comes along and opens the playing field again. (e.g, X=Data execution prevention, Y=Return oriented programming). This keeps happening. It takes some arrogance to believe that a safe large system can be built in an unsafe language, these days.
  - JustSomeNobody 11y ago
    This will happen regardless of C or C++.
    - peterwaller 11y ago
      I agree with this and bilbo0s. There exists no panacea. But C/C++ leave a lot of unholstered footguns lying around to play with :)
  - bilbo0s 11y ago
    "...But time and time again, the community says "Yay, we've invented X, this makes a huge class of security bugs obsolete". Then Y comes along and opens the playing field again..." To be fair... This issue exists with every other language as well. I would be very skeptical of any language claiming to be 100% secure. The same is true of the developer argument. Cyclone, Rust, C#, Java... you name it... they are all capable of producing systems with security vulnerabilities owing to developer quality inconsistencies.
w8rbt 11y ago
Secure software can be written in C or C++ (they are two different languages BTW). For example, OpenBSD and OpenSSH. Both are written in C and both have very good security records.
- pjmlp 11y ago
  You are joking in regards to OpenSSH right?
  - w8rbt 11y ago
    No, not at all. It's likely the most secure remote access software that you could use. http://www.openssh.com/security.html http://www.openssh.com/security.html
    - pjmlp 11y ago
      Except when it isn't http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial_name=OpenSSH_vulnerabilities.html http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial... http://www.cvedetails.com/vulnerability-list/vendor_id-97/product_id-585/version_id-121223/Openbsd-Openssh-5.3.html http://www.cvedetails.com/vulnerability-list/vendor_id-97/pr...
      - rrss1122 11y ago
        Any secure remote access software is the most secure, except when it isn't. This is a tautology, doesn't reveal any deep insight.
        pjmlp 11y ago
        The point being that the amount of available exploits shows it is far from being secure.
J_Darnley 11y ago
So what language to you propose we use to rewrite all video and audio software? Javascript, Lua, Brainfuck, what? Sure make every numeric value a double, nobody ever wants a char. Don't allow contiguous blocks of memory. Or if you do check every access is within the bounds. Its all safe! Nobody cares that suddenly we can't decode an MP3 in realtime. Are you going to outlaw assembly too? What utter insanity.
- pjmlp 11y ago
  Ada, Modula-2, .... > What utter insanity. Insanity is that C and C++ keep being used.
- JustSomeNobody 11y ago
  Pffft... Javascript. Don't you read CodingHorror? W/E! /s
- zamalek 11y ago
  I suppose the answer would be Rust or similar because they aim to be as fast as C/++; however, that is currently only a goal and most certainly not the reality (according to some source I read a month or two back that I can no longer find). I also hope to end C/++, but it's simply not time yet.
  - sdf45 11y ago
    Please show me how to implement a graph library without using unsafe in Rust.
    - lifthrasiir 11y ago
      This argument is very flawed, since you are forced to use `unsafe` when you need anything communicating to the outside world (which includes, obviously, `println!`). The very point of Rust is to limit the unsafe surface, not to completely eliminate that.
      - 11y ago
tempodox 11y ago
To this, I can only agree. I love C and I can write secure software in it, but the costs of doing that are generally not worthwhile in today's market (if they ever were). C will still have a place in its niche, but it shouldn't be considered the standard general-purpose language any more. Our processors have gotten so fast we can run slow-motion versions without even noticing (smartphone & tablet CPUs), so don't tell me anything other than C would be “too slow”. C is unbeatable as long as riding rodeo on your raw CPU is all you could ever want. But software has evolved, mankind's dependency on software has evolved, and so have our expectations & standards. It's time to learn the lesson and move on.
- justwannasing 11y ago
  Niche? C and Java are the most used languages in the world!
  - tempodox 11y ago
    Niche as in “where it makes sense to use it because the strengths of the language support your important goals and the weaknesses don't kill you” as opposed to using it because it's one of the most used languages in the world.
    - justwannasing 11y ago
      Which emphasizes my point. There are few places where C's strength is not prevalent and its weaknesses won't kill you.
      - tempodox 11y ago
        Depending on your skill, which is a scarce resource in general.
- chriswarbo 11y ago
  Memory-safety doesn't make a language slower. Garbage collection does, but there are other approaches like linear types which perform all checks at compile-time, so the resulting code doesn't need to do any checking/indirection/etc. and is hence equivalent to what C would produce.
swah 11y ago
Another way to look at it: the ones that can write that software are still chosing C/C++. The ones who would like to use Haskell/Rust/Java are discussing online.. :)
walkingolof 11y ago
"There are only two kinds of languages: the ones people complain about and the ones nobody uses". -Bjarne
flohofwoe 11y ago
Excuse my french, but: What a load of bullshit. It's not the language, it's the tools. Add a static analyzer pass to each C/C++ compiler which is switched on by default. Add clang-address-sanitizer-style code when compiling in debug mode, and also offer runtime checks as option for release-compiled code. Both combined would have caught 99% of memory safety issues that pop up now and then. If necessary extend the language with optional ownership keywords a'la Rust, and allow me to switch off features I don't require to reduce complexity. Most important of all: provide options that I don't need to pay at runtime for memory safety with precious CPU cycles.
- justwannasing 11y ago
  If by "tools" you mean "user" then, yes, you are correct. This author is a tool. In French, your first line would be, "Oh, hell no!"
- sdf45 11y ago
  While tooling may help, I think that a completely new approach is necessary. The correctness invariants of complex C++ programs (such as browsers and JITs) cannot be 'discovered' by static analysis - they must be, at least in part, supplied by the programmer. C and C++ were not designed to allow programmers to specify such invariants (and have them automatically checked). I am not convinced that introducing them can be done in a clean way.
  - flohofwoe 11y ago
    Hmm true, we could have a new 'safe' keyword (or even #pragma) which would switch off 'unsafe' language features (basically the opposite of Rust's 'unsafe' enforce a stricter, more restrictive code style which is easier for the static analyzer to reason about). The majority of even high-performance C/C++ apps only needs to twiddle bits in very small areas of the code. That's still a lot better then trying to rewrite basically all software that has been written in the last 50 years ;)
- gizmo 11y ago
  No need to panic, nobody is coming to take your precious pointer arithmetic away. If you want to write unsafe code, go ahead. But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. We're talking about classes of security bugs that just don't exist in managed languages. Bugs that can't happen in languages like Rust either because it forces programmers to indicate ownership and lifetime of memory. There's always a trade-off between performance and security, but with better tooling support the price for secure code will be very low. Right now security is bad because we look at security as a feature. As something that is added to a project, instead of as something that guides the entire design. Your suggestion that static analysis can fix this is wildly optimistic, because C/C++ code for a modern browser uses memory pools, pointer arithmetic, just-in-time compilation, and shared memory between object instances, threads and processes and so on. It's hugely complex, and correctness can't be verified with some sort of static analyzer or with added runtime checks.
deleted 11y ago
[deleted]
sdf45 11y ago
As of yet, a browser (in particular the JavaScript JIT) cannot be implemented in a safe language. It is not even clear how a safe language that would permit this would look like. Thinking that banning C/C++ magically solves all problems is naive.
- epidemian 11y ago
  > It is not even clear how a safe language that would permit this would look like. If this hypothetical browser is implemented in a safe language that runs on a JIT-compiled environment itself, then it could compile JS to that same safe language and allow that same runtime environment to JIT-compile the resulting compiled JS. Would that make sense? (I have no empirical data to back this up, but i'd like to know if at least hypothetically this approach could work)
deleted 11y ago
[deleted]
stef13013 11y ago
If it's a joke it is quite good. Your post is full of memory leaks, can you rewrite it with a better language... Please.
eatonphil 11y ago
I'm confused when the author says the DOM is garbage collected only in IE/Blink. How is DOM memory managed elsewhere? At first guess, I thought the JavaScript runtime (which surely always uses garbage collection) would manage the DOM, but I'm guessing that's not actually the case. Who is typically in charge of memory management at that layer?
- steveklabnik 11y ago
  Spidermonkey has a GC which manages DOM objects, so yeah, that claim would appear false.
p0nce 11y ago
C++ is safe enough, provided you use the tools like Intel Inspector, valgrind, and static analyzers. With C++11 memory corruptions became a somewhat rare occurence.
- pjmlp 11y ago
  Which most developers actually don't use, specially the 9-5 developers.
  - p0nce 11y ago
    Indeed. C++ is incredibly fragmented, I guess that could cause its demise before safety becomes an actual concern for language choices.
carlosrg 11y ago
C++11 is pretty "memory safe". But obviously it allows the programmer go low-level and deal with dangling pointers if he/she wants. After all, the programmer/engineer is supposed to be a professional that can handle these things and make autonomous decisions.
- pjmlp 11y ago
  Exactly! When I use C++ alone, I use it like e.g. Ada or C#. When I use C++ in a team, I cry how they make it C with a C++ compiler.
deleted 11y ago
[deleted]
J2Alpha 11y ago
I do appreciate a good troll once in a while but they shouldn't rise to the top page of HN. It gives them ideas above their station. I have a burning question tough, What pray tell safe language would you use to write the original garbage collector, because Garbage collecting is only a form of abstracting good pointer practices away, helping programmers write complex programs easily.
- jganetsk 11y ago
  Who said anything about a garbage collector? https://www.rust-lang.org/ https://www.rust-lang.org/
cranklin 11y ago
garbage collection makes not a language safe
planteen 11y ago
Is there even an operating system not written in asm/C/C++ to run these "secure" non-C/C++ applications?
- steveklabnik 11y ago
  You only need a tiny bit of asm to have an operating system in Rust. No C required.
  - planteen 11y ago
    Is there an OS yet in Rust though? Google tells me about these projects: https://github.com/ryanra/RustOS https://github.com/ryanra/RustOS http://scialex.github.io/reenix.pdf http://scialex.github.io/reenix.pdf
    - steveklabnik 11y ago
      There are a number of hobby projects, but nothing you'd want to use in production yet. That of course doesn't really change the amount of assembly needed. (Also, there's been a lot of rumbling about MirageOS, see https://internals.rust-lang.org/t/unikernels-in-rust/2494 https://internals.rust-lang.org/t/unikernels-in-rust/2494 and the linked MirageOS mailing list thread)
justwannasing 11y ago
My problem with this article and its statement is that it's saying to "sunset" C/C++ because it causes problems but the problems are caused by an incompetent user, not C. I see so many articles complaining about C letting you shoot yourself in the foot but no one who would shoot themselves in the foot should be handling a gun. "You know you wouldn't have so many splatters on that painting, Mr. Pollock, if you would just let a computer handle that brush for you!"
charlesL 11y ago
Ugh... these kinds of extreme posts really piss me off. Yes, C is unsafe. Yes, there are safer higher level languages, but there's a reason C is used. Because it's REALLY freaking fast, and allows you to actually tune how memory is used. The issue with C is not the language itself. It's the complexity of the project. Once a project reaches a certain size, no programmer will be able to keep the entire thing in their head at one time. That's why the bugs appear. I have no issue with saying that C is hard to work with in giant projects. If you have an issue with that, write the sections of code that bottleneck in C, and then glue them together with a higher level language (I personally like Lua for this). Also, the post is mainly complaining about security issues for Chrome. Assuming Chrome is rewritten in Rust or Go, will these security issues vanish? Of course not. Bugs (especially security bugs) will exist in all software, whether it's written in C or Ruby. So the results of rewriting all C code in the world is: slower, less optimized code and continued existence of security bugs. Sounds great.
- steveklabnik 11y ago
  > Assuming Chrome is rewritten in Rust or Go, will these security > issues vanish? Of course not It's true that they will never _vanish_, but all of the ones related to memory safety, which are the ones the article focuses on, shouldn't happen in Rust: > 70% of the high-risk bugs in Chrome 44 would have been prevented > if Chrome were written in a memory-safe language instead of C/C++. (it's true that it's not 100%, because someone could still write bad code in an unsafe block, but that's a _significant_ reduction in the surface area, which should lead to a similar reduction in errors.)
- pjmlp 11y ago
  > So the results of rewriting all C code in the world is: slower, less optimized code and continued existence of security bugs. Sounds great. C compilers are fast today. They used to be crap in the early 90's and seen as we see Python and Ruby performance nowadays. Execution speed isn't a magic feature of C, not available to any other compiled language. C is the systems programming language that allows for buffer overruns, memory corruption and dangling pointers everywhere in the codebase. Other systems programming languages allow developers to explicitly only use those features explicitly when required. In C using strings is enough.
notacoward 11y ago
"This is a huge job" I don't think the author fully appreciates just how huge, and how many new bugs would be introduced by rewrites on that scale. It might be reasonable to say C/C++ should be deprecated for new projects, but truly vast amounts of C/C++ will remain with us for the foreseeable future. Perhaps a better approach would be to ease integration of new code written in memory-safe languages with older code written in C/C++, which tends to be tedious at best nowadays.
rrss1122 11y ago
"I don’t see many people in the security industry taking up this call..." http://www.viva64.com/en/b/0324/ http://www.viva64.com/en/b/0324/ [Criticizing the Rust Language, and Why C/C++ Will Never Die ] "It is crystal clear for every sane programmer that C/C++ is not going to die in the nearest future. No one is going to rewrite almost all of the existing desktop applications, operating system kernels, compilers, game and browser engines, virtual machines, databases, archivers, audio and video codecs, tons of other C-libraries, and so on and so forth, into other languages. This is a huge mass of fast, debugged, and time-proven code. Rewriting it is way, way too expensive, risky, and, honestly, doesn't seem to make sense except in the heads of the most frantic Rust fans. The demand for C/C++ programmers has always been high and will remain so for a long time to come." Seems like just more proselytizing from Rust fans looking to expand their ranks. Of course more people in the security industry are not taking up this call, because it is a ridiculous suggestion.
- pjmlp 11y ago
  To the point that Intel has poured millions of dollars into researching how to make C code safe. https://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions https://software.intel.com/en-us/articles/introduction-to-in... This is the real cost of language features.
AnimalMuppet 11y ago
The article claims that the problem with Flash is not so much Flash itself, but that it's written in C/C++. It "proves" the point by listing a bunch of high-profile exploits in various other systems, then repeats the claim that C/C++ is the problem, and advocates abandoning C/C++. That's... not exactly proof. It's barely even evidence. Yes, you can argue "all these programs have all these flaws, and all are written in C/C++". And that's true. They are written in C/C++, and they have these flaws. Now let's look at the programs that do the same kinds of things, and are as widely used, and are not written in C/C++, and compare the number of exploits... oh, you don't have a handy list of equivalent programs to compare? Go work on that; I'll wait. The fundamental problem is that these programs are trying to safely handle hostile input, with attackers having essentially infinite time to experiment and craft attacks, including attacks that the authors didn't know that they needed to defend against at the time the code and/or the spec were written. Would the whole world be safer if everything were at least written in Java? Yes, it might be safer, but not safe. And it would take more resources, and often take longer to start up. And it would be vulnerable to bugs in the design and implementation of the JVM, which would become a single point of failure for a lot of software. That world would, perhaps, be somewhat safer, but it wouldn't be the security paradise that the article envisions. Not everyone is a fool who doesn't use the tools you think are best...
vu3rdd 11y ago
I think a lot of comments in this thread are too harsh. I am a C programmer myself and see the value of it in embedded systems, operating system kernels etc. While it is possible to write correct programs in C and C++ (which are very different languages, but usually mentioned together because of their names and history), it is too easy to make mistakes that are not caught by the compiler. It is easier to be sloppy in C than in say, Go or Rust. I have seen this in my own code and also in others' code. C is not the only way to write system programs. Oberon, Inferno are good examples of OS environments written in safer languages. But I agree that some of the disadvantages of C are also its advantages. The author of the blog post has more followup posts: http://trevorjim.com/why-safe-languages-are-the-best-way-to-achieve-memory-safety/ http://trevorjim.com/an-unsafe-legacy/ http://trevorjim.com/unsafe-at-any-speed/ [edit: fix typos, rephrase a few sentences, fix links]

31 points by vu3rdd 11y ago

Absurdly absurd ideas and ramblings. I suppose we can write our "safe languages" in "safe languages" then we'll never have need of really programming anything ourselves. We can simply pat together what ever is "safe" for us to do in our little play sandbox and act like we're adults who understand the problems faced when programming in "real" languages. This would be similar to replacing all automobiles with stuffed animals because, who in the world ever heard of stuffed animals getting into pile-up wreaks on the freeway and causing death misery and misfortune.

fiedzia 11y ago
Rule 20.4 (required): Dynamic heap memory allocation shall not be used. Good luck writing misra-compliant web browser. And yes, safe languages can be written in safe languages. See rust and servo.
- sklogic 11y ago
  > Good luck writing misra-compliant web browser. I'd be delighted to see one. Statically pre-allocating a large continuous chunk of memory for the whole browser process lifetime would have been great.
  - quonn 11y ago
    And then, what do you do with that chunk? Since the amount of memory you need depends on the website (e.g. some might need memory for a canvas, others might display large tables, etc.), presumably you take parts of it and allocate them for the various tasks you need to do? So you just write your own dynamic memory allocator.
    - sklogic 11y ago
      > So you just write your own dynamic memory allocator. If the entire pool is reclaimed once page is rendered (and there is a way to handle the running out of space condition) it may not count as a rule violation, no more than incrementing an array index counter. And, browser is hardly a mission-critical appliance.
- huhtenberg 11y ago
  This MISRA - https://en.wikipedia.org/wiki/MISRA_C https://en.wikipedia.org/wiki/MISRA_C ?
- Nashenas 11y ago
  Rust and servo are great projects, but I would say there's still some time before Rust can completely replace C/C++. The language is stable, but there's still a lot of tooling that needs to be built up, and the compiler needs to be more performant. I also think it needs a few more small features in order to truly compete with C++ (it's already on par with C, in my opinion), e.g. being able to specify sized traits as return types. Once that's all done I think starting new projects in C/C++ wouldn't make sense anymore.
- deleted 11y ago
  [deleted]
- JustSomeNobody 11y ago
  "... misra-compliant web browser." Surely this is a joke.
  - RotsiserMho 11y ago
    I so wish it were.

sklogic 11y ago

C still got a right to exist even in the very sensitive mission-critical environments, as long as MISRA requirements are followed (and, the good thing is that they can be automatically enforced).

pjmlp 11y ago
MISRA makes C look like Ada with C syntax.

Timmons 11y ago

This is quite ignorant of why C/C++ is used. It is used for that exact memory control and access that this article demonizes so that we can have efficient and thought out systems. When those systems aren't well thought out or secure you have security issues. C/C++ lets you build a wobbly treehouse _and_ a secure fortress. It is up to the developer which one is made...

peterwaller 11y ago
A place where your reasoning breaks down is when one comes to define "the developer". There are a few legendary developers in the world I would trust to write secure C/C++. Others may be able to do so, by luck. Would I trust an organization of 2000 people all developing the same large code base? I know there are processes that can be adopted, such as using clever static analysis tools and rigorous review by security professionals. But time and time again, the community says "Yay, we've invented X, this makes a huge class of security bugs obsolete". Then Y comes along and opens the playing field again. (e.g, X=Data execution prevention, Y=Return oriented programming). This keeps happening. It takes some arrogance to believe that a safe large system can be built in an unsafe language, these days.
- JustSomeNobody 11y ago
  This will happen regardless of C or C++.
  - peterwaller 11y ago
    I agree with this and bilbo0s. There exists no panacea. But C/C++ leave a lot of unholstered footguns lying around to play with :)
- bilbo0s 11y ago
  "...But time and time again, the community says "Yay, we've invented X, this makes a huge class of security bugs obsolete". Then Y comes along and opens the playing field again..." To be fair... This issue exists with every other language as well. I would be very skeptical of any language claiming to be 100% secure. The same is true of the developer argument. Cyclone, Rust, C#, Java... you name it... they are all capable of producing systems with security vulnerabilities owing to developer quality inconsistencies.

w8rbt 11y ago

Secure software can be written in C or C++ (they are two different languages BTW). For example, OpenBSD and OpenSSH. Both are written in C and both have very good security records.

pjmlp 11y ago
You are joking in regards to OpenSSH right?
- w8rbt 11y ago
  No, not at all. It's likely the most secure remote access software that you could use. http://www.openssh.com/security.html http://www.openssh.com/security.html
  - pjmlp 11y ago
    Except when it isn't http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial_name=OpenSSH_vulnerabilities.html http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial... http://www.cvedetails.com/vulnerability-list/vendor_id-97/product_id-585/version_id-121223/Openbsd-Openssh-5.3.html http://www.cvedetails.com/vulnerability-list/vendor_id-97/pr...
    - rrss1122 11y ago
      Any secure remote access software is the most secure, except when it isn't. This is a tautology, doesn't reveal any deep insight.
      - pjmlp 11y ago
        The point being that the amount of available exploits shows it is far from being secure.

J_Darnley 11y ago

So what language to you propose we use to rewrite all video and audio software? Javascript, Lua, Brainfuck, what? Sure make every numeric value a double, nobody ever wants a char. Don't allow contiguous blocks of memory. Or if you do check every access is within the bounds. Its all safe! Nobody cares that suddenly we can't decode an MP3 in realtime. Are you going to outlaw assembly too? What utter insanity.

pjmlp 11y ago
Ada, Modula-2, .... > What utter insanity. Insanity is that C and C++ keep being used.
JustSomeNobody 11y ago
Pffft... Javascript. Don't you read CodingHorror? W/E! /s
zamalek 11y ago
I suppose the answer would be Rust or similar because they aim to be as fast as C/++; however, that is currently only a goal and most certainly not the reality (according to some source I read a month or two back that I can no longer find). I also hope to end C/++, but it's simply not time yet.
- sdf45 11y ago
  Please show me how to implement a graph library without using unsafe in Rust.
  - lifthrasiir 11y ago
    This argument is very flawed, since you are forced to use `unsafe` when you need anything communicating to the outside world (which includes, obviously, `println!`). The very point of Rust is to limit the unsafe surface, not to completely eliminate that.
    - 11y ago

tempodox 11y ago

To this, I can only agree. I love C and I can write secure software in it, but the costs of doing that are generally not worthwhile in today's market (if they ever were). C will still have a place in its niche, but it shouldn't be considered the standard general-purpose language any more. Our processors have gotten so fast we can run slow-motion versions without even noticing (smartphone & tablet CPUs), so don't tell me anything other than C would be “too slow”. C is unbeatable as long as riding rodeo on your raw CPU is all you could ever want. But software has evolved, mankind's dependency on software has evolved, and so have our expectations & standards. It's time to learn the lesson and move on.

justwannasing 11y ago
Niche? C and Java are the most used languages in the world!
- tempodox 11y ago
  Niche as in “where it makes sense to use it because the strengths of the language support your important goals and the weaknesses don't kill you” as opposed to using it because it's one of the most used languages in the world.
  - justwannasing 11y ago
    Which emphasizes my point. There are few places where C's strength is not prevalent and its weaknesses won't kill you.
    - tempodox 11y ago
      Depending on your skill, which is a scarce resource in general.
chriswarbo 11y ago
Memory-safety doesn't make a language slower. Garbage collection does, but there are other approaches like linear types which perform all checks at compile-time, so the resulting code doesn't need to do any checking/indirection/etc. and is hence equivalent to what C would produce.

swah 11y ago

Another way to look at it: the ones that can write that software are still chosing C/C++. The ones who would like to use Haskell/Rust/Java are discussing online.. :)

walkingolof 11y ago

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". -Bjarne

flohofwoe 11y ago

Excuse my french, but: What a load of bullshit. It's not the language, it's the tools. Add a static analyzer pass to each C/C++ compiler which is switched on by default. Add clang-address-sanitizer-style code when compiling in debug mode, and also offer runtime checks as option for release-compiled code. Both combined would have caught 99% of memory safety issues that pop up now and then. If necessary extend the language with optional ownership keywords a'la Rust, and allow me to switch off features I don't require to reduce complexity. Most important of all: provide options that I don't need to pay at runtime for memory safety with precious CPU cycles.

justwannasing 11y ago
If by "tools" you mean "user" then, yes, you are correct. This author is a tool. In French, your first line would be, "Oh, hell no!"
sdf45 11y ago
While tooling may help, I think that a completely new approach is necessary. The correctness invariants of complex C++ programs (such as browsers and JITs) cannot be 'discovered' by static analysis - they must be, at least in part, supplied by the programmer. C and C++ were not designed to allow programmers to specify such invariants (and have them automatically checked). I am not convinced that introducing them can be done in a clean way.
- flohofwoe 11y ago
  Hmm true, we could have a new 'safe' keyword (or even #pragma) which would switch off 'unsafe' language features (basically the opposite of Rust's 'unsafe' enforce a stricter, more restrictive code style which is easier for the static analyzer to reason about). The majority of even high-performance C/C++ apps only needs to twiddle bits in very small areas of the code. That's still a lot better then trying to rewrite basically all software that has been written in the last 50 years ;)
gizmo 11y ago
No need to panic, nobody is coming to take your precious pointer arithmetic away. If you want to write unsafe code, go ahead. But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. We're talking about classes of security bugs that just don't exist in managed languages. Bugs that can't happen in languages like Rust either because it forces programmers to indicate ownership and lifetime of memory. There's always a trade-off between performance and security, but with better tooling support the price for secure code will be very low. Right now security is bad because we look at security as a feature. As something that is added to a project, instead of as something that guides the entire design. Your suggestion that static analysis can fix this is wildly optimistic, because C/C++ code for a modern browser uses memory pools, pointer arithmetic, just-in-time compilation, and shared memory between object instances, threads and processes and so on. It's hugely complex, and correctness can't be verified with some sort of static analyzer or with added runtime checks.

deleted 11y ago

[deleted]

sdf45 11y ago

As of yet, a browser (in particular the JavaScript JIT) cannot be implemented in a safe language. It is not even clear how a safe language that would permit this would look like. Thinking that banning C/C++ magically solves all problems is naive.

epidemian 11y ago
> It is not even clear how a safe language that would permit this would look like. If this hypothetical browser is implemented in a safe language that runs on a JIT-compiled environment itself, then it could compile JS to that same safe language and allow that same runtime environment to JIT-compile the resulting compiled JS. Would that make sense? (I have no empirical data to back this up, but i'd like to know if at least hypothetically this approach could work)

deleted 11y ago

[deleted]

stef13013 11y ago

If it's a joke it is quite good. Your post is full of memory leaks, can you rewrite it with a better language... Please.

eatonphil 11y ago

I'm confused when the author says the DOM is garbage collected only in IE/Blink. How is DOM memory managed elsewhere? At first guess, I thought the JavaScript runtime (which surely always uses garbage collection) would manage the DOM, but I'm guessing that's not actually the case. Who is typically in charge of memory management at that layer?

steveklabnik 11y ago
Spidermonkey has a GC which manages DOM objects, so yeah, that claim would appear false.

p0nce 11y ago

C++ is safe enough, provided you use the tools like Intel Inspector, valgrind, and static analyzers. With C++11 memory corruptions became a somewhat rare occurence.

pjmlp 11y ago
Which most developers actually don't use, specially the 9-5 developers.
- p0nce 11y ago
  Indeed. C++ is incredibly fragmented, I guess that could cause its demise before safety becomes an actual concern for language choices.

carlosrg 11y ago

C++11 is pretty "memory safe". But obviously it allows the programmer go low-level and deal with dangling pointers if he/she wants. After all, the programmer/engineer is supposed to be a professional that can handle these things and make autonomous decisions.

pjmlp 11y ago
Exactly! When I use C++ alone, I use it like e.g. Ada or C#. When I use C++ in a team, I cry how they make it C with a C++ compiler.

deleted 11y ago

[deleted]

J2Alpha 11y ago

I do appreciate a good troll once in a while but they shouldn't rise to the top page of HN. It gives them ideas above their station. I have a burning question tough, What pray tell safe language would you use to write the original garbage collector, because Garbage collecting is only a form of abstracting good pointer practices away, helping programmers write complex programs easily.

jganetsk 11y ago
Who said anything about a garbage collector? https://www.rust-lang.org/ https://www.rust-lang.org/

cranklin 11y ago

garbage collection makes not a language safe

planteen 11y ago

Is there even an operating system not written in asm/C/C++ to run these "secure" non-C/C++ applications?

steveklabnik 11y ago
You only need a tiny bit of asm to have an operating system in Rust. No C required.
- planteen 11y ago
  Is there an OS yet in Rust though? Google tells me about these projects: https://github.com/ryanra/RustOS https://github.com/ryanra/RustOS http://scialex.github.io/reenix.pdf http://scialex.github.io/reenix.pdf
  - steveklabnik 11y ago
    There are a number of hobby projects, but nothing you'd want to use in production yet. That of course doesn't really change the amount of assembly needed. (Also, there's been a lot of rumbling about MirageOS, see https://internals.rust-lang.org/t/unikernels-in-rust/2494 https://internals.rust-lang.org/t/unikernels-in-rust/2494 and the linked MirageOS mailing list thread)

justwannasing 11y ago

My problem with this article and its statement is that it's saying to "sunset" C/C++ because it causes problems but the problems are caused by an incompetent user, not C. I see so many articles complaining about C letting you shoot yourself in the foot but no one who would shoot themselves in the foot should be handling a gun. "You know you wouldn't have so many splatters on that painting, Mr. Pollock, if you would just let a computer handle that brush for you!"

charlesL 11y ago

Ugh... these kinds of extreme posts really piss me off. Yes, C is unsafe. Yes, there are safer higher level languages, but there's a reason C is used. Because it's REALLY freaking fast, and allows you to actually tune how memory is used. The issue with C is not the language itself. It's the complexity of the project. Once a project reaches a certain size, no programmer will be able to keep the entire thing in their head at one time. That's why the bugs appear. I have no issue with saying that C is hard to work with in giant projects. If you have an issue with that, write the sections of code that bottleneck in C, and then glue them together with a higher level language (I personally like Lua for this). Also, the post is mainly complaining about security issues for Chrome. Assuming Chrome is rewritten in Rust or Go, will these security issues vanish? Of course not. Bugs (especially security bugs) will exist in all software, whether it's written in C or Ruby. So the results of rewriting all C code in the world is: slower, less optimized code and continued existence of security bugs. Sounds great.

steveklabnik 11y ago
> Assuming Chrome is rewritten in Rust or Go, will these security > issues vanish? Of course not It's true that they will never _vanish_, but all of the ones related to memory safety, which are the ones the article focuses on, shouldn't happen in Rust: > 70% of the high-risk bugs in Chrome 44 would have been prevented > if Chrome were written in a memory-safe language instead of C/C++. (it's true that it's not 100%, because someone could still write bad code in an unsafe block, but that's a _significant_ reduction in the surface area, which should lead to a similar reduction in errors.)
pjmlp 11y ago
> So the results of rewriting all C code in the world is: slower, less optimized code and continued existence of security bugs. Sounds great. C compilers are fast today. They used to be crap in the early 90's and seen as we see Python and Ruby performance nowadays. Execution speed isn't a magic feature of C, not available to any other compiled language. C is the systems programming language that allows for buffer overruns, memory corruption and dangling pointers everywhere in the codebase. Other systems programming languages allow developers to explicitly only use those features explicitly when required. In C using strings is enough.

notacoward 11y ago

"This is a huge job" I don't think the author fully appreciates just how huge, and how many new bugs would be introduced by rewrites on that scale. It might be reasonable to say C/C++ should be deprecated for new projects, but truly vast amounts of C/C++ will remain with us for the foreseeable future. Perhaps a better approach would be to ease integration of new code written in memory-safe languages with older code written in C/C++, which tends to be tedious at best nowadays.

rrss1122 11y ago

"I don’t see many people in the security industry taking up this call..." http://www.viva64.com/en/b/0324/ http://www.viva64.com/en/b/0324/ [Criticizing the Rust Language, and Why C/C++ Will Never Die ] "It is crystal clear for every sane programmer that C/C++ is not going to die in the nearest future. No one is going to rewrite almost all of the existing desktop applications, operating system kernels, compilers, game and browser engines, virtual machines, databases, archivers, audio and video codecs, tons of other C-libraries, and so on and so forth, into other languages. This is a huge mass of fast, debugged, and time-proven code. Rewriting it is way, way too expensive, risky, and, honestly, doesn't seem to make sense except in the heads of the most frantic Rust fans. The demand for C/C++ programmers has always been high and will remain so for a long time to come." Seems like just more proselytizing from Rust fans looking to expand their ranks. Of course more people in the security industry are not taking up this call, because it is a ridiculous suggestion.

pjmlp 11y ago
To the point that Intel has poured millions of dollars into researching how to make C code safe. https://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions https://software.intel.com/en-us/articles/introduction-to-in... This is the real cost of language features.

AnimalMuppet 11y ago

The article claims that the problem with Flash is not so much Flash itself, but that it's written in C/C++. It "proves" the point by listing a bunch of high-profile exploits in various other systems, then repeats the claim that C/C++ is the problem, and advocates abandoning C/C++. That's... not exactly proof. It's barely even evidence. Yes, you can argue "all these programs have all these flaws, and all are written in C/C++". And that's true. They are written in C/C++, and they have these flaws. Now let's look at the programs that do the same kinds of things, and are as widely used, and are not written in C/C++, and compare the number of exploits... oh, you don't have a handy list of equivalent programs to compare? Go work on that; I'll wait. The fundamental problem is that these programs are trying to safely handle hostile input, with attackers having essentially infinite time to experiment and craft attacks, including attacks that the authors didn't know that they needed to defend against at the time the code and/or the spec were written. Would the whole world be safer if everything were at least written in Java? Yes, it might be safer, but not safe. And it would take more resources, and often take longer to start up. And it would be vulnerable to bugs in the design and implementation of the JVM, which would become a single point of failure for a lot of software. That world would, perhaps, be somewhat safer, but it wouldn't be the security paradise that the article envisions. Not everyone is a fool who doesn't use the tools you think are best...

vu3rdd 11y ago

I think a lot of comments in this thread are too harsh. I am a C programmer myself and see the value of it in embedded systems, operating system kernels etc. While it is possible to write correct programs in C and C++ (which are very different languages, but usually mentioned together because of their names and history), it is too easy to make mistakes that are not caught by the compiler. It is easier to be sloppy in C than in say, Go or Rust. I have seen this in my own code and also in others' code. C is not the only way to write system programs. Oberon, Inferno are good examples of OS environments written in safer languages. But I agree that some of the disadvantages of C are also its advantages. The author of the blog post has more followup posts: http://trevorjim.com/why-safe-languages-are-the-best-way-to-achieve-memory-safety/ http://trevorjim.com/an-unsafe-legacy/ http://trevorjim.com/unsafe-at-any-speed/ [edit: fix typos, rephrase a few sentences, fix links]