[kmaitreys]

I really like Julia as a language but I have struggled to adopt it and be productive in it. Part of it is because of the JIT runtime and a sub-par LSP (at least when I last tried).

To those who regularly write Julia code, what is your workflow? The whole thing with Revise.jl did not suit me honestly. I have enjoyed programming in Rust orders of magnitude more because there's no run time and you can do AOT. My intention is not write scripts, but high performance numerical/scientific code, and with Julia's JIT-based design, rapid iteration (to me at least) feels slower than Rust (!).

[jakobnissen]

The boring answer is that I don’t use huge dependencies that takes minutes to compile, and I don’t lean on the LSP - I tend to put more effort in reading the code.

In my experience you really gotta work with the tools the language gives you. Julia gives you Revise, so it’s a bit of a handicap not using it. Maybe analogous to writing Rust without an LSP.

I get that leaning on the LSP can become a habit, and also that the Julia LSP is quite poor, but I find it wild that rapid iteration for you is faster in Rust. I write Rust as well and can’t imagine how that would be the case.

[kmaitreys]

A lot of people have focussed on the LSP in their replies when it is was only one of the problems I mentioned.

rust-analyzer is a great LSP and paired with clippy it can teach you the language itself. Also, writing numerical code is extremely easy in Rust. I can write code and just run cargo run to see the output. Julia, on the other hand, forced a REPL-based workflow which never has made sense to me. REPL-based workflow makes sense when you just want to do some script stuff. But when writing a code which will run for a long duration on a HPC? I don't get it. Part of the problem is I'm not "holding it correctly", but again, out of the box experience isn't good. You define a struct and later add or remove a field from it. Often you'll get an error because Revise.jl didn't recompile things. It was a sub-par experience and I was hoping to people would share their dev workflow in more detail

[leephillips]

And yet Julia is used for large-scale simulations on giant HPC machines and Rust is not.

Recent versions of Revise let you redefine structs in the REPL.

You are not forced to use the REPL, ever. It’s a fantastic convenience, however.

My dev workflow is to write my code in Neovim, sometimes with a REPL attached to the editor to try out code snippets. I don’t need or use LSPs. I do enjoy the Aerial plugin, which pops up an outline of my code for easy navigation.

[SatvikBeri]

Well, my workflow uses Revise.jl. I develop either in Jupyter notebooks or in the REPL, prototyping code there and then moving functions to files when they're ready. In that context, rapid iteration is fairly fast.

Nowadays I often use Claude Code, working with a Julia REPL in a tmux or zellij session via send-keys. I'll have it prototype and try to optimize an algorithm there, then create a notebook to "present its results", then I'll take the bits I like and add them to the production codebase.

[kmaitreys]

How do you develop a program which will run for longer duration on HPCs. How do you quickly modify struct definitations, how do you define imports (using vs include syntax is so confusing!)

REPL-based workflow doesn't make sense to me other than scripting work.

[SatvikBeri]

Re: REPL use, you just use it to run code and look at results. e.g. for TDD – you can modify your code files normally in the IDE, changes get picked up by revise, and then you re-run the tests in the REPL.

For long-running jobs, I basically follow the same process as in any other language: make the functions I want to run, test them locally on a small dataset that runs relatively quickly, then launch them on the remote machines with the full data.

Revise.jl has struct redefinition now, but before that I would just use NamedTuples while iterating, then make a struct when I was ready to move something to production.

`using` is for importing modules, `include` is for specific files. At work, we currently have a monorepo, with one top-level OurProject.jl file that uses `using` to import external packages, and `include` for all the internal files.

[adgjlsfhk1]

> How do you develop a program which will run for longer duration on HPCs.

The main strategy is to have a way of parameterize the program to bring the runtime down to seconds-minutes on a laptop. E.G. for PDEs, you may be running the HPC version on a giant mesh, but you can run the same algorithm on your local computer on a much coarser mesh.

> How do you quickly modify struct definitations

Thankfully on 1.12 this has been solved. You can redefine structs while keeping the REPL up.

> how do you define imports (using vs include syntax is so confusing!)

Yeah julia messed this up. The basic rule is that include and using are basically the same.

[arbitrandomuser]

yup the LSP is bad, there is a new lsp being rewritten based on JET.jl a static code analyzer , this should be faster than the old lsp which kind of runs by loading all the modules into a julia instance and queries it for symbols and docs ( im not 100% sure but i think thats how it works)

[thimotedupuch]

Exactly ! The new LSP is getting ready https://github.com/aviatesk/JETLS.jl/ with one of the compiler devs working hard on it. I tried it with VSCode, Zed and Helix and it's more than fine already.

I hope julia developper tools will one day match the best of what other programming languages have to offer.

[tombert]

Just an FYI...Claude is actually really good at building LSP servers [1].

If you want a better Julia LSP, you might just be able to get Claude or Codex to build one for you. I've been impressed with the TLA+ bindings it generated.

[1] https://github.com/Tombert/TLA-Language-Server-Protocol

[paddim8]

What's the problem with the JIT runtime? Why is rapid iteration slower with JIT? Just-in-time compilation isn't inherently slower and is normally faster than AOT for dynamic languages and even static languages that have some dynamic features like dynamic dispatch

[lelanthran]

> Part of it is because of the JIT runtime and a sub-par LSP (at least when I last tried)

Good LSPs do the autocompletion, sub par ones don't.

Is it really such a good idea to have every single automated aid turned on when picking up a new language?

How will you learn if you cannot get feedback on what you did wrong?

I mean, until you learn multiplication, maybe don't use the calculator.

Once you learn it then you get a small speed increase, but if you are new to something, LSP autocompletion is going to slow down your learning.

[kmaitreys]

I think LSPs like rust-analyzer are very good tools to learn the language itself. I think I learnt Rust solely through LSP and clippy.