What's bad about Julia?

# · 🔥 324 · 💬 315 · one month ago · viralinstruction.com · jakobnissen
I've heard of organizations whose codebase is in Julia where it takes 5 minutes to start a Julia process and load their packages. Julians are usually very proud of the large amount of code sharing and code reuse in the Julia community, but it's worth noting that this sharing stops abruptly at the language barrier: We might be able to use a Rust library in Julia with little friction, but no-one would use a Julia library if they could avoid it. The Julia team really tries to avoid regressions like that, and they're usually picked up and fixed on the master branch of Julia before they make it to any release. It's only been three years since Julia 1.0 came out, so if you find a blog post from 2015, any posted Julia code is unlikely to work, and the packages have probably released several breaking changes since then. A few abstract types in Julia are well documented, most notably AbstractArray and its abstract subtypes, and it's probably no coindidence that Julia's array ecosystem is so good. Since so much of Julia's behaviour is controlled through the type of variables instead of traits, people are tempted to use wrapper types if they want type A to be able to behave like type B. But those are a terrible idea, since it only moves the problem and in fact makes it worse: You now have a new wrapper type you need to implement everything for, and even if you do, the wrapper type is now of type B, and doesn't have access to the methods of A! A good example of the subtyping system not working is Julia's standard library LinearAlgebra. Because JuliaFolds is not Julia's default iterator implementation, and therefore sees less usage and development than Julia's built-in iterators, the package suffers from some compiler inference issues and obscure errors.
What's bad about Julia?



Archive | Send Feedback | WebAssembly Version (beta)