This seems to me like a very practical way to approach Clojure typing. Similar to the author, I have often needed to make a series of transformations on complex objects. Those transformations mostly depended on the presence of certain keys, so having strict types was unnecessarily rigid. Derived typing would also be useful, of course.

One point to appreciate about this approach is the flexibility in only worrying about the relevant pieces. In my case, I may be worrying about whether a continuous variable has been tagged "datetime", requiring additional processing steps. Merely checking for such tags allows the input data to implicitly direct the flow of the program, reducing the coupling between data and specific processing implementations.

I've had good luck with prismatic schema https://github.com/Prismatic/schema, which seems to be along a similar direction. It's fairly low commitment and can lead to big gains fairly quickly. I assume this would be similar.

    (def Customer {:customer-id s/Int, :address-id s/Int}

    (def ProcessedCustomer (merge Customer {:external-id s/Int}))

Important to note that this isn't STATIC typing (which detects errors at compile-time), rather this is more like a validation library to make sure structures have certain properties at run-time.

Not saying it isn't useful, in fact I have a project in which this would be a very good fit and I might even implement it there.

I've also been thinking about types, validation, and structure. I see room for various approaches, including static typing, validation, and more. For example, here's an in-progress library that I plan to build out soon: https://github.com/bluemont/shape

It would be interesting to see a "When structural-typing is better than prismatic/schema" section in the readme. I read the readme, and I don't see why you can't use something like s/validate instead of built-like. So instead of:

    (type! :Point (requires :x :y))
    (some->> points
         (all-built-like :Point)
         (map color)
         (map embellish))

To keep it simple, as in the first example of the whirlwind tour, we could use:

    (def Point {:x s/Any :y s/Any})
    (some->> points
         (s/validate [Point])
         (map color)
         (map embellish))

It's good that structural-typing does not use macros, instead building ontop of specter which is pretty cool. So is there a performance enhancement?

It's clear that one should use structural-typing where an expertise with specter has been attained, Not sure when else it's the best choice.

Our software system currently uses Redis as a central bus, and around that we have a dozen apps that send a hashmap back and forth among themselves. We use Carmine/Nippy to serialize and deserialize the hashmap, so we never have to think about anything other than a hashmap. All the bugs we face are because of missing or misused fields in the hashmap. For us, a combination of structural typing and Nippy could potentially protect us from 90% of the bugs we have seen so far.

"somewhat inspired by Elm". We are seeing a trend here.

Speaking as one who is trying to use more functional languages and starting to love Elm.