What's Bad About Julia | Jeff Bezanson | JuliaCon 2019

The "time-to-first-plot" (compiler latency) problem is something that the Julia gurus know about and are working on. For example, Jeff Bezanson gave a talk [1] at the just-completed JuliaCon that listed this as the first on a list of known problems with Julia. One immediate solution is to use PackageCompiler.jl [2] to build a Julia image that includes a pre-compiled version of the slow code (packages). [1] [VIDEO] [2] [LINK]

Indeed, and while there is plenty to still be worried about, a lot has been addressed, too. Further we are now starting to see the pay-off with amazing algorithmic innovations being implemented in Julia. We have working code to code automatic differentiation: [LINK] Finally, the core team is paying attention to the problems and addressing them. All my top complaints are already mentioned in the laundry list: [VIDEO]

A good opportunity to point out this Juliacon 2019 video: What's Bad About Julia ( [VIDEO] ) TL;DR: Julia is not that bad.

Julia is dynamically typed, but if the compiler can deduce the type of your expressions, it will usually generate specialized code that avoids dynamic dispatch. Getting rid of type instability (as it is called) is usually one of the first things I do when trying to optimize a Julia function. The discussion about C++ lookup rules actually really reminded me of Julia, where functions are quite often overloaded and it is not always trivial to figure out which one should be called. For lack of a better source, there is something about that in this talk: [VIDEO]

>I’ve had a lot of frustration with the Julia community being unwilling to see faults in the language. What? It's basically a meme at this point for major contributors to write a list of what they think is bad. The language's creator did a nice Youtube video "What's bad about Julia?" at JuliaCon 2019 ( [VIDEO] ), one of my most popular blog posts of all time is "7 Julia Gotchas and How To Handle Them" ( [LINK] ), etc. What the community pushes back about is things that are factually incorrect or just silly and repetitive, like the n+1th discussion about 1-based indexing. It's stuff below like, "I want to do an interactive workflow but not use the REPL, so it's not working well"... well the REPL is literally the interactive piece that caches the compilation so just use it if that's what you're trying to do? Yes, nobody has time for that nonsense, but everyone chimes in for real substantive discussions like changing the Base iterator API, programming patterns that would reduce recompilation, etc.

Just to clarify the above: 1. I use the term "performance" slightly vaguely. It's comprised of two distinct things: the time it takes to compile the code, and the execution time. The issue is the compilation time: there are certain cases where it's exponential in the number of types which could unify with the callsite's type params. 2. IIRC, Julia compiler has heuristics to ensure things don't explode for common cases. If I'm not mistaken, not only do compile times explode, but certain (very common) things don't even typecheck. There's an excellent video about it by the designer of the language, Jeff Bezanson -- [VIDEO] . Note: Julia experts, please correct me if this has been fixed. 3. The difficulty in intuiting which combinations of types will unify at a given callsite isn't theoretical; there are reports of libraries which unexpectedly fail to work together. I want to qualify this statement: Julia is light years ahead of any language lacking multimethods when it comes to library composability. But my guess is that those problems would be reduced with non-symmetric multimethods. 4. The non-symmetric multimethod system I'm "proposing" isn't my idea. They are referred to variously as encapsulated or parasitic multimethods. See [LINK] I have huge respect for Jeff Bezanson, for the record!