https://news.ycombinator.com/item?id=14780381 shows a few errors that provide typo protection, no type declaring needed
https://news.ycombinator.com/item?id=13389287 shows the optimization warnings
https://news.ycombinator.com/item?id=12222404 shows it can even delete unused code thanks to type inference
There's also a handful of attempts to bring stricter type checking guarantees on top as a library, but I haven't experimented with those. I'm very much in the crowd that doesn't find static types very valuable (apart from aiding performance) even for multi-million-line projects, but if I can get a few non-strict warnings like SBCL gives, that's a nice bonus, much like running a concurrent linter for extra warnings in <any lang>.
I liked Clojure a lot, but fell out of love once I realized how much it's still missing from the Common Lisp it was inspired from (non-bonkers OOP, condition system, and reader macros being the biggest to me), and also how its pervasive laziness is something I'd rather opt in to than vice versa. Some people feel the same about its immutability-by-default structures, I don't mind either way. (e.g. I can opt in to them in CL, that's fine, and Clojure's ways of opting out of them aren't bad either.)
If you want to try Haskell, work though a few tutorials and if it looks good, you can grab a free copy of my Haskell book https://markwatson.com/opencontent/haskell-cookbook.pdf There are much better Haskell books than mine though, my book just reflects my own learning process.
If you mean "repl-driven" in a stronger sense, in the sense of a livecoding repl-driven environment that supports building programs by interactively modifying them as they run, then about the only place you find full-featured support for that style of programming is in old-fashioned Lisp and Smalltalk systems. Maybe also in Factor, and arguably in FORTH (though with fewer conveniences).
There's no reason in principle that you can't have a full-featured repl-driven environment for a statically-typed language; I just don't know of any. That's not a big surprise, though. There aren't all that many of them for dynamically-typed languages, either. It takes a lot of work to build one, and the builders pretty much need to know up front what it is they're trying to build, which means they probably need to have seen one before. Most programmers haven't.
Static types aren't particularly an obstacle, but strong immutability is. A full-featured repl-driven livecoding environment wants the programmer to be able to inspect and change anything and everything in the live environment as it runs. Soft immutability is fine; it's okay if you have to say "Mother, may I?" before changing something. Hard immutability is a problem, though. If it's actually _impossible_ to change something, that's incompatible with the nature of a repl-driven livecoding environment. A programmer accustomed to livecoding environments will experience that impossibility as a bug in the environment.
The following is fine therein and statically type checks:
(let ([x (if (condition) "string" (list "a list"))])
(if (string? x)
(string-length? x)
(length? x)))
However, when using a language with a great typesystem, the need for a REPL is just much less. You mostly don't need to try things out because the types guide you. Therefore these languages might have a REPL and it might be useful, but REPL-driven is not really necessary.
> I always wish that it would become unnecessary to have to choose between stability and extensibility
Stability, extensibility, low language-complexity. Pick 2.
Stability - one of Clojure's core tenets.
Low language complexity - not much more than EDN and everything is an expression, plus a few extras like destructuring. Certainly simpler than any other language I have used.
Extensibility - again, one of Clojure's strong points with macros.
As for "Type systems removing the value of a repl" again, I disagree. Repl driven development is as much about exploring the problem than it is writing code.
> Repl driven development is as much about exploring the problem than it is writing code.
Which is exactly what types give you. This even coined the term "type driven development" (same as "test driven development" on purpose").
I'd call it "robustness".
One language which is explicitly designed to have first-class hotloading support and static types is Mun. It's not production ready, but it was born out of frustration over the dynamically typed nature of Lua while appreciating the benefits it brought to extensibility and rapid prototyping.
For me Lua has the iterative part, but no types. The iterative part makes LÖVE an attractive target for gamejam developers, who don't want to be constrained by compile-restart cycles when they don't yet understand what every aspect of the finished game will look like.
My hope is yes, in that it's just that the work hasn't been put in yet to create to create the equivalent of Typescript for Clojure or Lua that compiles down to the actual, extensible language.
I always wish that it would become unnecessary to have to choose between stability and extensibility when selecting a programming language. Having a Clojure with static types or a typed Lua (Teal) would put us so much closer to that goal.