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