4 ms·
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 che
by cmeiklejohn 9y ago
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.
- bjz_ 9y agoHow 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.
- geogriffin 9y agoWelcome 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.
- bjz_ 9y agoInteresting. 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 http://files.movereem.nl/2017saner-eventsourcing.pdf