3 ms·

The existence of a soundness bug in the typechecker doesn’t refute the value of soundness as a language design contract. If anything it’s the opposite: issues

The existence of a soundness bug in the typechecker doesn’t refute the value of soundness as a language design contract. If anything it’s the opposite: issues demonstrated by cve-rs are _language bugs_ and are _fixable_ in principle. “Safe Rust should be memory-safe” is a well-defined, falsifiable contract that the compiler can be measured against. Meanwhile memory unsafety is a feature of the semantics of C++ and so it would be absurd to file a bug against gcc complaining that it compiled your faulty code.

rurban 6mo ago
The language design contract is unsafe by default. In memory, types and concurrency. What are you talking about? There are unsafe blocks all over the stdlib. And concurrency safety would need to get rid of their blocking IO, which they haven't even acknowledged.
- quotemstr 6mo ago
  > There are unsafe blocks all over the stdlib Physics is unsafe. Something, somewhere needs to provide the safe core. > And concurrency safety would need to get rid of their blocking IO, which they haven't even acknowledged. Is your position that blocking IO can't be compatible with concurrency safety? That's a strange claim. Can you explain?
  - rurban 6mo ago
    Sure, but then they shout all over how safe they are. They got rid of the safeties pretty late, when they ripped out their GC, but kept their false promises all over. No, that's common knowledge. I fixed concurrency safety by forbidding blocking IO. Others also. Maybe there are other ways, but never heard of other ways.
    - quotemstr 6mo ago
      Huh? It doesn't follow that forbidding blocking IO is either necessary or sufficient for concurrency safety, at least under any definition of "safety" I can imagine. What do you mean? You mean async-not-blocking-event-loop stuff? That's not the only way to do more than one IO at a time.
      - rurban 6mo ago
        Non-blocking IO is only one part to provide concurrency safety. Process locks are even worse. All locks are forbidden to avoid dead-locks.
    - aw1621107 6mo ago
      > They got rid of the safeties pretty late, when they ripped out their GC, but kept their false promises all over. This seems like a non-sequitur to me? The presence/absence of a GC is not dispositive with respect to determining "safety", especially when the GC itself involves unsafe code.
      - rurban 6mo ago
        Have you ever seen a GC system with memory unsafeties? I cannot remember any
        afdbcreid 6mo ago
        Ah. I believe pretty much every safe language on the planet constantly has bugs in the implementation that can be exploited to cause unsafety. Sometimes they even get CVEs, e.g. in JavaScript VMs.
        rurban 6mo ago
        I don't do Javascript, but any self-respecting language which calls itself safe is actually safe. I worked for decades in actually memory and type safe languages, and never ever heard of a memory or type safety bug. Just not the cheaters: Rust, Java (until recently), and of course Javascript with its unsafe implementations. Memory safety bug in a proper lisp? Unheard of, unless you break the GC or do wrong FFI calls.
        kibwen 6mo ago
        You've made it clear from this thread that you have no idea what you're talking about. Please do not waste our time by commenting on this topic further.
        rurban 6mo ago
        Ha, I did maintain two safe languages. How many did you?
        aw1621107 6mo ago
