Skip to content
HHackerTube.videoSurprise me

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

What's Bad About Julia | Jeff Bezanson | JuliaCon 2019 on HackerTube: recommended by 2 Hacker News commenters across 2 separate months, 2019–2026.

Julia co-creator Jeff Bezanson candidly lists fundamental problems with the language at JuliaCon 2019, including modularity, types and compiler latency, and how they might be solved.

Why Hacker News recommends it

HN cites it as the language creator's honest account of Julia's weaknesses, useful for anyone evaluating the language.

people recommended it
2
separate months
2
strong recommendations
0
discussed on HN
2019–2026
“A good opportunity to point out this Juliacon 2019 video: What's Bad About Julia ( ) TL;DR: Julia is not that bad.”
— chappi42, Aug 2019, in “Giving up on Julia (2016)”

What HN commenters said

6 Hacker News comments link this video. Each one links back to its thread.

seertaakFeb 2026Recommends

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 -- ▶ this 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!

in “Show HN: A physically-based GPU ray tracer written in Julia” · View on HN

chappi42Aug 2019Recommends

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

in “Giving up on Julia (2016)” · View on HN

ChrisRackauckasJul 2021Cites it

>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 ( ▶ this 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.

in “What's bad about Julia?” · View on HN

sischoelMar 2021Cites it

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: ▶ this video

in “How C++ Resolves a Function Call” · View on HN

CerthasAug 2019Cites it

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: ▶ this video

in “Giving up on Julia (2016)” · View on HN

chrispeelJul 2019Cites it

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] ▶ this video [2] [link]

in “Julia: Come for the Syntax, Stay for the Speed” · View on HN

Topics & tags

Programming language designCompilers, interpreters & program analysisjuliajeff bezansontime to first plottype systemlanguage design