3 ms·

I guess I'm starting a language war, but... I see how Rust is on that list. I don't get how the other languages are on that list. I mean, yes, I guess they'r

I guess I'm starting a language war, but... I see how Rust is on that list. I don't get how the other languages are on that list. I mean, yes, I guess they're marginally better than C and C++ at memory-safety, but... just barely...? Like... this report? https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/ https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

woodruffw 4y ago
I’m a big fan of Rust, and I think it’s reasonable for those languages to be listed: with the exception of a few niches, most of the code written in those languages will be spatially and temporally memory safe. They’re also popular languages with large ecosystems, so listing them “grounds” the guidance.
brightball 4y ago
I've actually heard claims of memory safety in Ruby for the last few years and I was always skeptical...but this gives those claims a lot more merit for sure. And worst case, there's always jRuby.
feukreust 4y ago
What do you mean just barely? They're exactly as safe as Rust. Perhaps they're not making it a selling point because it's been obvious for a few decades that automatic memory management tends to be memory safe. In fact some languages are even safer (e.g. Scheme and various Lisp implementations don't have integer overflows due to having bignums by default).
- VikingCoder 4y ago
  I guess I'm using "memory safety" very broadly and not literally, which I admit is not good. But, the borrow-checker seems to be significantly safer than anything else I've read about. Having no null pointer sounds very smart...
  - andai 4y ago
    Fair enough. I think Rust is the only language on that list which solves the "billion dollar mistake" (null pointers).
    - kaba0 4y ago
      Null pointers are not a memory safety issue in most managed languages. It is completely well-defined behavior in Java for example, you can safely catch any NPE and go on as if nothing happened. This is not true of C, where dereferencing a nullptr is incredibly unsafe.
  - 3a2d29 4y ago
    Except Rust can still have serious memory safety errors like double-frees and memory leaks. All those other languages cannot. Rust is much less safe than a GC language in terms of memory.
    - VikingCoder 4y ago
      C# cannot have a memory leak? We're using very different definitions of those words, I guess. https://slashdot.org/story/07/11/17/0552247/c-memory-leak-torpedoed-princetons-darpa-chances https://slashdot.org/story/07/11/17/0552247/c-memory-leak-to...
      - 3a2d29 4y ago
        C# allows you to tune the GC, which I believe was the cause of that issue. Keep in mind by turning off the GC, how have now made C# just as safe as rust, not unsafer.
        VikingCoder 4y ago
        I think that one was actually circular references in event handlers...
        4y ago
the__alchemist 4y ago
Safe and fast: Pick 1 has been the standard for a while. Rust is both, but this doesn't mean the others aren't safe.
weberer 4y ago
How is Java not memory-safe?
nicoburns 4y ago
I think the key thing is ironclad protection against memory corruption or gain unintended code execution access (barring a bug in the implementation of the compiler/runtime which can of course affect any language).

woodruffw 4y ago

I’m a big fan of Rust, and I think it’s reasonable for those languages to be listed: with the exception of a few niches, most of the code written in those languages will be spatially and temporally memory safe. They’re also popular languages with large ecosystems, so listing them “grounds” the guidance.

brightball 4y ago

I've actually heard claims of memory safety in Ruby for the last few years and I was always skeptical...but this gives those claims a lot more merit for sure. And worst case, there's always jRuby.

feukreust 4y ago

What do you mean just barely? They're exactly as safe as Rust. Perhaps they're not making it a selling point because it's been obvious for a few decades that automatic memory management tends to be memory safe. In fact some languages are even safer (e.g. Scheme and various Lisp implementations don't have integer overflows due to having bignums by default).

VikingCoder 4y ago
I guess I'm using "memory safety" very broadly and not literally, which I admit is not good. But, the borrow-checker seems to be significantly safer than anything else I've read about. Having no null pointer sounds very smart...
- andai 4y ago
  Fair enough. I think Rust is the only language on that list which solves the "billion dollar mistake" (null pointers).
  - kaba0 4y ago
    Null pointers are not a memory safety issue in most managed languages. It is completely well-defined behavior in Java for example, you can safely catch any NPE and go on as if nothing happened. This is not true of C, where dereferencing a nullptr is incredibly unsafe.
- 3a2d29 4y ago
  Except Rust can still have serious memory safety errors like double-frees and memory leaks. All those other languages cannot. Rust is much less safe than a GC language in terms of memory.
  - VikingCoder 4y ago
    C# cannot have a memory leak? We're using very different definitions of those words, I guess. https://slashdot.org/story/07/11/17/0552247/c-memory-leak-torpedoed-princetons-darpa-chances https://slashdot.org/story/07/11/17/0552247/c-memory-leak-to...
    - 3a2d29 4y ago
      C# allows you to tune the GC, which I believe was the cause of that issue. Keep in mind by turning off the GC, how have now made C# just as safe as rust, not unsafer.
      - VikingCoder 4y ago
        I think that one was actually circular references in event handlers...
        4y ago

the__alchemist 4y ago

Safe and fast: Pick 1 has been the standard for a while. Rust is both, but this doesn't mean the others aren't safe.

weberer 4y ago

How is Java not memory-safe?

nicoburns 4y ago

I think the key thing is ironclad protection against memory corruption or gain unintended code execution access (barring a bug in the implementation of the compiler/runtime which can of course affect any language).