[rurban]

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.

[mamcx]

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

But what Rust gives is that not assume that you want to do it for most programs.

[quotemstr]

> 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]

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.

[aw1621107]

> 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]

Have you ever seen a GC system with memory unsafeties? I cannot remember any

[aw1621107]

I think so, assuming I'm thinking of the same thing you are, but I think that's somewhat besides the point. What I'm trying to say is twofold:

- The presence of a GC doesn't guarantee memory safety since there are sources of memory unsafety that GCs don't/can't cover (i.e., escape hatches and/or FFI), not to mention the possibility of bugs in the GC implementation itself.

- The absence of a GC doesn't preclude memory safety since you can "just" refuse to compile anything which you can't prove to be memory-safe modulo escape hatches and/or axioms and/or FFI (and bugs, unfortunately). Formal verification toolchains for C (Frama-C, seL4's setup, etc.) and Ada/SPARK's stricter modes are good examples of this.

In the case of Rust:

- `unsafe` blocks (or at least their precursors) were added in 2011 [0].

- Rust's reference-counting GC was removed in 2014 [1].

That's why I think "ripped out their GC" is a bit of a non-sequitur for "got rid of the safeties". Rust wasn't entirely safe before the GC was removed because `unsafe` already existed. And even after the GC was removed, the entire point of Rust's infamous strictness is to reject programs for which safety can't be proved (modulo the same sources that existed before the GC was removed), so the removal of GC does not necessarily imply losing memory safety either.

[0]: https://github.com/rust-lang/rust/pull/1036

[1]: https://github.com/rust-lang/rust/pull/17666

[afdbcreid]

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]

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]

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]

Ha, I did maintain two safe languages. How many did you?

[quotemstr]

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]

Non-blocking IO is only one part to provide concurrency safety. Process locks are even worse. All locks are forbidden to avoid dead-locks.