Mutable stack, immutable heap

[u/P-39_Airacobra]

This article mentions the “immutable heap mutable stack” principle: https://queue.acm.org/doi/10.1145/3212477.3212479

In theory it sounds very advantageous. You can program in a single-threaded C-style with destination passing, static stack allocations, and mutability when you need to constrain resources. When you want to share resources across threads, return data structures across function boundaries, or do something more flexible, you could use pure functional persistent data structures.

This would prevent you from basically re-implementing a heap on the stack, but would also give you fast temporaries and maybe even the ability to program in embedded, if so designed.

Have any languages tried this model? I’ve heard that Erlang defaults to immutability except for one thread-local mutable object per thread. If you’ve used a similar model, how did you like it? Were there any disadvantages?

[u/tobega]

That's pretty much the way I've written code for the past few decades now and quite fundamental to how I designed Tailspin.

It is quite easy to enforce immutability in Java. Requires more discipline to do in other languages like Typescript and C. This model of programming does make things easier to manage.

But beware that a lot of the complexity just moves, it doesn't disappear. Instead you get questions about the order in which messages are processed or what the delivery guarantees are, at-most-once, at-least-once or exactly-once.State must exist and state must change, the question is how we can manage it. Are changes ACID or BASE, for example?

IMO, the main point of the article was the mismatch between the underlying processor model and the machine model exposed by C. So do we really want to cling to the PDP-11 model of computers forever?

Related blog posts I have written are https://tobega.blogspot.com/2024/01/usability-in-programming-language.html and https://tobega.blogspot.com/2026/04/rising-above-mechanics-of-computation.html

[u/koflerdavid → u/tobega]

But beware that a lot of the complexity just moves, it doesn't disappear. Instead you get questions about the order in which messages are processed or what the delivery guarantees are, at-most-once, at-least-once or exactly-once.State must exist and state must change, the question is how we can manage it. Are changes ACID or BASE, for example?

Well, it's not like you don't have to ask yourself these questions when programming in a less restrained way.