5 ms·
Mini rant incoming. 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 af
by blindseer 5y ago
Mini rant incoming.
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).
- blindseer 5y agoOne thing I think the Julia core team should look to get professional help on is human computer interface design in programming languages. I know there’s been a lot of strides in the right direction, but having used rust I can say that Julia is waayyyyy far behind. I’m mainly thinking of general naming, error messages and stack traces. My opinion on the naming is that it feels like it is written by scientists for scientists (which can be good, but is also a barrier to entry). Specifically w.r.t. to stacktraces, I think the Julia core team should just pay someone like Jonathan Turner to review their stacktraces and see how they can improve it. JT was involved in the rust stacktraces and when he was using Zig on stream he was immediately able to identify ways to improve Zig’s stacktraces. I think his kind of insight could go a long way in helping Julia be more friendly. Another place is Pkg error messages. I’ve opened projects from a few years ago and things have just failed. I think it is because I’m not using the same Julia version that I did when I recorded the Manifest (weird that Julia doesn’t record the Julia version number in the Manifest). But I will never know I guess because I get almost cryptic error messages from Pkg. It is borderline infuriating. I say all of this because I really like (or at least really want to like) Julia. And I know fellow coworkers who share this sentiment about some of these pain points. If these are fixed (and latency becomes better) I for one would pull fewer hairs out of my already balding head :) I would ask that Julia advocates take all my criticism kindly. I know you are all passionate and have worked on a lot of these features yourselves. I’m expressing some opinionated frustrations. Edit: w.r.t. HCI in programming languages, here’s a comment shared by one of my grad school friends that is doing a thesis on HCI in programming language syntax: “It (sic, It -> Julia syntax) is inconsistent in a lot of ways. There’s "primitive type", "abstract type", "struct" and "mutable struct" that are all keywords for defining "struct" like things. Why not use "struct" or "type" everywhere consistently? …” My friend’s comment is long and winding, but I’ll check with them if I can post a link to their thesis here. It might be an interesting read for some folk.
- teruakohatu 5y agoI completely agree. Julia stack traces are abysmally bad. The only worst stacktraces I have to endure is Shiny... Essentially useless at best or deceptive at worst.