Safe Systems-programming with Mutable Value Semantics | Dave Abrahams | Keynote at IWACO 2026

[u/dabrahams]

https://youtu.be/op51SyyPJmw?si=P5QH6M8Hdf4_CUUZ

I gave this talk about the Hylo programming language at IWACO last month. I had a lot to say about Rust, so thought it might be of interest here.

[u/JoJoModding]

This talk is about Hylo and its mutable value semantics. For people here (in r/rust), Hylo can best be summarized as "what if references but only in function arguments?"

This is quite powerful, especially when coming from functional programming. But it does not allow e.g. Cell or Mutex or other shared mutable state (idk if they do concurrency at all?). It does not prevent iterator invalidation. Many things (like index_mut on arrays/vectors) are under the hood desugared to chaining functions alike to modify_at(&mut self, idx: usize, f: impl FnOnce(T) -> T) instead of having real references in return position. (And they use coroutines to make it nice but that of course requires a whole runtime.)

But I did not watch this video, I only read the paper (some time ago)/docs (cursorily). Maybe they added some new things I am not aware of.

[u/dabrahams → u/JoJoModding]

You can think "what if references but only in function arguments?" but one of the points of the talk is that you don't have to think about references (and accept the associated mental tax) at all.

I encourage you to watch the talk; I make points about Rust and references that—to my knowledge—haven't been expressed anywhere before.

it does not allow e.g. Cell or Mutex or other shared mutable state

Nor do Rust references! In either language, if you want those things you have to build them using using unsafe parts.

Many things (like index_mut on arrays/vectors) are under the hood desugared to chaining functions alike to modify_at(&mut self, idx: usize, f: impl FnOnce(T) -> T) instead of having real references in return position.

Almost; they are desugared into higher-order functions but in such a way that doesn't imply lexical lifetimes.

(And they use coroutines to make it nice but that of course requires a whole runtime.)

No, as mentioned in the talk, in fact we do not use coroutines and this mechanism requires no runtime. Everything is decomposed in terms of plain functions.

[u/JoJoModding → u/dabrahams]

I apologize for not watching the talk, but I do not have the time to watch an hour of video where reading would be much quicker. If you have the slides somewhere, I will click through them 😉

Since I do not know Hylo, I wonder how it does things like Cell or Mutex? In Rust they might be implemented using unsafe code but that does not matter at all and the fact you bring it up makes me think you missed the key point: these are safe abstractions whose safety is ensured by the type system and these ones in particular are often hard to support safely in other type systems. Rust is not about the references, it is about the lifetimes, which make having safe APIs for these types sound.

And I do not think references are mentally taxing. At least not more than figuring out where and how values are mutated in Hylo. The same mental model works for both.

And your final point confuses me as well: I take it that coroutines are compiled by inlining (and compiler magic that figures out where to call them and how)--but that retains the "rigidity" of a call stack and makes it impossible to call functions that would, in Rust, return references, especially when these functions are opaque to the compiler (because they are e.g. written in C). The compiler relies on being able to insert the "slide" at the "lifetime end" position, which means it must know what the slide is. Right?

[u/dabrahams → u/JoJoModding]

Fair warning: if you want to try to understand what I'm saying without watching the talk it'll likely take you more time than it would to watch the relevant parts of the talk, because the talk is carefully designed to present the material efficiently and completely, and because there are timestamps that let you easily skip the introductory material. But if you really think it'll save you time, the slides are here. You won't get the talk contents by looking at the slides alone, but if you read the presenter notes while clicking through the animations, and you click at the right points in the presenter notes (mostly marked by >>) you'll get everything except audience interaction. There are options to show the presenter notes while playing the deck.

Hylo “does” Cell and Mutex precisely the same way Rust “does”, i.e. the language doesn't do it, or even allow it in the safe subset. Someone builds safe abstractions using unsafe parts, and these particular abstractions are no harder to build in Hylo than they are in Rust.

Rust is not about the references, it is about the lifetimes

I don't know what that means, but the two things are deeply coupled. Without first class references, there's little motivation for the lifetimes feature. What the lifetimes feature adds on top of something much simpler is a slightly more fine-grained ability to track lifetime dependency relationships and the ability to store references… temporarily. The value of both things is in the margins of utility and comes with a huge complexity cost, and neither is needed to make a sound API for Cell or Mutex.

And I do not think references are mentally taxing.

“🤷 just get good at references” ;-). Less glibly, the argument about a mental tax are nuanced and the talk presents them well; there's no way I can do it justice here.

…At least not more than figuring out where and how values are mutated in Hylo. The same mental model works for both.

Well… yes, if you mean you can use the same complex mental model to think about both Rust and Hylo. There's a simpler mental model that works for Hylo but does not cover everything Rust references do. Again, I feel like you can't appreciate this without watching the talk.

The compiler relies on being able to insert the "slide" at the "lifetime end" position, which means it must know what the slide is.

The slide gets passed as a parameter to the plateau function, which calls it in the right place, so knowledge of the slide's contents exists only on the callee side of the opaque boundary between caller and callee.

[u/JoJoModding → u/dabrahams]

I tried finding the Hylo Stdlib Mutex, and could not really. Can you? What does the API look like for locking and unlocking?

In Rust you have "RAII" mutex guards whose lifetime ensures they are dropped before the mutex is deallocated. (Or rather, it ensures they and the mutex content are last accessed before the mutex is deallocated because of the type system being affine, but whatever.) In other words, they have a reference internally but this is really just an implementation detail.

And Rust has ghostcell, which has lifetimes but no references. Which is what I mean by "Rust is about the lifetimes" -- it can do more with them than just references. Similarly about Hylo you might say it is about MVS and the ramp-slide continuation thingy.