I don't know Julia!
I saw devs leaving CL for a new graal (and eventually coming back). Grass may not be greener on the other side…
You can't make it a CLI script, because it compiles the whole code WITH dependencies every time, and as soon as you import some serious libraries, compile times will skyrocket. I quickly hit 40 seconds of compilation with just geospatial lib and dataframes. These 40 seconds turned out to be A LOT when you develop interactively. And you can't build everything in a Jupyter Notebook, because eventually you'll have to switch to a CLI script.
Table of contents
Compile time latency Large memory consumption Julia can't easily integrate into other languages Weak static analysis The core language is unstable The ecosystem is immature The type system works poorly You can't extend existing types with data Abstract interfaces are unenforced and undiscoverable Subtyping is an all-or-nothing thing The iterator protocol is too hard to use The protocol The problem Functional programming primitives are not well designed
I very recently tried to write a high performance production system in it, and was sorely disappointed. The tooling is just so buggy and it's clear that the community isn't really interested in using it for anything besides modeling/research in a Jupyter notebook.
Things that kind of suck about using Julia for production:
Never could get Revise to work, had to restart my REPL everytime I changed any code. Even though Julia 1.6 was a lot faster than 1.5, it still took too long. (=> =we don't have to restart the REPL in Lisp, even when we install new packages)
Couldn't find a static type checker that actually worked (I tried JET and StaticLint). I feel like static typing is just so important for a production system, but of course the community isn't really interested because of the research focus. (=> In CL we do have static type checks, especially with SBCL and we can gradually add more type declarations. It is not a "full" ML-like type system though. For that, see the Coalton library.)
Editor tooling. The LSP server absolutely sucks. I first tried using it with emacs (both lsp-mode and eglot mode), but it would crash constantly. I think switched to VSCode (much to my chagrin), and that worked marginally better though still very poorly. It was clear that the LSP server had no idea what was going on in my macro heavy code. It couldn't jump to definitions or usages much of the time. It could never correctly determine whether a variable was unused or misspelled either. Coupled with the lack of static type checking, this was extremely frustrating. (=> Slime/Sly is still more feature complete than what LSP provides.)
Never felt like the community could answer any of my questions. If you have some research or stats question, they were great, but anything else, forget about it.
Will all of that being said, I do still use Julia for research and I find it works really well. The language is very nicely designed.
There is no pattern matching and no language features to manipulate types, for example. Julia's AST and IR share a lot in basic data structure thanks in large part to Julia's dynamical nature. Since adding static typing to Julia at the current stage of its development would be almost an upheaval, I am not counting on it.
This means there is an upper bound to how good the editing and refactoring tooling will be. I suspect the best will be a little below Python's tooling, because Python's class helps in disambiguating methods.
I use and love Julia but I really wanted to see the general purpose language that is claimed. On one hand, you see amazing scientific libs like DifferentialEquations.jl, on the other side, things like the PackageCompiler.jl mentioned just sucks at generating binaries for daily basis. (=> creating self-contained binaries is a solved problem in CL)
(in CL a hello world weighs ±20MB):
«Don't you just compile the script into an executable?» «you end up with a several hundred megabytes executable for a hello world program.»
(I love to not deal with syntax anymore):
« what's false ? 1 : 2 : 3 : 4? —better yet— if you remove a single space then the expression will yield an error.»
«It's pretty immature. Things take time.» «I think I have encountered an example of Julia's immaturity.
A few months ago, I tried to write a program that should receive UDP packets over IPv6 multicast.
It didn't work. I never figured it out. This works in Java and Python.
This might be unfair or untrue, but I get the feeling that it doesn't work because no one has seriously tried to use the language this way.
IPv6 multicast is not an obscure feature in low-level systems programming, and I feel pretty confident that the Go and Rust people would be quick to fix a problem like this. This kind of application development is not a typical use for Julia.»
(CL is damn stable):
«Also, my packages seem to really like breaking when I try to load them about once a month, but this is more likely to blame with my underlying Linux system than Julia itself (though it didn't happen with Python).»
I migrated from Lisp to Julia for the ecosystem. It hasn't been worth it from my point of view. I'll migrate back to Lisp eventually.
lukego on https://news.ycombinator.com/item?id=32175820 about lisp-stats, 2022-07-21
- https://yuri.is/not-julia/ "Why I no longer recommend Julia" (2022): "there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters", "in terms of basic correctness, Julia is not currently reliable or on the path to becoming reliable". HN discussion. And HN discussion on an answer article "Why I still recommend Julia".