4 ms·

Not really a "smaller Rust", but certainly a language that does Rust-y things (lifetime analysis) without getting in the users way (it's all automatic) is http:

Not really a "smaller Rust", but certainly a language that does Rust-y things (lifetime analysis) without getting in the users way (it's all automatic) is http://strlen.com/lobster/ http://strlen.com/lobster/ It does "compile time reference counting" (http://aardappel.github.io/lobster/memory_management.html http://aardappel.github.io/lobster/memory_management.html) which moves almost all memory management to compile time. The end result is a language which you can program while mostly ignoring ownership, and still get the benefits. The article also mentions the desire for "control-flow-capturing closures" as in Kotlin, which Lobster has too (non-local returns).

seg_lol 6y ago
> Lobster combines its original (runtime) reference counting with a lifetime analysis algorithm, to get “compile time reference counting”. Interesting. Do you think it would be possible to have a prototype language that compiled to Rust and used this algorithm to wrap values in an Arc<T> ? How does Lobster handle mutation? The Rust type system can make some pretty cool guarantees about code. If you were running in ring-0, is there anything that the MMU could do to aid your system? New instructions that don't yet exist? You might be interested in Dune, http://dune.scs.stanford.edu/belay:dune_slides.pdf http://dune.scs.stanford.edu/belay:dune_slides.pdf BTW, I dabbled in E on my Amiga 500 back in the 90s, we found it on some BBS that had the warez. :)
- Aardappel 6y ago
  The current implementation is such that every heap allocated object does have a refc field, but it is simply unused for lifetimes managed at compile time. It would be possible to do further analysis to able to separate out objects which guaranteed never participate in runtime refc updates, and the omit that field. That would be similar to be able to emit to a language like Rust and select an Rc type or not. There are other places where the current algorithm may rely on Lobster specifics (such as closed world compilation and flow-sensitive typing). Mutation is not protected from having multiple owners/borrowers like in Rust. Lobster does not have shared-memory concurrency (only distributed), nor interior pointers, nor pointers to stack objects (always copied), so its situation is a whole lot simpler. It does "lock" local variables for mutation after borrowing. I don't think there's any need for anything MMU in what I am doing. Most is compile time. At runtime only the remaining refc ops happen. What did you have in mind? Hah, I guess there was a paid version of Amiga E that was on those BBS-es :) The free version was limited to emitting 32K executables (which was a lot of code back then).

seg_lol 6y ago

> Lobster combines its original (runtime) reference counting with a lifetime analysis algorithm, to get “compile time reference counting”. Interesting. Do you think it would be possible to have a prototype language that compiled to Rust and used this algorithm to wrap values in an Arc<T> ? How does Lobster handle mutation? The Rust type system can make some pretty cool guarantees about code. If you were running in ring-0, is there anything that the MMU could do to aid your system? New instructions that don't yet exist? You might be interested in Dune, http://dune.scs.stanford.edu/belay:dune_slides.pdf http://dune.scs.stanford.edu/belay:dune_slides.pdf BTW, I dabbled in E on my Amiga 500 back in the 90s, we found it on some BBS that had the warez. :)

Aardappel 6y ago
The current implementation is such that every heap allocated object does have a refc field, but it is simply unused for lifetimes managed at compile time. It would be possible to do further analysis to able to separate out objects which guaranteed never participate in runtime refc updates, and the omit that field. That would be similar to be able to emit to a language like Rust and select an Rc type or not. There are other places where the current algorithm may rely on Lobster specifics (such as closed world compilation and flow-sensitive typing). Mutation is not protected from having multiple owners/borrowers like in Rust. Lobster does not have shared-memory concurrency (only distributed), nor interior pointers, nor pointers to stack objects (always copied), so its situation is a whole lot simpler. It does "lock" local variables for mutation after borrowing. I don't think there's any need for anything MMU in what I am doing. Most is compile time. At runtime only the remaining refc ops happen. What did you have in mind? Hah, I guess there was a paid version of Amiga E that was on those BBS-es :) The free version was limited to emitting 32K executables (which was a lot of code back then).