We tried Typed Clojure. A couple of times. We actually went back and forth between Schema and Typed Clojure a few times. We ended up abandoning the use of both (but we have been using clojure.spec fairly heavily since it first appeared).
We ran into a lot of the same problems with Typed Clojure that CircleCI talked about in their post.
When we first tried to introduce it, you couldn’t just annotate one or two functions – you had to annotate everything in a namespace (even if it was just to say “ignore this function”) if you wanted to avoid a giant wall of warning messages. In addition, if you used any third party libraries, it was very difficult to either come up with annotations for those functions or annotate your own code so Typed Clojure wouldn’t complain. Then there were situations where you just couldn’t satisfy Typed Clojure without refactoring your code (quite a few nil-punning idioms tended to defeat both its inference and its conformance).
We probably got about 5% of our code base annotated and checked but it was slow, painful work. We felt the annotations were often detrimental to readability (a complaint often leveled at type systems that don’t do enough inference). We also found that sometimes you’d refactor or enhance some code and the annotation would be outdated and then you’d have to wrestle that back into compliance (sometimes leading to more refactoring just to satisfy Typed Clojure).
If Ambrose can make it do more inference – and better support nil-punning idioms – as well as better handling the boundary between typed code and untyped code (there was a great talk about this specific issue in the context of Typed Racket at one of the Clojure conferences, as I recall?), then Typed Clojure might be more tenable.
I think gradual typing is a promising approach to adding more checking to Clojure code. I think some of Clojure’s idioms make type inference an extremely hard problem to solve.
Given that we now have clojure.spec, I don’t think that I would invest my time in trying to introduce Typed Clojure into our current code base at work. I’ll definitely keep an eye on the project, as it moves forward, tho’…