5 ms·
Some more things I see coming soon: * Decoupled allocation, to use any allocator with any existing code. Cone has some really cool things on the way here, wher
by verdagon 5y ago
Some more things I see coming soon:
* Decoupled allocation, to use any allocator with any existing code. Cone has some really cool things on the way here, where we can package up allocators into modules and others can import them and use them [0]. Odin is also trailblazing here, with its implicit allocator "context" parameter [1]. Zig does this in an explicit way in its standard library [2].
* First-class isolated regions, where certain areas of memory cannot point to each other, but within a particular region we can freely mutably alias. Vale [3] and Verona [4] are doing some interesting experiments here.
* Better static analysis, to close the gap between memory-managed languages and C. Lobster's algorithm is very impressive here [5], and Vale is attempting an "automatic Rust" approach [6].
* True "structured parallelism", where we can "freeze" all existing memory and freely access it in parallel from a loop's body. Pure functional languages might be able to do this, but it would be interesting in an imperative language. Rust can almost do this, but can only share things with Sync.
* Blending the borrow checker with other paradigms. Cone is going all-in on this concept [7], and looks really promising. The pieces are also there in D and Vale, but we'll see!
I also have some things on my wish list (full deterministic replayability!) but they aren't really on the horizon yet.
(Disclaimer: I work on Vale, which aims to bring many of these features into the mainstream)
[0]: https://cone.jondgoodwin.com/coneref/refregionglo.html https://cone.jondgoodwin.com/coneref/refregionglo.html
[1]: https://odin-lang.org/docs/overview/#allocators https://odin-lang.org/docs/overview/#allocators
[2]: https://ziglearn.org/chapter-2/ https://ziglearn.org/chapter-2/
[3]: https://vale.dev/blog/zero-cost-refs-regions https://vale.dev/blog/zero-cost-refs-regions
[4]: https://www.microsoft.com/en-us/research/project/project-verona/ https://www.microsoft.com/en-us/research/project/project-ver...
[5]: https://aardappel.github.io/lobster/memory_management.html https://aardappel.github.io/lobster/memory_management.html
[6]: https://vale.dev/blog/hybrid-generational-memory https://vale.dev/blog/hybrid-generational-memory
[7]: https://cone.jondgoodwin.com/coneref/refperm.html https://cone.jondgoodwin.com/coneref/refperm.html
- c0balt 5y agoI might also want to add that rust allows decoupled allocation rn. There are some popular allocators, like jemalloc, but also some project specific ones, especially for some custom OS no-std projects. Edit: See https://docs.rust-embedded.org/book/collections/index.html#using-alloc https://docs.rust-embedded.org/book/collections/index.html#u... for a through explanation
- moldavi 5y agoSomething about Odin I like is that you can have multiple allocators, and use a bump allocator for just a specific call (and its subcalls), and afterward free it all at once, and go back to normal heap allocation. It would be cool if Rust offered a built-in way to do that too.
- ameliaquining 5y agoStrictly speaking, Rust doesn't need this as a built-in language feature, because its design allows it to be implemented as a third-party library: https://docs.rs/bumpalo https://docs.rs/bumpalo The biggest problem is that there's some awkwardness around RAII; I'm not sure whether that could have been avoided with a different approach. Of course, ideally you'd want it to be compatible with the standard-library APIs that allocate. This is implemented, but is not yet at the point where they're sure they won't want to make backwards-incompatible changes to it, so you can only use it on nightly. https://doc.rust-lang.org/stable/std/alloc/trait.Allocator.html https://doc.rust-lang.org/stable/std/alloc/trait.Allocator.h... Or are you suggesting that the choice of allocator should be dynamically scoped, so that allocations that occur while the bump allocator is alive automatically use it even if they're in code that doesn't know about it? I think it's not possible for that to be memory-safe; all allocations using the bump allocator need to know about its lifetime, so that they can be sure not to outlive it, which would cause use-after-free bugs. I'm assuming that Odin just makes the programmer responsible for this, and if they get it wrong then memory corruption might occur; for a memory-safe language like Rust, that's not acceptable.
- verdagon 5y agoIt actually is possible to have decoupled allocation in a memory safe way. We have an open proposal for this in [0], for Vale. TL;DR: Have some bits in the malloc header which instruct the language on which deallocator function to use. I've never used Odin, so I don't know whether/how they'd keep it safe. [0]: https://docs.google.com/document/d/1243br9VVluZN0ZD9MVKSQMAwJbKO9ey9aJzmx6rnpAY https://docs.google.com/document/d/1243br9VVluZN0ZD9MVKSQMAw...
- ksec 5y agoOff topic question, how did you find out all these non-mainstream language that are doing interesting things and research? First time I heard of Cone and Vale. And I think your post deserve to be at the top. I wish I could super upvote.
- verdagon 5y agoThanks =) I suspect my post was penalized down from the top once I edited in those link citations. HN works in mysterious ways! I've mostly been in the https://reddit.com/r/ProgrammingLanguages https://reddit.com/r/ProgrammingLanguages subreddit and its discord server, and chat with these folks a lot, about interesting innovations. It's a fascinating time to be into programming languages!
- ModernMech 5y agoNon-mainstream languages tend to find their way to HN. Take a look at my favorite list, I favorite every PL posted here that I come across (over 250 so far)
- verdagon 5y agoWow, that's an impressive collection! Are there any that stood out to you? (I'm especially interested in new memory management techniques)