31–40 of 68 posts
Discussion on r/rust: https://www.reddit.com/r/rust/comments/gfgt1b/rustlike_langu...
I look at this and I think it's a innovative and promising idea - the freedom of a garbage collected language, but with the tracing done as a type-aware static analysis, and the cleanup code inserted at compile-time!
Discussion on r/ProgrammingLanguages: https://www.reddit.com/r/ProgrammingLanguages/comments/gfgn0... Discussion on r/rust: https://www.reddit.com/r/rust/comments/gfgt1b/rustlike_langu... I look at this and I think it's a innovative and promising idea - the freedom of a garbage collected language, but with the tracing done as a type-aware static analysis, and the cleanup code inserted at compile-time!
https://www.csail.mit.edu/event/safe-parallel-programming-pa...
https://chapel-lang.org/docs/master/builtins/OwnedObject.htm...
And a couple more with affine types, or algebraic effects.
Yes, this might be the future, but we are still far from the overall convenience of GC for common programming scenarios.
If anything one was to thank the Rust community for pushing more people to look into this area, regardless of its outcome in the language market.
Earlier quoted context omitted.
> One thing I'd like to see in modern languages is to encourage and simplify working with an (almost) entirely static memory layout, and make manipulations inside this static memory layout safe. This sounds interesting! What do you mean by (almost) static memory layout? Fixed sizes for everything in a contiguous region, or multiple growing arrays, or something else entirely? In recent time I have written a few progra…
I (mostly) returned to C a little while ago, and for smaller things I sometimes create the entire application state as a single, big struct that's made of many smaller nested structs, maybe with one or very few "layers" of dynamically allocated data dangling off from the static "root structure" (but only when really needed). A very simple example is an all-in-one application data structure like this: https://github.c…
You can still have modules per file, where the globals can be thought as members of a virtual root. And the globals can be either shared or private to the module.
I have seen very complex programs done like that. There are some advantages like proving the program does not run out of memory, but the problem is that you end up with code that is harder to reuse, harder to test, etc. as soon as you start sharing state.
But yeah, it is sometimes done like that.
If a language like this were to take off, I could see linter-style errors pop up that are not currently possible. "ERROR: maximum memory usage computed to be XYZ MB, which is higher than the speicified limit of 500MB" Now that would help keep the RAM bloat down!
As long as it still allows for arbitrary-length vectors - which I can't imagine it not - this would be impossible due to the halting problem. Or I guess, maybe you could derive a lower bound on memory usage, but you could not get an upper bound/exact number.
if (sz (sz)
else
throw "Size exceeds upper limit"Earlier quoted context omitted.
As long as it still allows for arbitrary-length vectors - which I can't imagine it not - this would be impossible due to the halting problem. Or I guess, maybe you could derive a lower bound on memory usage, but you could not get an upper bound/exact number.
What about allocation is only possible when you can prove the upper limit. So this is possible if (sz (sz) else throw "Size exceeds upper limit"
I haven't dug into the details a ton, but I am excited to see this! Would love to see more research in this direction. > micro-mitten's approach is significantly different from Rust's. Rather than depending on single ownership and a complex lifetime system, micro-mitten uses a series of data-flow analyses to statically approximate heap liveness. To be clear, Rust these days also looks at control-flow. This was what a…
Where can I learn more about this?
Earlier quoted context omitted.
What about allocation is only possible when you can prove the upper limit. So this is possible if (sz (sz) else throw "Size exceeds upper limit"
I'm saying you could know "it will use at least X memory", but you could never know "it will use at most X memory" unless you seriously cripple the language's capabilities
That means the language isn't always crippled, but you can get compiler enforcement for certain embedded programs.
Still interesting research though.