Hacker News Reader

We're trying to highlight that most of the work you're doing to make sure the interfaces are well defined and match up manually can easily be done by a type checker, as you would have if you wrote this as a single application.

View on HN

How are you going to handle updates and migrations of types? Something I've been thinking about in terms of dependently typed APIs is versioning and migration - but more at the code ecosystem level than in terms of running systems that can't be turned off. But there is kind of a similarity there. You can think of the ecosystem of written programs as kind of a distributed system. Would be nice to give library authors the tools to more gracefully migrate their consumers code in a type directed way, and to highlight potential problems prior to deployment, but this could equally apply in a distributed computing context.

Welcome to Erlang/OTP "releases" where the folklore is that Ericsson engineers spent as much time testing releases (read: state migration code) as they did application code.

Interesting. Yeah, from what I understand the Erlang philosophy was to just throw out the idea of a type system and deal with faults dynamically, which is understandable given the time the language was created. But given what we've learned about type systems in the intervening years, it would be super nice to leverage a type system for this, and greatly reduce the testing overhead.

I'd love to see this in an event sourcing context too. This paper, “The Dark Side of Event Sourcing: Managing Data Conversion”, seems to hint at there being some interesting algebraic foundations to splitting and merging streams, adding new fields, etc: http://files.movereem.nl/2017saner-eventsourcing.pdf

Reply on news.ycombinator.com