4 ms·

Drew, you're actually wrong here. Safe systems languages predate Rust by quite a while, most of them being in the Wirth family (Modula, Oberon, etc.). Given tha

Drew, you're actually wrong here. Safe systems languages predate Rust by quite a while, most of them being in the Wirth family (Modula, Oberon, etc.). Given that here at HN, we have a large constituency of Lisp Hackers and Unix Haters (as in the handbook), if somebody talks about how C is junk, and how safe systems languages should be used instead (esp. if that person is pjmlp, nickpsecurity, or lispm), they are likely referring to those, not Rust. So not a reasonable connection to make, if you know a bit more of the context. I certainly don't blame you for making the jump, but I seem to be in the minority.

nickpsecurity 10y ago
Great analysis. The thread he links actually corroborates it, too. I've even found a few more safer, system languages since then that may be featured in future lists or threads. To be fair to me, though, note that I also heavily promote memory-safe C (eg Softbound, SAFEcode), memory-safe UNIX (CheriBSD, SVA-OS), and user-mode UNIX (eg seperation kernels, GenodeOS) to help UNIX/C users reduce serious problems they might encounter. I just default on countering root causes of problems as first resort. ;)
- qwertyuiop924 10y ago
  I didn't know that about you. However, I would say that you probably fall under UNIX-Hater nonetheless. Not that that is a bad thing, it's merely a statement about your opinions and ideals. I will totally have to check out some of those project now. Although I do wonder why Cyclone, the project that inspired Rust, wasn't on your list for memory-safe C.
  - nickpsecurity 10y ago
    Oh yeah, I've linked to original and ESR's interpretation of UNIX Hater Handbook. Like I said, great analysis minus that one aspect of my posts here. :) Far as recommendations, putting my name and those terms into Google gives me six hits on HN where I recommend them both. In several, I push alternatives like microkernels, SPARK, and Rust plus those if person stays with C. In reply to ZeroTier developer, I reference Code-Pointer Integrity too while pointing out he's less safe with C++ because he can't use these C features. Ironic. "Although I do wonder why Cyclone, the project that inspired Rust, wasn't on your list for memory-safe C." I get 47 hits on that as I give Morissett et al's work plenty credit. Often when someone says Rust did the dynamic safety first where I counter they got it from Cyclone. Reason I don't push Cyclone so much is it isn't actively developed any more like most safer C's. C people just ignore them. Others included Safe-C, Clay, and Vault languages although I don't think all of them were OSS'd. Many non-C languages also compiled to C to get portability and performance benefits while app gets type-checked or other checks (eg bounds). Hardly any take-up there either. At this point, I just recommend them putting work into compiler extensions that make C safer with reasonable performance hits. SAFEcode already in LLVM, too.
