4 ms·

"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 safet

"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, ...

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