Comment by xorvoid
2 days ago
"Memory Safe No garbage collector, no manual memory management. A work in progress, though."
I wish them the best, but until they have a better story here I'm not particularly interested.
Much of the complexity in Rust vs simplicity in Go really does come down to this part of the design space.
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.
Folks like to mention Ada. In my understanding, Ada is not memory safe by contemporary definitions. So, this requires relaxing the definition. Zig goes in this direction: "let's make it as safe as possible without being an absolutist"
If you look at the Github, there's a design proposal (under docs/design) for that.
It looks like the idea at the present time is to have four modes: value types, affine types, linear types, and rc types. Instead, of borrowing, you have an inout parameter passing convention, like Swift. Struct fields cannot be inout, so you can't store borrowed references on the heap.
I'm very interested in seeing how this works in practice--especially given who is developing Rue. It seems like Rust spends a lot of work enabling the borrow checker to be quite general for C/C++-like usage. E.g. you can store a borrowed reference to a struct on the stack into the heap if you use lifetime annotations to make clear the heap object does not outlive the stack frame. On the other hand it seems like a lot of the pain points with Rust in practice are not the lifetime annotations, but borrowing different parts of the same object, or multiple borrows in functions further down the call stack, etc.
Not being able to store mutable ref in other type reduces expressiveness. The doc already mentions it cannot allow Iterator that doesn't consume container
https://github.com/rue-language/rue/blob/trunk/docs/designs/...
No silver bullet again
For future readers, please use this link: https://github.com/rue-language/rue/blob/b0867ccff77ee9957d6...
I am going to be cleaning these up, as they don't necessarily represent things I actually want to do in this exact way. My idea was to dump some text and iterate on them, but I think that's actually not great given some other process changes I'm making, so I want to start fresh.
Just to be clear, these proposals are basically scratch notes I have barely even validated, I just wanted to be able to iterate on some text.
But yes, there is going to inherently be some expressiveness loss. There is no silver bullet, that's right. The idea is, for some users, they may be okay with that loss to gain other things.
Yeah, that stuff is very much a sketch of the area I want to play in. It’s not final syntax nor semantics just yet. Gotta implement it and play around with it first (I have some naming tweaks I definitely want to implement separate from those ADRs.)
I don’t struggle with lifetimes either, but I do think there’s a lot of folks who just never want to think about it ever.
> 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.