[rvense]

You build your system as a box that takes strings in and sends strings out. You then have to do a bunch of checks (as part of your de/serializing) at the boundaries only. Inside the box, all your logic and transformations are type safe, and indeed you can turn some logic issues into mechanically checked type-level issues, which are basically free unit tests.

[SOLAR_FIELDS]

I like this for lightweight applications. I imagine it could become a bottleneck for anything moderately heavyweight when it comes to data processing. Most web apps are designed to not do any heavyweight lifting on the client side, so it is a nice general paradigm for that.

[rvense]

Why a bottleneck? Static types don't have to add any runtime overhead. In fact, the type information isn't present at runtime at all in some languages. It's a compile-time guarantee that actually allows you to remove some runtime checks and assertions. And I think all bechmarks show that static languages are as a rule faster than dynamic languages.

If you're comparing two different designs in a statically language where one involves making lots of new types and the other just shuffles strings back and forth, then I can't say and it'd depend on the specific case. Generally, helping the compiler is a good thing, and obviously things like switching on an enumeration is much faster than a long line of string comparisons. Actually, strings are just a horrible datatype, so unconstrained and inefficient. Use strings less!