I really want to love Julia. I've never gotten over the startup time, slow string functions, and package manager repl thing. Perhaps I was getting into it at a bad time, right around the time the new package manager was being announced. The whole thing felt very magic... too R like for comfort.
I think Julia started getting popular a little too early — I had a few bad experiences and crashes (and crashes were almost impossible to debug as they gave backtracked in the compiler code). There are only so many hours to try new things.
My experience has been completely the opposite. Julia has been frustrating to work with. Most of the time I’m just waiting for precompilation of the packages.
It’s unbelievable that the Julia core devs still haven’t addressed it. It is not fun by any means. Not even tolerable.
Julia is what happens if you let amateurs develop a compiler. The few times I’ve tried it produced gigabytes worth of stuff super slowly. The majority of packages are half backed, the only way to discover any type error is to let the program run, which coupled with multi method dispatch and hellishly slow compile times for trivial amounts of code makes the whole experience super unpleasant. Modern C++ plus some python feels more pleasant to work with (lightning fast compiles).
Julia looked interesting to me, so I tried 1.0 after it came out. I have a oldish laptop (fine for my needs), and every time I tried to do seemingly anything, it spent ~5 minutes recompiling libraries or something. So I've been waiting newer versions that hopefully stop doing that, or for me to buy a better computer.
How do you get on with package management? That is probably the area where Julia had the most opportunity to trounce Fortran, and yet that is the part of the language I've never managed to get comfortable with.
This article is painfully true. Julia is full of gems, but also features so many warts everywhere that I'm not sure whether it will be able to overcome the latter – I hope it will.
I would add to the author's list the subtle differences between REPL and scripts, the weird obsession of Julia for embedding slightly different and out of date versions of its dependencies (BLAS, uv, LLVM, ...) that makes it a nightmare to package, the painfully slow documentation website,
the sometimes surprising function names, and wholeheartedly agree on the failure that is functional programming handling, both in syntax and implementation – which is surprising for a language stemming from MIT.
This is the first time I’ve heard somebody say that Julia’s package management is worse than Python’s! For most people who have spent years grappling with the succession of unofficial attempts to supply Python with something like package management, including virtual environments, etc., and the resulting dependency hell, Julia’s integrated and sophisticated package management (even with its own special REPL mode) is refreshing. I don’t doubt your experiences are real, but suspect you have just had really bad luck.
1.2 is pretty ancient. Current, or even recent, versions of Julia have a fraction of the startup time (https://lwn.net/Articles/856819/). Package management has been refined further, as well.
Yeah, this has been my experience as well. I really _want_ to like Julia. But so far the JIT experience has been exceptionally miserable--and unfortunately for me, my typical approach to development is quite interactive. I'm on 1.1.1.
Make the package management more Cargo-like and I'd probably adopt it wholesale; whenever I've tried Julia in the past the user experience of just getting started has been the off-putting part.
I agree, I have the same love/hate relationship with Julia. When the stars align, the language and its ecosystem are incredibly fast and pleasant to use.
But most of the time, it is waiting for the incredibly slow doc website; trying to reverse engineer the lib that everyone presents you like the best there is, but is woefully underdocumented – if it is documented at all; delving through bad stacktraces; struggling with the abysmal multithreading experience; hoping for small syntaxic sugar such as a better syntax for one-line conditional execution than &&, do/while loops, or if-as-expressions while we get an nth unicode operator; waiting for plots; the REPL being unable to redefine structs; getting enthusiastic about AD, until understanding that it is so slow that is basically only works on toy problems; etc.
All in all, the language and its ecosystem gives the impression that it is not much more than heaps over heaps of promising PoCs stacked on each other, but would need thousand of CS engineering man-hours to go from promising academic project to actually usable environment.
I tried really hard to like Julia and it just isn't happening for me. Slow startup, bad documentation, fragmented ecosystem, poor error messages and stack traces, encouraging the use of unicode glyphs and operators... it's been a horrible beginner experience all while the Julia community keeps telling everyone (and each other) how amazing the language is. I'm not seeing it.
I like the idea of Julia but had a poor time making it work (circa october-november 2020) on my Ubuntu laptop. It also refuses to work in environments like repl.it. I feel like it's quite imature still, and that I'll try to pick it up later when it's better.
I think there needs to be a distinction between on one hand Julia's startup time, which is an inevitable consequence on its compilation model and unlikely to change, and on the other hand whether there is a lack of command line functionality in Julia, e.g. the package manager. The latter is much easier to amend.
Yes I follow this. The load time keeps getting better. And am looking forward to 1.9.
I really don't want to come across as negative, Julia is a fantastic language, and my hope is that that it will continue its impressive improvement path.
But to follow form the thread's sentiment, I have the feeling Julia lives in an unstable equilibrium. It is lower level than R/Python but doesn't quite deliver the benefits of rust/c/fortran/c++. I find my colleagues gravitate to one of the 2 equilibria.
Maybe your last paragraph crystallizes it. If one lives in the REPL, Julia is wonderful. Not how I work. I prefer the command line. Have new data, run code on it. Data changes in real time, code not. My code may run millions of times on different operating systems and only infrequently change.
I have a love/hate relationship with Julia. I’ve been using Julia professionally since 2018, and in my spare time since before that. And after writing a lot of code and reading and reviewing even more, my biggest complaint is that tooling suuuccckkssssss.
LanguageServer takes up to 10 minutes to start (5000-7000 line Julia project with lots of Julia dependencies). I usually open vim, go get coffee and then come back to start working on the project. And if the LanguageServer crashes or I have to restart vim for some reason, oh boy.
Even after 10 minutes, updates are SO slow. You can type something incorrectly and the LSP diagnostics won’t pick it up for at least 30-40 seconds. By then you may have moved to a different point in the codebase. Forget about switching branches when you are doing all this. I’ve tried PackageCompiler and weirdly it doesn’t really help here for some reason.
The worst part is there’s no way to run a subset of tests. You HAVE to run ALL the tests every time. This makes IDE driven development and test driven development absolutely non starters. REPL driven development is the ONLY way to go, and even the REPL has its readline quirks. And god bless Revise.jl. I shudder to think of life, it weren’t for Revise, the giant hack that it is.
There’s no officially blessed language formatter. LanguageServer.jl uses a formatter and JuliaFormatter.jl kind of exists on its own. And even these formatters don’t do enough, by the way (imo). Two examples that come to mind is converting explicit returns to implicit returns and changing using Foo -> import Foo: x,y. Not to mention the vim plugins for LSP and formatting are not great. Even the most popular Julia-vim plugin has some super odd opinionated un-vim like choices like high jacking TAB and the choice of commentstring syntax etc.
All this in daily development is painful as it is, and even more so when I have to review someone’s code. I’m a software engineer by training, and when I have to read domain specific code written by a scientist or a domain specific engineer, or worse when I have to refactor and clean it up, I cringe all the time. Try figuring out which method gets dispatched without using a repl, fun times. Maybe few people port a Pluto notebook script into a production application as much as I do but yikes is it painful. There is SO much down time. Wait for tests, wait for LSP, wait for formatter, wait for static analyzer with JET, make a change, rinse and repeat.
Contrast this to using Python, Rust, Zig, or Go and feedback is immediate! And unlike Julia, vscode isn’t the only golden editor. You can use pretty much any editor and you get first class support.
All in all, Julia as a language is super interesting. I would probably only use it for small personal projects though. Professionally, I would still stick with python / pypy, or even writing python and rust or go. Multiple dispatch alone isn’t worth the other pain points when working with a large team (>50 people).
Julia is really nice the only problems are 1) its focus is it being used from the REPL. While you can use a .jl script from the cli it feels wrong because of 2) its lack of a good AOT compilation/runtime/static binary option. Its JIT compiler is really good but you pay a price on startup and first runs hence Julians usually just have long running REPLs they don't close. 3) the ecosystem is still immature there are some amazing parts but also a lot of empty or poor parts still.
Interesting, I've had the opposite reaction. I find it to be about the nicest programming language to work with. I even started writing a little toy database in Julia, and find it really easy to reason about.
Package management system is its only weak point IMO. It makes a lot of counter-intuitive decisions (having to build a package from the packages directory? that's just strange). Cargo / Bundler to me feel like the gold standard in package management... most alternatives I've seen would be better off just copying those workflows unless there's a really good reason to try something new.
reply