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.
https://news.ycombinator.com/item?id=36755618, 2023
2021-07
from https://viralinstruction.com/posts/badjulia/ (https://news.ycombinator.com/item?id=27960865)
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
from https://news.ycombinator.com/item?id=27280174#27281281
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.
(=> ouch!)
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.»
2021-03
(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.»
2021-03
«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://danluu.com/julialang/
- 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".
Julia feedback and answer to that gist, 2024-02 https://news.ycombinator.com/item?id=39384352
It's a young language still. Pre-compilation has brought "time to first plot" down considerably, and ameliorated many (but not all) of the specific complaints in that gist. One stands out, which is "lack of pattern matching", Julia is a language like CL where a language feature can be a library. MLStyle is arguably the best but there are a few1.
Similarly, there's a start (heh) on a condition and restart system2. Julia macros are actually full-strength and that makes up for a lot. I would say that "less mature" is a fair comparison with CL but "less rich" is more of a judgement call. When people are in a mood to be critical of Common Lisp, the richness of the package/system ecosystem is a frequent target of that critique.
Binaries which aren't enormous is a main focus of development now, as I understand the timeline 1.11 will bring modest improvements (in the next few months) and 1.12 will be relentlessly focused on achieving this, it's a recognized problem.
I find Julia completely suitable for general-purpose programming, right now. Moreover I see it on the right trajectory. My hope is that when the trigger is pulled on 2.0, this will include a standardization process, resulting in an actually-stable language by about 2030. Note that Julia is closer to Rust-stable than Python-stable already, post-1.0 code which runs on the latest version (1.10) is more common than not, but I do think compatibility needs to be broken, once, eventually, to fix some bad decisions. It shouldn't have to happen twice.
I realized I didn't address one of the main things you said, which was about image-based tools. That's better as its own reply I reckon.
Depends on what you mean by "image-based". Julia doesn't support reloading core dumps, but it has pre-compilation, and it has Revise, which will do everything it can to keep the REPL state up-to-date with changes to the source code. My experience is that it always updates state (silently) or fails and tells you, and when it fails can be predicted: if you modify the layout of a struct, or change an enum, it can't track that, so the prompt will turn yellow and you'll have to restart. You get the same yellow prompt (instead of green, and this is configurable to use textual cues btw) if there's a syntax error, but in that case, you fix the code and press enter and it goes green again.
Revise evals the minimum amount of code to update the program state, this is instantaneous for all practical purposes.
The Julia REPL is a massive improvement over any of the REPLs which ship with open-source Common Lisps, and head and shoulders above what comes with most other languages. It is not yet up to the standard of a commercial Lisp, or of the Emacs SLIME-mode approach, but the community lives in the REPL (and notebooks), so I expect to see the polishing process continue.