Substrates 2025

The Substrates 2025 workshop was held earlier this year (2025-06), and the submitted vision statements have quite a few ideas that I believe are of interest here. The proceedings were originally private, but over time the authors all agreed to publish them, and they’ve just recently been collected and published. (I believe @Bosmon was at least partly involved in this publishing process. Thanks for working on this!)

5 Likes

Thanks for the link, going to read them over coffee this morning.

  • Gilad Bracha: chatbot woo, but VR
  • Clayton Lewis: Also chatbot woo
  • Jonathan Edwards: Asks a valuable question: “Can the stack be pluralistic”, and goes on to answer it with a kind of no.
  • Tom Larkworthy: Optimistically using the web stack to make long lasting software
  • Clemens Nylandsted Klokmose: Really quite good, clear specification for liveness
  • Joel Jakubovic: Didn’t understand anything at all, conflates substrate and malleability somewhat
  • Tomas Petricek: Was hoping for more, nice writing, there is no mention of AI making this one quite commendable.
  • Antranig Basman: Full of interesting links! First time hearing about Boxer
  • Stephen Kell: Excellent point, although, I got spooked by the idea that one stack must inevitably triumph over the others. Reminds me of Jonathan Edwards’
  • Yann Trividic: Grounded, eloquent and no-bullshit exposition of file the format synchronization problem that nobody wants to think about, loved this one.
  • Camille Gobert: Similar point to Yann, but goes at length to define what a computer is and what it does tho. Makes an interesting point about living with bad systems instead of razing everything to the ground every time, which feels fresh.
  • Steven Githens: Call to action to make things simpler, but doesn’t go too deep on how to get from here to there. Throws the words easy and simple around a lot. Author should probably read Umberto Eco’s Search For A Perfect Language
  • Pavel Bažant: Structural editing and rich text programming language musings
  • Patrick Dubroy: Clear vision statement, proponent of more research in systems thinking and new stacks, but non sequiturs into examples from the past that are hard to connect with the statement. Text in this document cannot be selected.. which feels a little bit like it’s trying to make a point
  • David Thomas: Wild, just wild. I don’t know what to say about that one. I mean, yeah, that would be nice. The optimism is high in this one, I think even Gilad is like woah there buddy!
  • Robert Hirschfeld: Felt incomplete, mentions stuff that is all behind ACM paywall
  • Luke Church and William Samosir: Fun one, the substrate is Phytoplankton. This might be my favourite one of the lot

Started reading reviews at the bottom of each paper, and.. damn, I want some of that cornucopia that Gilad Bracha is smoking, jfc

In summary, using Clayton’s words: Malleable substrates are like toothbrushes. You only want to use your own

6 Likes

That’s actually good advice for pretty much everyone in the space of programming language design!

1 Like

I finally finished a first reading of everything!

Many vision statements focus on a particular corner of computation space, but don’t explicitly say so. I hope that the discussions at the workshop helped to clarify this lack of consideration of the basic questions “for who?” and “for which use cases?”. That should then settle the question of whether or not there could be a single substrate for everyone and everything. My answer is “obviously no”, but then, pretending that a single substrate is achievable could well be a fruitful hypothesis for academic research.

The question of how to design, implement, and maintain any form of substrates gets too little attention overall. Many submissions point out the necessity to remove or at least weaken boundaries in a substrate, e.g. the boundary between data and code, or the boundary between different devices or different users. By Conway’s law, boundaries in software architecture reflect boundaries in the organizational structure of the people who build the software. What does this imply for substrates? How can the long-lasting work on and with a substrate, involving lots of people, be effectively coordinated with a minimum of institutional boundaries?

2 Likes