1. There are functional dependencies and multi-parameter type classes. No GADTs (yet?) or existential types (yet?). 2. Records are being implemented but it's f

1. There are functional dependencies and multi-parameter type classes. No GADTs (yet?) or existential types (yet?). 2. Records are being implemented but it's far from being a dealbreaker, in the sense that thousands of production lines of Coalton have been built without needing them. It's just not ergonomic to shuffle around and pattern match against record-like data. With pattern matching in function arguments, things are at least easier. 3. All Coalton functions compile to Lisp functions. There's a guide that describes what is promised about interop (https://github.com/coalton-lang/coalton/blob/main/docs/coalton-lisp-interop.md https://github.com/coalton-lang/coalton/blob/main/docs/coalt...). 4. Since Coalton functions are Lisp functions, you can call (unconstrained) functions directly. However there's a lot of room for improvement. There's an open issue to make a dedicated Coalton REPL that can show types and not require COALTON to be typed. 5. Coalton is developed as an open source project to build tools at HRL Laboratories, so it does receive sponsorship. Yes, HRL is hiring. Feel free to send me an email to the address in my profile. As seems to be the case with any "serious" programming language, there's always another thing to do—seemingly perpetually—to make said language useful enough for "serious" use. :)