- nwmcsween 10y ago
  The problem is can you name a safe systems language that doesn't sacrifice performance? Dependent types should fix most but there is no current systems language with it.
  - masklinn 10y ago
    ATS? (though from the examples I've seen, the "UI" of the language is less than optimal)
    - nwmcsween 10y ago
      I looked at ATS quite some time back and wrote it off due to the syntax. Maybe I'll give ATS a second look.
  - nickpsecurity 10y ago
    "The problem is can you name a safe systems language that doesn't sacrifice performance?" Your performance comes specifically from not knowing your program will work upon malicious or faulty input. So, that claim is almost always apples to oranges. It's "language X let's me work and fail very fast" whereas "language Y let's me work fast." I think the 2nd one should be default option given speed of computers these days. Also, remember users' tolerance of program crashes may not be enough justification for riskier languages: silent corruption, which they don't like, can also result from unsafety. Far as languages, the Oberons used in OS's [1] and Modula-3 [2] used in CVSup were very fast. The safe variants of C [3] were faster than inserting checks yourself given the compiler optimized some checks away with static analysis. Annotation and backward compatibility varies with each. SPARK Ada [4] can go as fast as C for static code but with provable absence of common errors. Ada, its parent, systematically [5] prevents/catches errors across whole process of programming. Rust is very CPU efficient with dynamic memory and concurrency safety. D language [6] is like a better C++ without C's risks. Fast as Free Pascal last I saw. ATS [7] is a programming-with-proofs language that uses dependent types to prove safety. It's been used on a 8-bit MCU. Finally, you can use typed, assembly languages [8] if performance really matters that much to you. Some academics & companies also mock-up assembly's in things like Rust, SPARK, etc to leverage their analyses with extraction to actual ASM. [1] https://en.wikipedia.org/wiki/Bluebottle_OS https://en.wikipedia.org/wiki/Bluebottle_OS [2] https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 [3] https://www.cs.uic.edu/pub/Main/PhDQualifyingExam/Sample4.pdf https://www.cs.uic.edu/pub/Main/PhDQualifyingExam/Sample4.pd... [4] http://www.adacore.com/press/spark-skein/ http://www.adacore.com/press/spark-skein/ [5] http://libre.adacore.com/developers/technical-papers-single/Ada-2012-safe-and-secure-booklet http://libre.adacore.com/developers/technical-papers-single/... [6] https://dlang.org/overview.html https://dlang.org/overview.html [7] http://www.ats-lang.org/ http://www.ats-lang.org/ [8] https://www.cs.cornell.edu/talc/ https://www.cs.cornell.edu/talc/
pjmlp 10y ago
Thanks for the hint, getting famous :) Actually I would enjoy C, if the language just had a few things from Wirth side: - Real enumerations, decay to integers requires explicit cast - No decay of arrays to pointers, &array[0] required for pointer conversion - References (no need to pass around pointers for out parameters) - bound checked arrays, for Assembly like performance use #pragma or compiler switch to disabled them I could remember a few more, this are just a few examples. However, we already had these features out of the box in C++ in 1993 when I used for the first time[0], hence why I never was a big C fan. [0] - To honest some of them required writing classes and overloading operators, but they were there.
- qwertyuiop924 10y ago
  >Actually I would enjoy C, if the language just had a few things from Wirth side: ...Which is pretty much my point: You don't like C, because it didn't take from Wirth enough. Do you have some kind of program that automatically notifies you whenever your name gets mentioned on HN? Because whenever I mention you, you show up within a day...
  - pjmlp 10y ago
    Hehe,no but it looks like a cool weekend idea.
  - nickpsecurity 10y ago
    "Which is pretty much my point: You don't like C, because it didn't take from Wirth enough." Close but not there yet. He doesn't like C because it ignored and still ignores basic, safety features on commonly-used operations. Wirth's stuff is often cited because it did safe one's as baseline, simple syntax/semantics, and for weak hardware. Closer to C than ALGOL, PL/0, and other languages we could cite that also had more safety. Telling a C programmer Thompson and Ritchie could've done ALGOL68 on a PDP-7 less believable than saying they could've done Modula-2 or something similar. ;) Note: I also can't overemphasize enough that the first language they actually designed, feature by feature, to replace C was a modification of Wirth's Oberon-2 with features like we're talking about. Their Go work is indeed reducing number of crashes and vulnerabilities in systems versus C work while performing fast and improving. Imagine if they just started with Wirth's stuff then kept it practical and long-lasting (unlike Wirth).

nickpsecurity 10y ago

Great analysis. The thread he links actually corroborates it, too. I've even found a few more safer, system languages since then that may be featured in future lists or threads. To be fair to me, though, note that I also heavily promote memory-safe C (eg Softbound, SAFEcode), memory-safe UNIX (CheriBSD, SVA-OS), and user-mode UNIX (eg seperation kernels, GenodeOS) to help UNIX/C users reduce serious problems they might encounter. I just default on countering root causes of problems as first resort. ;)

qwertyuiop924 10y ago
I didn't know that about you. However, I would say that you probably fall under UNIX-Hater nonetheless. Not that that is a bad thing, it's merely a statement about your opinions and ideals. I will totally have to check out some of those project now. Although I do wonder why Cyclone, the project that inspired Rust, wasn't on your list for memory-safe C.
- nickpsecurity 10y ago
  Oh yeah, I've linked to original and ESR's interpretation of UNIX Hater Handbook. Like I said, great analysis minus that one aspect of my posts here. :) Far as recommendations, putting my name and those terms into Google gives me six hits on HN where I recommend them both. In several, I push alternatives like microkernels, SPARK, and Rust plus those if person stays with C. In reply to ZeroTier developer, I reference Code-Pointer Integrity too while pointing out he's less safe with C++ because he can't use these C features. Ironic. "Although I do wonder why Cyclone, the project that inspired Rust, wasn't on your list for memory-safe C." I get 47 hits on that as I give Morissett et al's work plenty credit. Often when someone says Rust did the dynamic safety first where I counter they got it from Cyclone. Reason I don't push Cyclone so much is it isn't actively developed any more like most safer C's. C people just ignore them. Others included Safe-C, Clay, and Vault languages although I don't think all of them were OSS'd. Many non-C languages also compiled to C to get portability and performance benefits while app gets type-checked or other checks (eg bounds). Hardly any take-up there either. At this point, I just recommend them putting work into compiler extensions that make C safer with reasonable performance hits. SAFEcode already in LLVM, too.
