I don’t have to look far to see Julia’s shortcomings that prevent me to advocate for its use.
- No static bit fields. This may seem minor, but it actually hit me on my very first professional attempt to promote Julia in production. For the efficiency brought by memory-locality of data used by my algorithm I needed to make a custom memory structure holding a static bit field. As you know, variable-size objects are stored as pointers in
structs, so accessing the individual
bitfield will usually involve a CPU cache miss. There was a promise for support for that in
StaticArrays, but despite a PR (Static Bitsets by chethega · Pull Request #647 · JuliaArrays/StaticArrays.jl · GitHub) it never materialized, to the best of my knowledge, to this day. What is the status of StaticBitsets? · Issue #1 · chethega/StaticBitsets.jl · GitHub. I even did report this shortcoming over a year ago to Sushil Kumar, who was at that time an employee of JuliaComputing team, and I never even got a feedback about appreciation of the problem. This all leads me to believe, that there is a whole mountain of obvious Julia shortcomings and there is by far not enough effort to fix them. Lack of support of static bit field seems like just one of many.
You can guess how disappointing it is for me, especially if you consider how easy is to do similar things in C++ and its STL. It was supposed to be this kind of pure data-science project, that was expected to showcase Julia to my whole organization.
Now, with the advent of C++20 and ever-increasing support for Python in Data science, the competition for Julia in terms of expressive power is even tougher.
There is a progress though: The other obstacle to the success of this project was a lack of support for binary compilation of Julia code. Now it seems to have been solved.
- Lack of static code analysis in IDE.
Correct me if I’m wrong, but I see only one modern IDE for Julia: VS Code with Julia addon. It has the philosophy to make code completion database on runtime, rather than statically one it parses the project. I find it a cheap walk-around and a dead-end.
VSCode can only help you with the type of the type-relevant hints only once the code was actually run, and only to the extent, as it was last seen by the Julia parser/interpreter. This is the root to most of the issues I have with Juno. (The other one is that Juno, being an Electron application, is incapable of supporting more than a one window).
Effectively, in summer 2022, the last time I’ve checked I found the overall experience of coding in Juno so much worse than doing the same thing in Python with pyCharm, that I decided that the syntax and speed benefit is not worth it.
I am aware, that doing things statically requires a lot more effort, as a lot of action is done during function dispatching and giving a full support for static analysis may require a lot of heuristics to overcome the infamous Touring’s halting problem. It may be a sad reality that Julia community may simply not afford this amount of manpower in the foreseeable future.
edit: I have mistook Juno with Julia plugin for VSCode. (I used to use Juno even earlier in my career, hence the confusion).