[jakobnissen]

I basically agree with subtyping (but not multiple dispatch). More importantly, I think it's important to recognize that Julia has a niche that literally no one can compete with - interactive, dynamic and high performance.

Like, what exactly is the alternative? Python? Too slow. Static languages? Unusable for interactive exploration and data science.

That leaves you with hybrids, like Python/Cython, or Python/Rust or Numba, but taken on their own term, these are absolutely terrible languages. Python/Rust is not safe (due to FFI), certainly not pleasant to develop in, and no matter how you cut your code between the languages, you always lose. You always want your Python part to be in Rust so you get static analysis, safety and speed. You always want your Rust part to be in Python, so you can experiment with it easier and introspect.

[mccoyb]

To clarify my comment: I agree that multiple dispatch is a very good language feature. I enjoy it, and I’m well-versed in the expression problem, yada yada.

That’s not what I meant by “method JIT architecture” — I meant calling back into the compiler at runtime to specialize code when the types are known.

[blindseer]

I think multiple dispatch (useful as it is) is a little overrated. There's a significant portion of the time where I know I have a closed set of cases to cover, and an enum type with a match-like syntax would have worked better for that. For interfaces, multiple dispatch is good but again I would have preferred a trait based approach with static type checking.

I largely think multiple dispatch works well in Julia, and it enables writing performant code in an elegant manner. I mostly have smaller gripes about subtyping and the patterns it encourages with multiple dispatch in Julia, and larger gripes about the lack of tooling in Julia.

But multiple dispatch is also a hammer where every problem in Julia looks like a nail. And there isn't enough discussion, official or community driven, that expands on this. In my experience the average developer to Julia tends to reach for multiple dispatch without understanding why, mostly because people keep saying it is the best thing since sliced bread.

wrt to hybrid languages, honestly, I think Python/Cython is extremely underrated. Sure you can design an entirely new language like Mojo or Julia, but imo it offers only incremental value over Python/Cython. I would love to peek into another universe where all that money, time and effort for Mojo and Julia went to Cython instead.

And I personally don't think Python/Rust is as bad. With a little discipline (and some tests), you can ensure your boundary is safe, for you and your team. Rust offers so much value that I would take on the pain of going through FFI. PyO3 simplifies this significantly. The development of `polars` is a good case study for how Rust empowers Python.

I think the Julia community could use some reflection on why it hasn't produced the next `polars`. My personal experience with Julia developers (both in-person and online) is that they often believe multiple dispatch is so compelling that any person that "saw the light" would obviously naturally flock to Julia. Instead, I think the real challenge is meeting users where they are and addressing their needs directly. The fastest way to grow Julia as a language is to tag along Python's success.

Would I prefer a single language that solves all my problems? Yes. But that single language is not Julia, yet, for me.

PS: I really enjoy your blog posts and comments.

[wrathofmonads]

Mojo has a different scope than Julia and Python, it targets inference workloads.

Polars is a dataframe library. Yes, it features vectorized operations, but it is focused on columnar data manipulation, not numerical algorithm development. I might say that this is narrow framing, people are looking at Julia through the lens of a data scientist and not of an engineer or computational scientist.

[blindseer]

Most of my gripes are when trying to use Julia the way a software engineer would use a programming language.

Most "data scientist" code is exploratory (it's a prototype or a script for an one-off exploration) in nature. And my main gripe is that making that code production ready and maintainable over a long period of time is so difficult that I would switch to Rust instead. If I were going to switch to Rust, I might as well start with Python.