21–30 of 143 posts
Meta comment, but I really like the formatting of the blog post! It reminds me of the early days of the web, when text was king and content was king. I particularly like the sidenotes in the margins approach. (Hope the author sees this comment :) Hats off)
The fact that re-using a slot for a different object of the same type is considered a memory safety technique is ridiculous.
You can think of it as the rather classic "Vec of struct + numeric IDs" that is used a lot e.g. in Rust to represent complex graph-like structures.
This combined with bound checking is absolutely memory safe. It has a bunch of correctness issue that can arise due to index confusion but those are not safety issues. When combined with some kind of generational counters those correctness issue also go away but are only caught at runtime not at compile time (and they incur a runtime cost).
Rust's memory safety is about avoiding liveness issues (that become type confusions since all memory allocators will reuse memory for different types), nothing more, nothing less.
> Curséd With an acute accent, that should be roughly /ˌkɜːrˈseɪd/ “curse-ay-d”. (Think “café” or “sashayed”.) The stylised pronunciation being evoked is roughly /ˈkɜːrˌsɛd/, “curse-ed”, and would be written with a grave accent: “cursèd”.
Meta comment, but I really like the formatting of the blog post! It reminds me of the early days of the web, when text was king and content was king. I particularly like the sidenotes in the margins approach. (Hope the author sees this comment :) Hats off)
Yeah the author always uses this in his blog about his language, Vale (which is very unfortunately not being developed anymore, at least for now). The other posts are also worth a read: https://vale.dev/
I’d love to see a language that kept everything as familiar as possible and implement memory safety as “the hard bit”, instead of the Rust approach of cooking in multiple different new sub languages and concepts.
Safety requires unions to be safe, so unions have to become tagged enums. To have tagged enums usable, you have to have pattern matching, otherwise you'd get something awkward like C++ std::variant.
Borrow checking works only on borrowed values (as the name suggests), so you will need something else for long-lived/non-lexical storage. To avoid GC or automatic refcounting, you'll want moves with exclusive ownership.
Exclusive ownership lets you find all the places where a value is used for the last time, and you will want to prevent double-free and uninitialized memory, which is a job for RAII and destructors.
Static analysis of manual malloc/realloc and casting to/from void* is difficult, slow, and in many cases provably impossible, so you'll want to have safely implemented standard collections, and for these you'll want generics.
Not all bounds checks can be eliminated, so you'll want to have iterators to implement typical patterns without redundant bounds checks. Iterators need closures to be ergonomic.
…and so on.
Every time you plug a safety hole, it needs a language feature to control it, and then it needs another language feature to make this control fast and ergonomic.
If you start with "C but safe", and keep pulling that thread, nearly all of Rust will come out.
The problem is that it is very easy to write non-GC'd code in a GC'd language, but the other way around it is much much harder.
Therefore, I think the fundamental choice of Rust to not support a GC is wrong.
It's surprising to see an article with such a large encompassing of different techniques, hybrid techniques and design interactions with the type system, but is more surprising that a whole dimension of memory (un)management was left out: memory fragmentation
It's probably because fragmentation isn't a safety issue. (In the sense of 'safety' being discussed here.)
I like many of the ideas of Rust, but I still think it is an unsuitable language for most projects. The problem is that it is very easy to write non-GC'd code in a GC'd language, but the other way around it is much much harder. Therefore, I think the fundamental choice of Rust to not support a GC is wrong.
It just runs at compile time. Bonus feature, it helpfully prevents a number of common bugs too.
I like many of the ideas of Rust, but I still think it is an unsuitable language for most projects. The problem is that it is very easy to write non-GC'd code in a GC'd language, but the other way around it is much much harder. Therefore, I think the fundamental choice of Rust to not support a GC is wrong.
It does have a GC. It just runs at compile time. Bonus feature, it helpfully prevents a number of common bugs too.
If you have to do it yourself, then it does not "have" a GC.