nwmcsween 10y ago
The problem is can you name a safe systems language that doesn't sacrifice performance? Dependent types should fix most but there is no current systems language with it.
- masklinn 10y ago
  ATS? (though from the examples I've seen, the "UI" of the language is less than optimal)
  - nwmcsween 10y ago
    I looked at ATS quite some time back and wrote it off due to the syntax. Maybe I'll give ATS a second look.
- nickpsecurity 10y ago
  "The problem is can you name a safe systems language that doesn't sacrifice performance?" Your performance comes specifically from not knowing your program will work upon malicious or faulty input. So, that claim is almost always apples to oranges. It's "language X let's me work and fail very fast" whereas "language Y let's me work fast." I think the 2nd one should be default option given speed of computers these days. Also, remember users' tolerance of program crashes may not be enough justification for riskier languages: silent corruption, which they don't like, can also result from unsafety. Far as languages, the Oberons used in OS's [1] and Modula-3 [2] used in CVSup were very fast. The safe variants of C [3] were faster than inserting checks yourself given the compiler optimized some checks away with static analysis. Annotation and backward compatibility varies with each. SPARK Ada [4] can go as fast as C for static code but with provable absence of common errors. Ada, its parent, systematically [5] prevents/catches errors across whole process of programming. Rust is very CPU efficient with dynamic memory and concurrency safety. D language [6] is like a better C++ without C's risks. Fast as Free Pascal last I saw. ATS [7] is a programming-with-proofs language that uses dependent types to prove safety. It's been used on a 8-bit MCU. Finally, you can use typed, assembly languages [8] if performance really matters that much to you. Some academics & companies also mock-up assembly's in things like Rust, SPARK, etc to leverage their analyses with extraction to actual ASM. [1] https://en.wikipedia.org/wiki/Bluebottle_OS https://en.wikipedia.org/wiki/Bluebottle_OS [2] https://en.wikipedia.org/wiki/Modula-3 https://en.wikipedia.org/wiki/Modula-3 [3] https://www.cs.uic.edu/pub/Main/PhDQualifyingExam/Sample4.pdf https://www.cs.uic.edu/pub/Main/PhDQualifyingExam/Sample4.pd... [4] http://www.adacore.com/press/spark-skein/ http://www.adacore.com/press/spark-skein/ [5] http://libre.adacore.com/developers/technical-papers-single/Ada-2012-safe-and-secure-booklet http://libre.adacore.com/developers/technical-papers-single/... [6] https://dlang.org/overview.html https://dlang.org/overview.html [7] http://www.ats-lang.org/ http://www.ats-lang.org/ [8] https://www.cs.cornell.edu/talc/ https://www.cs.cornell.edu/talc/

pjmlp 10y ago

Thanks for the hint, getting famous :) Actually I would enjoy C, if the language just had a few things from Wirth side: - Real enumerations, decay to integers requires explicit cast - No decay of arrays to pointers, &array[0] required for pointer conversion - References (no need to pass around pointers for out parameters) - bound checked arrays, for Assembly like performance use #pragma or compiler switch to disabled them I could remember a few more, this are just a few examples. However, we already had these features out of the box in C++ in 1993 when I used for the first time[0], hence why I never was a big C fan. [0] - To honest some of them required writing classes and overloading operators, but they were there.

qwertyuiop924 10y ago
>Actually I would enjoy C, if the language just had a few things from Wirth side: ...Which is pretty much my point: You don't like C, because it didn't take from Wirth enough. Do you have some kind of program that automatically notifies you whenever your name gets mentioned on HN? Because whenever I mention you, you show up within a day...
- pjmlp 10y ago
  Hehe,no but it looks like a cool weekend idea.
- nickpsecurity 10y ago
  "Which is pretty much my point: You don't like C, because it didn't take from Wirth enough." Close but not there yet. He doesn't like C because it ignored and still ignores basic, safety features on commonly-used operations. Wirth's stuff is often cited because it did safe one's as baseline, simple syntax/semantics, and for weak hardware. Closer to C than ALGOL, PL/0, and other languages we could cite that also had more safety. Telling a C programmer Thompson and Ritchie could've done ALGOL68 on a PDP-7 less believable than saying they could've done Modula-2 or something similar. ;) Note: I also can't overemphasize enough that the first language they actually designed, feature by feature, to replace C was a modification of Wirth's Oberon-2 with features like we're talking about. Their Go work is indeed reducing number of crashes and vulnerabilities in systems versus C work while performing fast and improving. Imagine if they just started with Wirth's stuff then kept it practical and long-lasting (unlike Wirth).