[rlmark]

Great question.

There are indeed tradeoffs; as an example, one thing that trips folks up in the "save typed values without encoders" world is that a stored value of a type won't update when your codebase's version of the type updates. On its face, that should be a self-evident concern (solvable with versioning your records); but you'd be surprised how easy it is to `Table.write personV1` and later update the type in place without thinking about your already written records. I mention this because sometimes the lack of friction around working with one part of Unison introduces confusion where it juts against different mental models.

Other general tradeoffs, of course, include a team's tolerance for newness and experimentation. Our workflow has stabilized over the years, but it is still off the beaten path, and I know that can take time to adjust to.

I hope others who've used Unison will chime in with their tradeoffs.

[scuff3d]

These seem to be mostly related to difficulties around adapting to a new programming model. Which is understandable, but do you have examples of more concrete tradeoffs?

For example, I don't think many would argue that for all the upsides a functional language with immutable state offers, performance can take a significant hit. And if can make certain classes of problems trickier, while simplifying others.

Surely with a model this unique, with the payoffs come costs.