- immature web/network services stack. For better or worse the lang seemed to focus on more number crunching throughput early than reliable distributed data processing, but the latter is a much larger market and what most enterprises care about.
It's the difference between a lang only having Matlab or R ceiling vs python-like ceiling.
- poor static compilation or static analysis story. this is what a lot of people needing to put code in production need.
It's also standard expectation now with a lot of dynamic language code (python or js) that aims to be in production.
- for certain types of realtime uses, more direct control of memory is doable, but you have to jump through hoops. Again, determinism is very important.
- historically, compile times were quite horrid. part of this was llvm, part of it was julia. It's gotten way better in 1.6 and 1.7, but compilation results need to be cached more than just precompilation.
however, all being said, I love the lang! There is a lot going for it especially how the package ecosystem works. There is also a lot of innovative projects.
You're comparing it with python.
https://github.com/typeddjango/awesome-python-typing
https://github.com/ethanhs/python-typecheckers
though i'd say they are worse than similar tooling in typescript/javascript.
julia's tooling is relatively nascent.
The deal breaker for me is that its compiler is JIT based whether you want it or not. Code will hang at runtime for multiple minutes as it compiles all the library dependencies and specializes them to the given data types.
I think the problems were from:
1) llvm itself getting dramatically slower over time, before more focus upstream on compiler speed more recently: https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html
2) different types of invalidations
3) less than ideal precompilation of packages
I think all of it has been improved, and can certainly be improved further. That also includes improving the speed of its interpreter (vs the JIT), which exists but was never optimized for speed afaik.
Also, there's a solution to precompile binaries with no JIT penalty...
https://github.com/JuliaLang/PackageCompiler.jl
Enjoy!
Nowadays, the language is promoted as a general purpose language suitable for any task or domain.
However, the perception that Julia is primarily for scientific computing remains strong among many developers. Only time will tell if that perception changes.
I think there have been steps recently to make those optional recently. Julia was really optimized for "big iron"-styles of workloads, but that's less than ideal when you are not trying to just do linear algebra all day.