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".
An answer and updates, 2025-01: https://news.ycombinator.com/item?id=42675794
The "feedback and answer" below the gist already covers a bunch of things I wanted to mention. So I'll skip those and only talk about the rest:
The "with dependencies" part is mostly untrue nowadays, with constantly better pre-compiled caches for dependencies with every release. The overall issue of compile times getting in the way of interactive development still has some truth to it, but much less than the comment implies.
The subheadings in the ToC are mostly based on comparisons with the best-in-class: for eg. "Julia can't easily integrate into other languages [compared to C]", "Weak static analysis [compared to Rust]".
Seeing this actually gave me hope about Julia's progress, based on how many of these issues have been largely mitigated or have been actively worked on in the last three years since the post.
As a side note, the author of the post is still an active user of and contributor to Julia, so I think this kinda falls under the "There are only two kinds of languages: the ones people complain about and the ones nobody uses" banner. As in, the complaints are there because they like and actively use the language enough to want it to be the best in every way.
I agree - I think pre-1.9 Julia experience sucked, and overselling the language in that period hurt its reception a lot. (I've mentioned elsewhere in the thread that the developer experience is still one of the weaker points of Julia.)
In Julia 1.12, with the experimental --trim feature, a hello world is <1MB. Still too early to tell how that'll translate to real programs though.
This is hilarious and awful at the same time. There's no beating CL in this - I've learnt that every language with syntax unfortunately develops "wat"s like this over time when well-intended syntax features interact.
I don't think it's either of those: it seems like networking was and remains a weak area in Julia. For eg., though the language itself is blazingly fast, there have been a bunch of reports about how HTTP traffic performance is several time slower than ostensibly slower languages like Ruby. The reason is probably what the quote says too, there just isn't as much of a userbase or demand for this side of things.
There's no source for this one, and no info on what "breaking" means or what the packages do, so I can only say this isn't a common experience. It's very easy to "pin" dependencies to preserve a reproducible state of dependencies and replicate it as well, which is greatly useful in a language used for science.
I'm not very surprised, given the lisp-stats context - it seems to be a common assumption/misconception, because Julia gets compared to Python and R often, that it's a data science and stats focused language. It's great for greenfield stats work, pleasant in many ways compared to those two, but the ecosystem is not particularly focused specifically on it. I'd suggest choosing Julia for the ecosystem if you're doing science science - quantum computing, diffeq modeling, numerical optimization, many others - but on the data science side, what Julia offers is consistent syntax, performance without C reliance, while retaining niceties like DataFrames and Tidier that other languages offer.