4 ms·

It honestly depends on your use-case. For heterogeneous systems that may run different versions of your Erlang software, strictly-typed messages are not that gr

It honestly depends on your use-case. For heterogeneous systems that may run different versions of your Erlang software, strictly-typed messages are not that great, because you can't really ensure that all your systems are running the same version of the code that accepts messages. (This is why in Protobuf3, everything is optional, for instance) If you are a smaller organisation than, say, Google, ensuring compatibility between your systems is easier, so that's still doable. For in-VM messaging, since all types are accessible and enforceable, it's easier to have a common contract amongst all your actors since the risk isn't the same.

agentultra 6y ago
It can be done with a sufficiently expressive type system, I think. One area I'm experimenting is is a library I co-wrote[0] in Haskell that uses the type system to attach a "version" tag to a type so that your code knows what version of a record you're looking at (and also so that you can upgrade/downgrade records between versions if you need that as well). [0] https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs/Data-Migration.html https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs...
- lukevp 6y ago
  This seems like the right approach... We store persistent data in DBMSes, which have a schema defining the layout of our data, and use versioned migrations to upgrade the data. All new data either has optional parameters with default values for all new properties, or the app has to be taken offline and all versions upgraded at the same time to migrate. It seems reasonable to reflect this practice in all state based data representations within a language, not just in an external system. Is the reason this isn't done as a first class citizen of language design because it's too much work to write migrators for every data structure change?
  - agentultra 6y ago
    > because it's too much work to write migrators for every data structure change? I think that might be one factor. And writing that migration by hand would be another source of potential errors to sneak into your program without some static analysis to ensure the streams in your program are handling the version of the data specified. Making it easier to write migrators and have your whole program verified automatically has been working well for me.

agentultra 6y ago

It can be done with a sufficiently expressive type system, I think. One area I'm experimenting is is a library I co-wrote[0] in Haskell that uses the type system to attach a "version" tag to a type so that your code knows what version of a record you're looking at (and also so that you can upgrade/downgrade records between versions if you need that as well). [0] https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs/Data-Migration.html https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs...

lukevp 6y ago
This seems like the right approach... We store persistent data in DBMSes, which have a schema defining the layout of our data, and use versioned migrations to upgrade the data. All new data either has optional parameters with default values for all new properties, or the app has to be taken offline and all versions upgraded at the same time to migrate. It seems reasonable to reflect this practice in all state based data representations within a language, not just in an external system. Is the reason this isn't done as a first class citizen of language design because it's too much work to write migrators for every data structure change?
- agentultra 6y ago
  > because it's too much work to write migrators for every data structure change? I think that might be one factor. And writing that migration by hand would be another source of potential errors to sneak into your program without some static analysis to ensure the streams in your program are handling the version of the data specified. Making it easier to write migrators and have your whole program verified automatically has been working well for me.