Re:The first new build of Circle, a new C++20 compiler, sinc...
by mjburgess on Monday January 23, 2023 @05:36PM
(#34496111)
You are right that the argument boils down to what we take "by construction" to mean.
I will resolve this, simply, by saying whatever advertisement Rust makes for itself, is better made by any "dynamic" language.
And if we're inclined to trade PR against PR, Rust looses. Managed memory has better PR.
And so those repeating the Rust agitprop against managed languages are simply "NPCs for the wrong ideology".
Re:The first new build of Circle, a new C++20 compiler, sinc...
by Yoric on Tuesday January 24, 2023 @03:37AM
(#34501084)
I would articulate things differently.
Theoretically, memory-safety between Rust and managed languages is equivalent.
However, memory-safe languages (i.e. not Managed C++) running on a memory-safe VM have one more layer of defense in depth than Rust. Additional layers may include, for instance, Unix and containers.
"dynamic" languages, though? That's entirely orthogonal to memory-safety and not very good for general software safety.
But, Safe Rust also chooses to construct safety that those GC'd languages don't have.
The reason Javascript doesn't have data races for example is that it doesn't have concurrency - can't have a race with only one runner. Java does have data races (with limited but still unsettling consequences), Go's data races are really bad, like actual Undefined Behaviour bad in some cases. Whereas Safe Rust doesn't have data races - you can write concurrent Safe Rust but you can't write a data race.
The difference you're grappling for probably feels intuitively like it should exist, but I assure you it does not.