In particular, multiple dispatch makes operator overloading so much nicer than Python’s fragile “dunder” methods like `__add__` and `__radd__`.

I don't really get why Julia is pigeon-holed for numerics. I prefer its syntax to Python and would consider it for scripting applications where I use Julia now.

       >>> ', '.join(['1', '2', '3'])
     '1, 2, 3'

       >>> '1, 2, 3'.split(', ')
     ['1', '2', '3']

When you start building out a project, it's easy to keep track and debug if multiple dispatch starts failing (i.e. <any> type starts spreading everywhere and Julia slows to Python like speeds).

In medium-to-large projects, it becomes extremely cumbersome to manage this. It's doable, but adds a layer of complexity management to projects that simply doesn't exist in strictly typed or pure scripting languages.

Of course, you can just decide to explicitly type everything - but the issue here again is the lack of enforcement.

In a nutshell: Julia is great when you're a grad student working mostly by yourself on small scale projects! But not so great in prod.

And there's really no problem with that; that's who the language was designed for!

The reason why Julia is fast is because automatic function specialization to concrete dispatches gives type-grounded functions which allows the complete optimization to occur on high-level looking code (see https://arxiv.org/abs/2109.01950 for type-theoretic proofs). It's basically a combination of (1) define a type system in a way that allows for type-grounded functions and compile-time shape inference (shape as in, byte structure of the structs), (2) define a multiple dispatch system with automatic function specialization on concrete types, (3) have a typed IR which proves and devirtualizes all dispatches before hitting the LLVM JIT. If you simply slap the LLVM JIT on random code, you will not get that performance. But now because multiple dispatch is fundamental to performance in the language, the rest of the "game" for the language is how to design an ergonomic language around this feature and how to teach people to use it effectively as a problem solving tool.

You actually see something similar going on in the world of Jax. With Jax, you need to be able to perform abstract interpretation to the Jax IR. In order for this to be possible with the interpreters Jax has, the functions that are being interpreted need to always have the same computational graph for the same inputs, i.e. they need to be pure functions. This is why Jax is built on functional programming paradigms. It would be similarly uncharitable to say the reason why Jax does not embrace OO is because the developers just love functional programming: the programming paradigm choice clearly falls out of what the tools needs to do.

It remains to be seen if Jax is the tool that makes more people finally embrace functional programming styles, or if enough people see pervasive performance necessary enough to change to the multiple dispatch paradigm of Julia. But what is clear is that tools that are moving away from OOP are not doing so arbitrarily, it's all about whether doing so is beneficial enough to justify the change.

[1] https://www.youtube.com/watch?v=kc9HwsxE1OY

IIUC, Common Lisp is the giant on whose shoulders Julia built in this respect.

This is not easily possible in Python, especially not with high performance.

In general, we've not had a formal roadmap - but we present a "State of Julia" talk at JuliaCon every year. But very broadly, the list (of the top of my head) includes: improving a lot of the underlying compiler infrastructure overall, improving support differentiable programming, improving garbage collection, support for GPUs from multiple vendors (too many of those now), supporting apple silicon, type system support for tools like JET.jl.

NEWS.md is generally updated during the course of a release cycle, which eventually becomes release notes, and then post release, we put together a highlights blog post. https://github.com/JuliaLang/julia/blob/master/NEWS.md

Julia doesn't have a good support for OOP. I don't think FP is the optimal way to solve all possible programming tasks. Usually a mix of both approaches leads to the most simple, maintainable and readable code.

And I'm really not sold on multiple dispatch. In Swift, I would simply implement the join function by adding an extension on `Array<String>`. And the + function would just be, for example, `static func + (left: Vector2D, right: Vector2D) -> Vector2D`. I've never come across a situation where I wished Swift would support multiple dispatch. On the other hand, the fact that Julia doesn't use the object.method() has 2 very clear drawbacks: lack of completion in an IDE and poor readability (example: `object.doSomething(a, b, c).doSomethingElse(a, b, c)` - imagine how would this look in Julia).

But the performance relies on the aggressive specialization which depends on multiple dispatch. And the adaptation to numerical computing, the cleanness and beauty is all about multiple dispatch.

To stay with the bike analogy, multiple dispatch is definitely the wheels, not the motor.

> for one, I 100% agree with your views on variable naming elsewhere on this thread ;)

Waaah! (pulls hair.) And yet, so far apart on the function naming ;)

But seriously, though. Without the incredible polymorphism and genericity, there's really nothing at all left of Julia. Multiple dispatch isn't a feature bolted onto Julia. It is the core philosophy, and the central organizing principle.