Well, every language requires you to write serialization code unless you have the rare case where your datastructures line up 1:1 with your serialized structure over the wire. And the 1:1 case is already trivial with Elm. So I don't really understand the complaint.

Frankly, with something like serde in Rust, it's such a pain to deviate from the 1:1 case that you tend to stick to the 1:1 datastructure despite how suboptimal it is, maybe manually transforming it after parse time if you can be bothered. I don't find that to be any superior to Elm's simple combinators.

My experience with Elm's codecs is that there's a small learning curve if the concept is new to you. And then after some real world experience you wonder how it was ever alien at all. I wish I had it in every other language I've worked with.

The complaint is that humans have to write and maintain code that the compiler could be writing. The more trivial, the more annoying it is for a human to do the compiler's work for it. I find 1:1 cases quite common when developing JSON endpoints in the back-end of a thick client.

To my understanding, derived serialization is in conflict with type inference. You can have one or the other but it is very complex and difficult to have both. Maybe one day Elm will get it but it is not a trivial implementation and there are other, more important issues that take precedence.

No, it works fine and inference is completely orthogonal. Haskell and PureScript both have this. You define types and the serialization instances are derived. Elm cannot do this, because it does not even have type classes.

http://hackage.haskell.org/package/aeson-1.4.5.0/docs/Data-A...