Comment by Someone
1 day ago
> Rust has only succeeded in making a Memory Safe Language without garbage collection via significant complexity (that was a trade-off). No one really knows a sane way to do it otherwise, unless you also want to drop the general-purpose systems programming language requirement.
> I'll be Very Interested if they find a new unexplored point in the design space, but at the moment I remain skeptical.
They’re the somewhat sane “don’t allow dynamic allocations; just dimension all your arrays large enough” approach from the 1950s (Fortran, COBOL).
A variant could have “you can only allocate globals and must allocate each array exactly once before you ever access it”. That would allow dimensioning them from command line arguments or sizes of input files.
The type system then would have “pointer to an element of foo” types (could be implemented old-style as indices)
Yes, that would limit things, but with today’s 64-bit address spaces I think it could work reasonably well for many systems programming tasks.
It definitely would be significantly less complex than rust.
> Yes, that would limit things, but with today’s 64-bit address spaces I think it could work reasonably well for many systems programming tasks.
As long as the systems programming tasks are strictly sequential, without threads, coroutines or signal handlers.
There is more to memory access than just out-of-bounds access which could be solved by just allocating every accessed memory page on demand as a slightly alteration of your variant.
Good points. As to signal handlers, I’m not aware of any language that fully supports them by making it impossible to call other than async-safe functions (https://man7.org/linux/man-pages/man7/signal-safety.7.html) from asynchrony signal handlers.