Comment by verdagon | Hacker News Reader

Comment by verdagon | Hacker News Reader

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

[1]: https://odin-lang.org/docs/overview/#allocators

[2]: https://ziglearn.org/chapter-2/

[3]: https://vale.dev/blog/zero-cost-refs-regions

[4]: https://www.microsoft.com/en-us/research/project/project-ver...

[5]: https://aardappel.github.io/lobster/memory_management.html

[6]: https://vale.dev/blog/hybrid-generational-memory

[7]: https://cone.jondgoodwin.com/coneref/refperm.html

I 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#u... for a through explanation

Something 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.

Strictly 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

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.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.

It 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/1243br9VVluZN0ZD9MVKSQMAw...

Hmm. It seems the way this prevents use-after-free is by having the allocator's destructor check at runtime whether everything in it has already been dropped, and if not, abort the process. With bumpalo's default API (which seems to be designed to have the lowest possible per-allocation runtime overhead), that wouldn't work, because it deliberately doesn't keep track of whether the things in it have been dropped (and also because there's no header to store the bits in).

On the other hand, if you required an API along the lines of bumpalo::boxed, and also were willing to add a bit more runtime overhead on top of that (for the tracking bits and the allocation count), then this could be done in Rust as a third-party library. Each executable that transitively depended on it would have to opt in with #[global_allocator], though. Also, I personally would rather have an API where the compiler makes sure I don't screw this up, than one where the runtime crashes my program if I do; this is generally a common sentiment in Rust, and points towards a bumpalo-style API.

That Sounds cool. Also sounds like an interesting way to potentially optimize applications for specofic workloads, with e.g. optomizations that build on top of applications usage logs. Maybe in a far, far future an addition to LLVM or other optimizing compilers.

Edit: Spelling. PS: Though might also be an awesome way to shoot yourself in the foot.

Off 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.

Thanks =) 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 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!

Non-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)

Wow, that's an impressive collection! Are there any that stood out to you?

(I'm especially interested in new memory management techniques)

Reply on news.ycombinator.com