This depends a lot on what one means by richness I suppose. I'd say that Python, Javascript, mosts lisps that don't have CLOS, etc. are all dynamic languages with very non-rich type systems.

Julia's type system (and to a lesser extent Common Lisp's) are very different. They can do a lot of extremely powerful things with their type systems, just not (usually) static type checking (though even that's changing in julia land with JET.jl: https://github.com/aviatesk/JET.jl)

Yeah; I think the distinction with runtime types among dynamic languages is that you can always emulate any other system's dynamic type system with some amount of constant syntactic overhead in any other system. E.g. you could write a CLOS system or Julia's multiple dispatch in Javascript if you wanted. It would just be extremely ugly because you would have to wrap every function and every function call (so as to intercept the native function call and substitute your own).

Nonetheless though that's "only" a constant amount of (painful) syntactic noise per call, which means that it is conceivable for a library to provide this functionality. And in fact occasionally libraries will require users to wrap all functions in order to give those functions certain "superpowers."

It is of course nicer if it integrates very nicely with the language rather than being full of wrappers everywhere so there is still a lot of value in these runtime type systems being built from the ground-up with certain features in mind.

But it's a very different world from static types, where usually if one static type system is missing features of another, no amount of emulation will get you there.

I'm not sure that's a particularly convincing argument. Bolting a type system on a dynamic language is incredibly hard to do if you're trying to make a type system that's worth using. It's a fundamental language design problem, and if the type system is doing anything worth while, it'd probably take around a decade to make one that is reasonably sound and robust. At that level of commitment, one can just turn around and look at your static language and say "Well, couldn't you just implement a new language with a new type system in your language?" (assuming your language is turing complete). This really isn't that different.

Meanwhile, Julia's type system is actually a fundamental player in it's optimization schemes (the compiler essentially breaks up programs into statically typed chunks and optimizes those separately), so rather than inducing a constant overhead, the type system is responsible for some of the fastest code that's possible to write, including BLAS libraries that are competitive with OpenBLAS, BLIS, and MKL (https://github.com/JuliaLinearAlgebra/Octavian.jl/issues/24)

I think we're starting to talk past each other and this is falling into the well-rehashed pit of "are runtime types really 'types' or just semantically normal runtime assertions."

I'm implicitly talking through the lens of the latter and you're talking through the former.

Regardless I agree with your central point that Julia is doing cool things with runtime types and its design is what is giving it the ability to do such impressive runtime optimizations.

> I think we're starting to talk past each other and this is falling into the well-rehashed pit of "are runtime types really 'types' or just semantically normal runtime assertions."

Sorry, that wasn't the direction I was trying to go. I just meant to say that the work it'd take to make different type system in a dynamic language is approximately the amount of work it'd take to make a whole new language.

So I think from a practical POV, it's fair to think of the type system that comes with a given dynamic language as being more or less intrinsic to it, regardless of what one's philosophical stance is on types in dynamic languages generally.