- mamcx 6mo ago
  > The language design contract is unsafe by default False. The language design safe by default, something that you can confirm super easily doing just the Rust tutorials and compare the same with C or C++. Read the repo well: cve-rs implements the following bugs in safe Rust: Use after free Buffer overflow Segmentation fault NOT REFUTE IT. > There are unsafe blocks all over the stdlib Unsafe blocks is not the same that unsafe code. Are marked areas that are required to do escape automated checks, and there, you are at the level of a C/C++ programmer (where in that languages ALL THE CODE IS MARKED UNSAFE). If you complaint against that, is the same as complaint against ALL THE CODE writer on C/C++. --- One thing important to understand about Rust: Rust is a system language and SHOULD be able to implement everyting including, Buffer overflow, Use after free , Segmentation fault and such. You should be able to implement a terrible OS, malware, faulty drivers, etc, minimally because that is required to test safe programs! (example: Deterministic Simulation Testing https://turso.tech/blog/introducing-limbo-a-complete-rewrite-of-sqlite-in-rust https://turso.tech/blog/introducing-limbo-a-complete-rewrite...). But what Rust gives is that not assume that you want to do it for most programs.

rurban 6mo ago

The language design contract is unsafe by default. In memory, types and concurrency. What are you talking about? There are unsafe blocks all over the stdlib. And concurrency safety would need to get rid of their blocking IO, which they haven't even acknowledged.

quotemstr 6mo ago
> There are unsafe blocks all over the stdlib Physics is unsafe. Something, somewhere needs to provide the safe core. > And concurrency safety would need to get rid of their blocking IO, which they haven't even acknowledged. Is your position that blocking IO can't be compatible with concurrency safety? That's a strange claim. Can you explain?
- rurban 6mo ago
  Sure, but then they shout all over how safe they are. They got rid of the safeties pretty late, when they ripped out their GC, but kept their false promises all over. No, that's common knowledge. I fixed concurrency safety by forbidding blocking IO. Others also. Maybe there are other ways, but never heard of other ways.
  - quotemstr 6mo ago
    Huh? It doesn't follow that forbidding blocking IO is either necessary or sufficient for concurrency safety, at least under any definition of "safety" I can imagine. What do you mean? You mean async-not-blocking-event-loop stuff? That's not the only way to do more than one IO at a time.
    - rurban 6mo ago
      Non-blocking IO is only one part to provide concurrency safety. Process locks are even worse. All locks are forbidden to avoid dead-locks.
  - aw1621107 6mo ago
    > They got rid of the safeties pretty late, when they ripped out their GC, but kept their false promises all over. This seems like a non-sequitur to me? The presence/absence of a GC is not dispositive with respect to determining "safety", especially when the GC itself involves unsafe code.
    - rurban 6mo ago
      Have you ever seen a GC system with memory unsafeties? I cannot remember any
      - afdbcreid 6mo ago
        Ah. I believe pretty much every safe language on the planet constantly has bugs in the implementation that can be exploited to cause unsafety. Sometimes they even get CVEs, e.g. in JavaScript VMs.
        rurban 6mo ago
        I don't do Javascript, but any self-respecting language which calls itself safe is actually safe. I worked for decades in actually memory and type safe languages, and never ever heard of a memory or type safety bug. Just not the cheaters: Rust, Java (until recently), and of course Javascript with its unsafe implementations. Memory safety bug in a proper lisp? Unheard of, unless you break the GC or do wrong FFI calls.
      - kibwen 6mo ago
        You've made it clear from this thread that you have no idea what you're talking about. Please do not waste our time by commenting on this topic further.
        rurban 6mo ago
        Ha, I did maintain two safe languages. How many did you?
      - aw1621107 6mo ago
mamcx 6mo ago
> The language design contract is unsafe by default False. The language design safe by default, something that you can confirm super easily doing just the Rust tutorials and compare the same with C or C++. Read the repo well: cve-rs implements the following bugs in safe Rust: Use after free Buffer overflow Segmentation fault NOT REFUTE IT. > There are unsafe blocks all over the stdlib Unsafe blocks is not the same that unsafe code. Are marked areas that are required to do escape automated checks, and there, you are at the level of a C/C++ programmer (where in that languages ALL THE CODE IS MARKED UNSAFE). If you complaint against that, is the same as complaint against ALL THE CODE writer on C/C++. --- One thing important to understand about Rust: Rust is a system language and SHOULD be able to implement everyting including, Buffer overflow, Use after free , Segmentation fault and such. You should be able to implement a terrible OS, malware, faulty drivers, etc, minimally because that is required to test safe programs! (example: Deterministic Simulation Testing https://turso.tech/blog/introducing-limbo-a-complete-rewrite-of-sqlite-in-rust https://turso.tech/blog/introducing-limbo-a-complete-rewrite...). But what Rust gives is that not assume that you want to do it for most programs.