I've not found immutable data to be the big win people tout it as. In most of what I do acting on stale data is just as bad, which means I wind up needing a lock anyway.

Doing a < b and taking an action based on that result is as harmful with stale data.

I'd like to tell you that stale data will always be a thing in any serious application because light only travels so fast. Therefore, you'll need to have sensible logic in the face of stale data either way, so it's not so bad as you think.

...and while that's true, I'd still like to hear the opinion of someone more knowledgeable because it's an issue that's been bugging me too.

This is a fair point: immutable data is just part of the solution. To get the win, you need to toss out all references to the old data when you update it: then you ensure that you can't access "stale" data. This requires some discipline, either manual (e.g., reusing the same variable name for the old and new bindings to ensure the stale binding is shadowed) or automatic (e.g., linear types).

But the data can't be stale, because `a` and `b` are immutable

In the case of Erlang, how would immutable data help? The code all run in single thread execution path in each process; there's no need for lock anyway. Each process can't access data of another process.

Immutable data (along with per process heaps) makes the garbage collection very simple.

Isn't one of pony's strengths, that it's doing GC better?

As a developer writing code, I don't particularly care whether GC is simple or complicate, as long as it works correctly. That's the compiler writer's job.

A fundamental strength of Erlang is that as many things as possible are simple, which makes it easy to know that it works correctly and under what conditions it doesn't work so well [1]. The compiler writer isn't necessarily the GC writer either; although, it's probably the same couple of people in Erlang.

[1] If you touch a lot of ref counted binaries, without generating enough garbage on the process heap to trigger GC. GC time scales with process heap, if you get a large enough backlog in your mailbox, GC may reduce the throughput to the point where you can't recover, although doing selective receives if you don't trigger the optimization for new references[2] is much more painful than GC scaling.

[2] http://erlang.org/pipermail/erlang-questions/2010-June/05175...

EDIT: from slides about r19 GC [3], it seems that both of the GC issues I mentioned have had targeted changes: for refcounted binary issues, there's now a 'virtual binary heap' to help trigger GC; for GC with a big mailbox, there are different allocation strategies available which may help.

[3] https://www.erlang-solutions.com/blog/erlang-19-0-garbage-co...