Does Julia Create a "1.5" Language Problem?

No, the only special handling is the lowering of the for loop. The union splitting is visible in @code_warntype and shows up the same if you replaced a looped iterate with any other method.

That’s possible, Python has a multipledispatch package and some OOP languages kind of have the syntax with function overloading. The problem is putting classes in real argument annotations (not the type hints Python has at most); I summed up the attempts I’ve seen in this comment. And those attempts were emulating Python, an OOP language with no formal type stability, and it’ll only get more awkward and brittle when considering that crucial feature. It becomes clearer why Lisp is the way it is.

I don’t remember where I read this, but someone speculated mimicking virtual method tables by fixing the specializations (and perhaps their return type) a runtime dispatch could do and throwing an error otherwise, even if the table was derived empirically from a running program. No syntax concept was provided, it was very speculative.

I think runtime dispatch is faster in Python than Julia, the type checking is less complicated at least, but in my experience this doesn’t bear out in practice because slower code only hurts the program’s performance if it occupies a significant portion of the runtime. Julia has some type inference recovery practices for the critical portions, Python has C-based libraries, it just evens out.

2 Likes