4 ms·

All of which have had massive security flaws, including hundreds or even thousands of zero-day remote exploits. And that's just counting the C memory corruption

All of which have had massive security flaws, including hundreds or even thousands of zero-day remote exploits. And that's just counting the C memory corruption bugs, not actual algorithmic bugs. If C requires me to only code in certain styles and only use certain tools to only get some increase in safety... Why not just use a language that builds safety in from the beginning? That said, we're just going to continue soldiering on because of horrible programmer attitudes like yours. Everyone wants to believe that they are a unique little snowflake who wouldn't make those kinds of mistakes (oh wait, Coverty couldn't catch Heartbleed, oops) and choose the comfortable fiction of a Just World where people get what they deserve. After all, if people just drove better we wouldn't have so many accidents, so why bother with air bags and seat belts? Better hope everyone else drives better too or you'll be changing all your passwords and keys with the rest of us schlubs no matter how fancy your valgrind test suite is.

PhantomGremlin 12y ago
> oh wait, Coverty couldn't catch Heartbleed, oops Not fair. Iirc the reason Coverity couldn't catch Heartbleed was because the OpenSSL people insisted on rolling their own inferior memory allocation. It would have worked if they just used the system malloc(). Coverity only works for normal programmers, it can't fully mitigate the ingenuity of complete fools. Of course, my recollection could be wrong. In which case "someone is wrong on the Internet" will apply and someone will quickly set the record straight.
jeffdavis 12y ago
"If C requires me to only code in certain styles and only use certain tools to only get some increase in safety... Why not just use a language that builds safety in from the beginning?" What language actually meets the need? GC'd languages haven't proven themselves useful for things like OSs, databases, or libraries that are deployed extremely widely in many environments. So what safe, non-GC language are you advocating?
- zurn 12y ago
  This is irrelevant (and false). GC is orthogonal to memory safety. (And all of those things have been successfully been done in GC'd languages.)
  - jeffdavis 12y ago
    Not sure what I said was false? I agree that GC and memory safety are orthogonal -- see rust. But there aren't a lot of options if you want safe and non-GC, which was my point. And GC is just not an option sometimes. GC has been around forever but it just hasn't proven itself in a lot of domains. I don't think it's for lack of trying, I think it's because sometimes you want to manage the memory.
- coldtea 12y ago
  There are several available (and some in the making). That they aren't more established for this kind of work is both a historical accident (bad moves with regards to licencing, etc) and a result of the cavalier, worse-is-better solutions the industry takes to everything, even when it's counter-productive (e.g with regards to security) that didn't let them catch on. For some known ones, used at one point or another for those purposes, Ada, Pascal, Oberon, Modula, etc. New contenders still in development include stuff like Rust, as a GC-optional newer contender. One wonders why it took until 2010+ to see another attempt at these kind of languages, as if we didn't have any issues with C/C++.
- Curmudgel 12y ago
  > GC'd languages haven't proven themselves useful for things like OSs, What about Lisp Machines?
  - lispm 12y ago
    Lisp Machines provide ways to 'manually' manage memory for things like network stacks. If a Lisp Machine is doing a global full GC (which it wants to avoid as much as possible), then it does not react in any useful way to inputs, the network, ...

PhantomGremlin 12y ago

> oh wait, Coverty couldn't catch Heartbleed, oops Not fair. Iirc the reason Coverity couldn't catch Heartbleed was because the OpenSSL people insisted on rolling their own inferior memory allocation. It would have worked if they just used the system malloc(). Coverity only works for normal programmers, it can't fully mitigate the ingenuity of complete fools. Of course, my recollection could be wrong. In which case "someone is wrong on the Internet" will apply and someone will quickly set the record straight.

jeffdavis 12y ago

"If C requires me to only code in certain styles and only use certain tools to only get some increase in safety... Why not just use a language that builds safety in from the beginning?" What language actually meets the need? GC'd languages haven't proven themselves useful for things like OSs, databases, or libraries that are deployed extremely widely in many environments. So what safe, non-GC language are you advocating?

zurn 12y ago
This is irrelevant (and false). GC is orthogonal to memory safety. (And all of those things have been successfully been done in GC'd languages.)
- jeffdavis 12y ago
  Not sure what I said was false? I agree that GC and memory safety are orthogonal -- see rust. But there aren't a lot of options if you want safe and non-GC, which was my point. And GC is just not an option sometimes. GC has been around forever but it just hasn't proven itself in a lot of domains. I don't think it's for lack of trying, I think it's because sometimes you want to manage the memory.
coldtea 12y ago
There are several available (and some in the making). That they aren't more established for this kind of work is both a historical accident (bad moves with regards to licencing, etc) and a result of the cavalier, worse-is-better solutions the industry takes to everything, even when it's counter-productive (e.g with regards to security) that didn't let them catch on. For some known ones, used at one point or another for those purposes, Ada, Pascal, Oberon, Modula, etc. New contenders still in development include stuff like Rust, as a GC-optional newer contender. One wonders why it took until 2010+ to see another attempt at these kind of languages, as if we didn't have any issues with C/C++.
Curmudgel 12y ago
> GC'd languages haven't proven themselves useful for things like OSs, What about Lisp Machines?
- lispm 12y ago
  Lisp Machines provide ways to 'manually' manage memory for things like network stacks. If a Lisp Machine is doing a global full GC (which it wants to avoid as much as possible), then it does not react in any useful way to inputs, the network, ...