Honestly you're defending this a little too much. Nobody cares about an unfinished LISP spin-off that may be production ready some day. The OP's point still stands, CL lacks static types.
This is frustratingly common with niche languages (and I am not saying CommonLisp is not productive, itself). If people are criticizing a missing feature in a language and the response is "Yeah, but we have some bespoke third-party solution available here," it's like the responder has missed the whole point.
Common Lisp, as defined by the standard, does not have static types. As such, Common Lisp will never have static types as a built-in language feature. For the people who care about built-in languages features alone, and not what the library ecosystem has to offer, the discussion could very well end there.
Most programmers seem to care what the library ecosystem has to offer, though, so long as said libraries are actually working and useful. Is Coalton such? It's a technology that has been in development for around 5 years, that is presently used for commercial purposes, and that offers an approach to static typing a la Haskell's type system within Common Lisp projects. It's not a slapdash weekend project that purports to do something, only to find it really only does 5% of what was advertised. All things considered, it seems reasonable to suggest it as an option for static typing.
Production-readiness is a gradient. (Or, less usefully, it's a binary quality determined by the question, "Is it used in production at a company?") I wouldn't personally use Coalton to build real-time rocket control software for many reasons, the most important of which is that it's not billed as a "1.0" product. But I also wouldn't dismiss it because it has a bug tracker with an exposition on an intrinsic limitation of Hindley-Milner type inference. Coalton is a tool built in Common Lisp that is used in production, today, now, as documented by those links in my GP comment. You can even be paid real money to develop Coalton and/or software in Coalton.
Look, I get that people are tired of this peculiar rhetoric, the
> Lisp has macros therefore it's always one step away from implementing any popular language feature.
kind. For a variety of reasons, it's usually not true in a practical sense, and ultimately leaves the would-be user holding the bag.
I suggest, however, that Coalton really isn't a smokescreen that just exists to duly check off a "Has Static Types?" feature checkbox for Common Lisp.
This is frustratingly common with niche languages (and I am not saying CommonLisp is not productive, itself). If people are criticizing a missing feature in a language and the response is "Yeah, but we have some bespoke third-party solution available here," it's like the responder has missed the whole point.