Elektrine lite

← Feed

@zwarich@hachyderm.io

Post #3613075

2026-01-05 16:47 UTC

@slava@mathstodon.xyz @joe@f.duriansoftware.com @foonathan@fosstodon.org @dotstdy@mastodon.social @ianh@mastodon.social I thought about this some more the past few days and one of the things that I keep coming back to is that if you add mutation to your language you’re faced with the problem of data races, and the type system features for the elimination of data races don’t look all the different from ownership systems used by safe systems languages. There is Midori (https://www.cs.drexel.edu/~csg63/papers/oopsla12.pdf), Pony (https://www.ponylang.io/media/papers/fast-cheap.pdf), Verona (https://www.microsoft.com/en-us/research/publication/reference-capabilities-for-flexible-memory-management/), etc. Of course, you could take the Java/C# copout of making data races memory safe (and maybe tack on the Go approach of optional dynamic race detection), but the issues that arise from this model are not very easy to debug.

Replies (1)

  • @joe@f.duriansoftware.com 2026-01-05 16:50

    @zwarich@hachyderm.io @slava@mathstodon.xyz @foonathan@fosstodon.org @dotstdy@mastodon.social @ianh@mastodon.social yeah we tried the cop-out approach in Swift for a minute and didn't get too far either. debugging aside, aliasable mutations also pretty much totally kill any non-global optimization. i think "mutation requires exclusivity" is a good default, with Atomic/Cell/RefCell/etc. on the side for cases where you need less stricture, but maybe you can integrate those alternative mutations more smoothly into the language

    Open ##3613074