6 ms·

Did any of those provide safety by means of compile-time checks (as opposed to sophisticated runtime systems, which are by necessity more expensive), though? AF

Did any of those provide safety by means of compile-time checks (as opposed to sophisticated runtime systems, which are by necessity more expensive), though? AFAICT, Lisp didn't, Smalltalk didn't and Oberon didn't.

pjmlp 11y ago
Not all the use cases that Rust covers, but many of the typical errors that are possible in C, yes. For example, the NEWP in MCP only allowed unsafe code in modes where the system administrator would configure them as such, back in 1961. https://en.wikipedia.org/wiki/Burroughs_MCP https://en.wikipedia.org/wiki/Burroughs_MCP https://en.wikipedia.org/wiki/NEWP https://en.wikipedia.org/wiki/NEWP
- catnaroek 11y ago
  If you need unsafe code to implement the garbage collector and other core system facilities, then “selectively” disabling safety doesn't really mean much, does it? Also, determining whether code is safe to run requires proof, not trust. Since when are system administrators particularly skilled at coming up with proofs?
  - pjmlp 11y ago
    Who said anything about NEWP using a GC?! Also the type of enabling/disabling unsafe code in those lanugages was not much different than running "rustc -D unsafe-code" Also computer admins in the 60's were programmers.
    - catnaroek 11y ago
      Somehow I'm doubtful that, using 60's-era technology, many non-trivial data structures and algorithms could be proven safe in a mechanized way. As for trusting a programmer's word, it's probably better than trusting a non-programmer's, but enabling unsafe code is still fundamentally a social hack. While you can work around technical problems by social means, this will never constitute a ultimately satisfactory solution.
      - pjmlp 11y ago
        I am not saying they were full proof, I am saying that systems programming languages from 60's and 70's were much safer than C. Many of memory corruption issues with C aren't a problem with the stronger type system of Algol and PL/* family of languages. However OSes written in those languages were commercial, whereas C was bundled with UNIX, distributed for free, because AT&T was forbidden to charge for it. If it wasn't for that, most likely Rust wouldn't be needed, at least not in the way it looks like.
        catnaroek 11y ago
        > Many of memory corruption issues with C aren't a problem with the stronger type system of Algol and PL/* family of languages. This is probably just my lack of imagination, but, how would you get the same degree of control C offers over the memory layout of data structures (among other things), without giving up on safety, and using only 60's and 70's technology? Even (safe) Rust doesn't help in some cases, say, if you want a single dynamically allocated memory block containing an array of “m” integers followed by an array of “n” floating-points, where “m” and “n” are determined at runtime. Or are you just going to say this is never desirable? > If it wasn't for that, most likely Rust wouldn't be needed, at least not in the way it looks like. Because we would still be using tagged architectures, and every machine instruction would incur in the cost of checking these tags? Or because non-determinism is never too big a price to pay for safe memory management? (Never mind the fact that programs also need to manipulate other resources that aren't as plentiful as memory, and thus require eager reclamation.) No, thanks.
        derefr 11y ago
        It might be desirable now, but those '60s/'70s OSes probably weren't dynamically allocating memory ever. They'd make a buffer in [their equivalent to] the .BSS section that was M×sizeof(int), and another that was N×sizeof(float), and then they'd process records through those buffers blockwise.
        pcwalton 11y ago
pcwalton 11y ago
Some did (SPARK for example), but they sacrificed dynamic allocation (i.e. malloc). Rust's real innovation (in an industry sense) is safe dynamic allocation without GC.
- pjmlp 11y ago
  And I wish it manages to succeed, if it wasn't for Rust, the C++ Core Guidelines wouldn't be a thing.
  - masklinn 11y ago
    > if it wasn't for Rust, the C++ Core Guidelines wouldn't be a thing So in a way, Rust has already succeeded.
- catnaroek 11y ago
  So, basically, the only thing that is ever dynamically allocated in SPARK is activation records? Sounds overly restrictive.
- PeCaN 11y ago
  ATS has had this (via linear types like Rust) for a while, but it's a massive pain to use. Rust's main innovation is gluing together existing ideas with a powerful community backing.
nickpsecurity 11y ago
Stack, bounds, and code vs data checks like Burrough's can be encoded with almost no gates in a processor. They can run in parallel to main CPU's activity with CPU results only written if checks succeed. One aspect of SAFE architecture at crash-safe.org did that along with some others. So, no, it's pretty easy and not done since modern processors are optimized to run unsafe, C code. ;) http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...
- catnaroek 11y ago
  So, in other words, a tagged architecture, except the possible values of the tags are "usable" and "not usable"? Sounds horrible - it's the hardware equivalent of checking at runtime whether a variable is in scope in, say, Python or JavaScript. I don't see any point to checking at runtime what can be known statically.
  - nickpsecurity 11y ago
    The tags are more commonly a few types like scaler, array, pointer w/ bounds, and so on. It checks basic stuff rather than full heap safety. Too tired to remember if there's one on that. The point was that runtime checking of critical aspects of safety isn't necessarily some high-overhead operation. The basics that go the furthest cost little to nothing in many designs. Then, you can go from there in your language or compiler design.
    - catnaroek 11y ago
      > The point was that runtime checking of critical aspects of safety isn't necessarily some high-overhead operation. The runtime check doesn't make the operation any less unsafe - it only makes the consequences of an error less disastrous.
      - nickpsecurity 11y ago
        "The runtime check doesn't make the operation any less unsafe - it only makes the consequences of an error less disastrous." I think we have a different definition of unsafe. If you think it's potential to cause problems, then I agree it doesn't make it less unsafe. Alternatively, it does make it less unsafe if that means it reduces the ability to invisibly corrupt data, hack your system, or crash your system. That's what I'm claiming. Even Rust or Ada might have a hard time meeting that definition once their pristine codes are converted into assembly.

pjmlp 11y ago

Not all the use cases that Rust covers, but many of the typical errors that are possible in C, yes. For example, the NEWP in MCP only allowed unsafe code in modes where the system administrator would configure them as such, back in 1961. https://en.wikipedia.org/wiki/Burroughs_MCP https://en.wikipedia.org/wiki/Burroughs_MCP https://en.wikipedia.org/wiki/NEWP https://en.wikipedia.org/wiki/NEWP

catnaroek 11y ago
If you need unsafe code to implement the garbage collector and other core system facilities, then “selectively” disabling safety doesn't really mean much, does it? Also, determining whether code is safe to run requires proof, not trust. Since when are system administrators particularly skilled at coming up with proofs?
- pjmlp 11y ago
  Who said anything about NEWP using a GC?! Also the type of enabling/disabling unsafe code in those lanugages was not much different than running "rustc -D unsafe-code" Also computer admins in the 60's were programmers.
  - catnaroek 11y ago
    Somehow I'm doubtful that, using 60's-era technology, many non-trivial data structures and algorithms could be proven safe in a mechanized way. As for trusting a programmer's word, it's probably better than trusting a non-programmer's, but enabling unsafe code is still fundamentally a social hack. While you can work around technical problems by social means, this will never constitute a ultimately satisfactory solution.
    - pjmlp 11y ago
      I am not saying they were full proof, I am saying that systems programming languages from 60's and 70's were much safer than C. Many of memory corruption issues with C aren't a problem with the stronger type system of Algol and PL/* family of languages. However OSes written in those languages were commercial, whereas C was bundled with UNIX, distributed for free, because AT&T was forbidden to charge for it. If it wasn't for that, most likely Rust wouldn't be needed, at least not in the way it looks like.
      - catnaroek 11y ago
        > Many of memory corruption issues with C aren't a problem with the stronger type system of Algol and PL/* family of languages. This is probably just my lack of imagination, but, how would you get the same degree of control C offers over the memory layout of data structures (among other things), without giving up on safety, and using only 60's and 70's technology? Even (safe) Rust doesn't help in some cases, say, if you want a single dynamically allocated memory block containing an array of “m” integers followed by an array of “n” floating-points, where “m” and “n” are determined at runtime. Or are you just going to say this is never desirable? > If it wasn't for that, most likely Rust wouldn't be needed, at least not in the way it looks like. Because we would still be using tagged architectures, and every machine instruction would incur in the cost of checking these tags? Or because non-determinism is never too big a price to pay for safe memory management? (Never mind the fact that programs also need to manipulate other resources that aren't as plentiful as memory, and thus require eager reclamation.) No, thanks.
        derefr 11y ago
        It might be desirable now, but those '60s/'70s OSes probably weren't dynamically allocating memory ever. They'd make a buffer in [their equivalent to] the .BSS section that was M×sizeof(int), and another that was N×sizeof(float), and then they'd process records through those buffers blockwise.
        pcwalton 11y ago

pcwalton 11y ago

Some did (SPARK for example), but they sacrificed dynamic allocation (i.e. malloc). Rust's real innovation (in an industry sense) is safe dynamic allocation without GC.

pjmlp 11y ago
And I wish it manages to succeed, if it wasn't for Rust, the C++ Core Guidelines wouldn't be a thing.
- masklinn 11y ago
  > if it wasn't for Rust, the C++ Core Guidelines wouldn't be a thing So in a way, Rust has already succeeded.
catnaroek 11y ago
So, basically, the only thing that is ever dynamically allocated in SPARK is activation records? Sounds overly restrictive.
PeCaN 11y ago
ATS has had this (via linear types like Rust) for a while, but it's a massive pain to use. Rust's main innovation is gluing together existing ideas with a powerful community backing.

nickpsecurity 11y ago

Stack, bounds, and code vs data checks like Burrough's can be encoded with almost no gates in a processor. They can run in parallel to main CPU's activity with CPU results only written if checks succeed. One aspect of SAFE architecture at crash-safe.org did that along with some others. So, no, it's pretty easy and not done since modern processors are optimized to run unsafe, C code. ;) http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...

catnaroek 11y ago
So, in other words, a tagged architecture, except the possible values of the tags are "usable" and "not usable"? Sounds horrible - it's the hardware equivalent of checking at runtime whether a variable is in scope in, say, Python or JavaScript. I don't see any point to checking at runtime what can be known statically.
- nickpsecurity 11y ago
  The tags are more commonly a few types like scaler, array, pointer w/ bounds, and so on. It checks basic stuff rather than full heap safety. Too tired to remember if there's one on that. The point was that runtime checking of critical aspects of safety isn't necessarily some high-overhead operation. The basics that go the furthest cost little to nothing in many designs. Then, you can go from there in your language or compiler design.
  - catnaroek 11y ago
    > The point was that runtime checking of critical aspects of safety isn't necessarily some high-overhead operation. The runtime check doesn't make the operation any less unsafe - it only makes the consequences of an error less disastrous.
    - nickpsecurity 11y ago
      "The runtime check doesn't make the operation any less unsafe - it only makes the consequences of an error less disastrous." I think we have a different definition of unsafe. If you think it's potential to cause problems, then I agree it doesn't make it less unsafe. Alternatively, it does make it less unsafe if that means it reduces the ability to invisibly corrupt data, hack your system, or crash your system. That's what I'm claiming. Even Rust or Ada might have a hard time meeting that definition once their pristine codes are converted into assembly.