4 ms·

Julia: Performance Tips

73 points by tosh 9mo ago

pachico 9mo ago
Legitimate and honest question: in which circumstances would you choose Julia over more mainstream alternative like Go?
- bandrami 9mo ago
  Math. Places you might use Wolfram or Sage.
- Human-Cabbage 9mo ago
  Julia is aimed at scientific computing. It competes against Python with numpy/scipy, R, etc.
  - ziotom78 9mo ago
    Correct, but I would add: Julia is better than Python+NumPy/SciPy when you need extreme speed in custom logic that can’t be easily vectorized. As Julia is JIT-compiled, if your code calls most of the functions just once it won’t provide a big advantage, as the time spent compiling functions can be significant (e.g., if you use some library heavily based on macros). To produce plots out of data files, Python and R are probably the best solutions.
    - jey 9mo ago
      And I would further add: In addition to performance, Julia's language and semantics are much more ergonomic and natural for mathematical and algorithmic code. Even linear algebra in Python is syntactically painful. (Yes, they added the "@" operator for matmul, but this is still true).
    - dgfl 9mo ago
      Disagree on the last statement. Makie is tremendously superior to matplotlib. I love ggplot but it is slow, as all of R is. And my work isn’t so heavy on statistics anyway. Makie has the best API I’ve seen (mostly matlab / matplotlib inspired), the easiest layout engine, the best system for live interactive plots (Observables are amazing), and the best performance for large data and exploration. It’s just a phenomenal visualization library for anything I do. I suggest everyone to give it a try. Matlab is the only one that comes close, but it has its own pros and cons. I could write about the topic in detail, as I’ve spent a lot of time trying almost everything that exists across the major languages.
      - dan-robertson 9mo ago
        I tried some Julia plotting libraries a few years ago and they had apis that were bad for interactively creating plots as well as often being buggy. I don’t have performance problems with ggplot so that’s what I tend to lean to. Matplotlib being bad isn’t much of a problem anymore as LLMs can translate from ggplot to matplotlib for you.
      - Certhas 9mo ago
        I love Makie but for investigating our datasets Python is overall superior (I am not familiar enough with R), despite Julia having the superior Array Syntax and Makie having the better API. This is simply because of the brilliant library support available in scikit learn and the whole compilation overhead/TTFX issue. For these workflows it's a huge issue that restarting your interactive session takes minutes instead of seconds.
      - versteegen 9mo ago
        I recently used Makie to create an interactive tool for inspecting nodes of a search graph (dragging, hiding, expanding edges, custom graph layout), with floating windows of data and buttons. Yes, it's great for interactive plots (you can keep using the REPL to manipulate the plot, no freezing), yes Observables and GridLayout are great, and I was very impressed with Makie's plotting abilities from making the basics easy to the extremely advanced, but no, it was the wrong tool. Makie doesn't really do floating windows (subplots), and I had to jump through hoops to create my own float system which uses GridLayout for the GUI widgets inside them. I did get it to all work nearly flawlessly in the end, but I should probably have used a Julia imGUI wrapper instead: near instant start time!
        leephillips 9mo ago
        Are you referring to https://github.com/JuliaImGui/CImGui.jl https://github.com/JuliaImGui/CImGui.jl ?
        versteegen 9mo ago
        Yes. And I did port my GUI layer to CimGui.jl. The rest of it is pretty intertwined with Makie, didn't do that yet. The Makie version does look better than ImGui though.
    - ainch 9mo ago
      Even then, if you're familiar with NumPy it's pretty easy to switch to Jax's NumPy API, and then you can easily jit in Python as well.
      - JanisErdmanis 9mo ago
        As long as someone else does the porting and maintains the compatability between both subecosystems of thoose who prefer using Jax and thoose who prefer depending on the NumPy. Also not having zero overhead structs that one can in an array handicaps types of performance codes one can write.
- markkitti 9mo ago
  When I need to do serious math, I use Julia.
- setopt 9mo ago
  Scientific computing. AFAIK, library support for that in Go is almost nonexistent.
- kryptiskt 9mo ago
  Go is a total non-starter, it's not interactive at all. The competitors are things like Matlab, Mathematica, R or Python (with the right math libs). If you're weird you could use something like Haskell, APL or Lisp in this role, but you'd pay a hefty price in available libs.
  - VorpalWay 9mo ago
    In what situations would a non-interactive language be a non-starter? I have never felt that I missed having a REPL when coding C++ or Rust. The only reason it is even useful in python is that the type info is laughably bad, so you need to poke things interactivly to figure out what shape of data you should even expect. (I'll take strong static typing every day, it is so much better.)
    - SatvikBeri 9mo ago
      REPLs/notebooks are really nice in situations where you don't know what you want ahead of time and are throwing away 90% of the code you write, such as trying to find better numerical algorithms to accomplish some goal, exploring poorly documented APIs (most of them), making a lot of plots for investigating, or working a bunch with matrices and Dataframes (where current static typing systems don't really offer much.)
      - VorpalWay 9mo ago
        Yeah, this is a entirely different domain than what I work in (hard real-time embedded and hard real-time Linux). Though poorly documented APIs exist everywhere, but they are not something you can rely on anyway: if it isn't documented the behaviour can change without it being a breaking change. It would be irresponsible to (intentionally) depend on undocumented behaviour. Rather you should seek to get whatever it is documented. Otherwise there is a big risk that your code will break some years down the line when someone tries to upgrade a dependency. Most software I deal with is long-lived. There is code I wrote 15 years ago that is still in production and where the code base is still evolving, and I see no reason why that wouldn't be true in another 15 years as well. At least you should write tests to cover any dependencies on undocumented behaviour. (You do have comprehensive tests right?)
- wolvesechoes 9mo ago
  It is highly interactive and dynamic, yet performant. And it is not only about scientific computing, for almost any application can take advantage of interactive, modifiable system, where you can explore your state at any point. In others, more static langs good debuggers help with this to lesser or larger extend, but it is not the same from my experience. So better question is: in which circumstances would you choose Julia over more mainstream-y alternative like Clojure? And here scientific and numerical angle comes to play. At the same time I think Julia is failed attempt, with unsolvable problems, but it is a different topic.
- Certhas 9mo ago
  On top of what others have said: In many situations the alternative to Julia isn't Go but C++ (or maybe Rust though its library support is lacking). E.g. if you are writing high-ish* performance algorithmic code that should also run on GPU. Julia also heavily prioritizes composability of libraries. And though that can be a source of bugs at times, there are things we are doing in Julia with one or two PhD students that would be practically impossible (as in require an order of magnitude more implementation work) in any other language.
- huijzer 9mo ago
  To replace uses where you would use Matlab or R probably. I prefer Julia over Matlab or R. So data science. For production code however, it's not great since it has no static typing. Imagine having your production code crash mid-execution with the error "Function foo not found". Only dynamic languages can do that to you.
  - jondea 9mo ago
    I broadly agree that it can be hard to nail down Julia's behaviour but it does have static typing and I think it is more subtle. Function arguments and variables can be concrete types e.g. if you were implementing an approximation for sin, you could restrict arguments to Float32 if you knew it was only suitably accurate for that type.
    - huijzer 9mo ago
      > it does have static typing and I think it is more subtle. Yes sure Julia isn't fully dynamically typed, but that doesn't change the fact that it isn't fully static typed. If it was, it should be pretty easy to create static binaries and find bugs like "func not defined" at compilation time.
- Joel_Mckay 9mo ago
  Julia collapses entire programming paradigms into single character syntax, and often will transparently handle clean parallelism or cluster instance batching. https://docs.julialang.org/en/v1/manual/mathematical-operations/#man-dot-operators https://docs.julialang.org/en/v1/manual/mathematical-operati... Go is similar in many ways, but takes a performance hit in areas like Garbage collection. The Julia community is great, and performance projects may also be compiled into a binary image. =3
  - ForceBru 9mo ago
    Judging by Julia's Discourse, compiling actual production Julia code into a standalone binary is highly nontrivial and ordinary users don't really know how and why to do this.
    - Joel_Mckay 9mo ago
      Example should still work: https://julialang.github.io/PackageCompiler.jl/dev/devdocs/binaries_part_2.html https://julialang.github.io/PackageCompiler.jl/dev/devdocs/b... They greatly improved the generated binary file size last year. ymmv with "--trim=unsafe-warn" =3
- andriamanitra 9mo ago
  If you need to deal with matrices Julia's built-in support for that kind of stuff is the best out of any language I've ever seen (and I've tried dozens of different languages). It's like having first-class numpy arrays without installing any third party packages, and the syntax is even more convenient than Python. The standard library is reasonably comprehensive (not quite as big as in Python or Ruby or Go, but it's usually more well-designed). It is also an excellent language for messing about because the language and especially the REPL have tons of quality-of-life features. I often use it when I want to do something interactively (eg. inspect a data set, draw a graph, or figure out what's going on with an Unicode string, or debug some bitwise trickery). What Julia is not great at is things where you need minimal overhead. It is performant for serious number crunching like simulations or machine learning tasks, but the runtime is quite heavy for simple scripting and command-line tools (where the JIT doesn't really get a chance to kick in).
- qalmakka 9mo ago
  My two cents: while Julia is arguably more complex than Go, it's type system and especially its data types (N-dimensional arrays, ...) make it way more suited anything that needs to process complex data, or do anything that's even closely related to geometry. `.|>` is wonderful and makes functional-like code easier, and that's just the tip of the iceberg, macros are also beautiful and absurdly useful. Also LLVM more often than not generates faster code than the Go backend, albeit the slowdown at startup in Julia programs is often a dealbreaker for small scripts and iteration in my experience Also, the REPL. Julia's REPL is vastly better than any other language REPL, by far. Python's is good but Julia is way better, even as a calculator for instance, it has fractions and it is more suited for maths
  - dandanua 9mo ago
    Yeah, Julia's REPL deserves special attention as it allows to do the package management (by pressing "]"), look for the functions help ("?") and do shell operations (";") without leaving it.
- xeonmc 9mo ago
  Its syntax is great for math and has a comprehensive ecosystem of scientific computing libraries stewarded by that timelord guy from Men in Black 3.
- dandanua 9mo ago
  Julia is not an alternative to Go. It is the alternative to Python (slow) and to C++ (hard and complex). Go is fast and simple but doesn't have abstractions to create complex code required by math libraries.
- a-french-anon 9mo ago
  You want real macros and a type system actually designed instead of "grown" on top of C/Aleph.
- SatvikBeri 9mo ago
  We use Julia at our quant fund. We looked into it and several other alternatives 5 years ago as a more performant replacement for numpy/scipy/etc., and Go was one of the alternatives we considered, along with things like numba and writing C extensions. Julia won for a very simple reason: we tried porting one of our major pipelines in several languages, and the Julia version was both the fastest to port and the most performant afterwards. Plus, Julia code is very easy to read/write for researchers who don't necessarily have a SWE background, while Go or C++ are not. We started using Julia in the Research Infrastructure team, but other teams ended up adopting it voluntarily because they saw the performance gains.
- sinnsro 9mo ago
  While others have mentioned plenty of reasons, for this particular case I want to highlight 3 things: 1. Julia has great tooling for operations research/linear programming. JuMP provides an standardise interface to interact with solvers (e.g., Gurobi, CPLEX) via wrapper libraries. 2. I like its overall ergonomics. It is fast enough that a programmer might not need to use a compiled language for performance. The type system allows for multiple dispatch. And the syntax is more approachable than say Python for matrix algebra. 3. I would say the performance is overstated by the community but out of the box it is good enough to avoid languages like C/C++ to build solutions. The two-language problem in academia is real, and Julia helps to reduce that gap somewhat in certain fields.
  - SatvikBeri 9mo ago
    > might not need to use a compiled language A very minor nit: Julia is a compiled language, but it has an unusual model where it compiles functions the first time they're used. This is why highly-optimized Julia can have pretty extreme performance. > I would say the performance is overstated by the community but out of the box it is good enough to avoid languages like C/C++ to build solutions. For about a year we had a 2-hour problem in our hiring pipeline where the main goal was to write the fastest code possible to do a task, and the best 2 solutions were in Julia. C++ was a close third, and Rust after that.
    - sinnsro 9mo ago
      > A very minor nit: Julia is a compiled language Caught. Should have just listed the usual suspects (C, C++, maybe Rust nowadays?). > and the best 2 solutions were in Julia. C++ was a close third, and Rust after that. Awesome. Which type of problem was this, if you can share?
      - SatvikBeri 9mo ago
        It was roughly "given this dataset with 100 time series, write code to calculate these statistics as performantly as possible. Make one single-threaded version and one using 4 cores." The C++ versions were around ~250 lines long, and the developers generally only had time to try one approach. While the Julia versions were around ~80 lines long, and the developers had time to try several approaches. I'm sure the best theoretically possible C++ version is faster than the best Julia version, but given that we're always working with time constraints, the performance per developer hour in Julia tends to be really good in my experience.
- pjmlp 8mo ago
  Besides all the listed points, Go's type system is relatively simple for the kind of stuff done in Julia, Mathematica, R, C++,...
Hasnep 9mo ago
There is also a section of Modern Julia Workflows [1] about optimisation that gives helpful, practical advice. [1] https://modernjuliaworkflows.org/optimizing/ https://modernjuliaworkflows.org/optimizing/
jdiaz97 9mo ago
I love Julia. It's a fun language, LLMs write it better than they write Python.
- gugagore 9mo ago
  Have you heard the thought that LLM hallucinations when coding within an API / framework are feature requests against the same? I have a suspicion that Julia, owing to multiple dispatch, has a sort of regularity that makes that you said plausible. Though there is just so much more Python to train on, any I bet they even do RL with validated rewards on Python, and probably not Julia.
stabbles 9mo ago
Back in the day I had trouble convincing my C++ friends to give Julia a try, because Julia's garbage collector was a showstopper. But if you follow these performance tips related to pre-allocation, in-place mutation, avoiding temporary allocations (and maybe avoiding cycling references), you don't struggle with GC performance issues. Looking back, I think the tooling Julia had from the start, combined with the REPL, made it actually really nice to fix these performance issues. Much better than compiling and linking a binary and running it through some heap profiler tool. You could simply do julia> @time f() x.y seconds (N allocations: M bytes) and iteratively improve part of the code base instead of profiling the entire application. (To be fair: back then escape analysis was not implemented in the compiler, and it was hard to avoid silly allocations)
- VorpalWay 9mo ago
  The issue with writing high performance code in GC languages is that you end up going out of your way writing things in a strange way to avoid the GC. At that point you might as well use a non-GC language. In my experience, the most natural way to write things in Rust is usually the fastest (or close enough) as well. Note: I don't know Julia specifically, but this does apply to other GC languages like Ocaml and Java. Try reading code in those languages that avoid the GC. It looks very strange. In python it is even worse: people try to avoid for loops because they are slower than list comprehensions for example (or at least used to, I haven't written much python for some years now).
  - SatvikBeri 9mo ago
    There are some big advantages to having it in the same language. You can write the easy, non-performant version quickly and gradually refactor while having an easy test case. This is especially nice in situations where you expect to throw away a lot of the code you write, e.g. research. Also, you don't have to write most code in a super performance obsessed way – Julia makes it really easy to find the key 5% that needs to be rewritten. We've ported some tens of thousands of lines of numpy-heavy Python, and in practice our Julia code is actually more concise while being about 10x-100x more performant.
muragekibicho 9mo ago
My PhD advisor demanded I use Julia for my dissertation. Back then I was a junior programmer so Julia's one-based indexing absolutely threw me off. In retrospect, the PhD experience was miserable and using Julia contributed to my 'death by a thousand cuts'.
- gozzoo 9mo ago
  I have tried Julia few times and each time this is what stops me. I don't understand why they decided to make indexes R-like oposed to "all other languages"-like. My brain just stops working when i need to recalculate indexes and each time I'm wrong. Some people may not realize it, but when it comes to programming languages, ergonomics matter—a lot.
  - leephillips 9mo ago
    “All other languages” such as Fortran, etc.? Why are you recalculating indices? I don’t think that any Julia program I’ve ever written would need to change if Julia adopted 0-based tomorrow. You don’t typically write C-style loops in Julia; you use array functions and operators, and if you need to iterate you write `for i in array ...`. “ergonomics matter” Definitely. Ergonomics is the main reason I enjoy Julia. Performance is a bonus.
  - Certhas 9mo ago
    We had this discussion on here recently. It's really puzzling to me. Julia has the most ergonomic array interface I have worked with by far. How did 1 based indexing ever trip you up?
  - Tarq0n 9mo ago
    That's just you being unable to let go of your biases? In languages with pointers giving primacy to offsets makes sense. In every other context aligning with natural language and math (first, second, 1..n inclusive) is perfectly logical.
  - wolvesechoes 9mo ago
    And 1-based indices are much more natural and ergonomic to everyone that doesn't pretend to be a machine. When I think about n-th element of a vector, its offset is not the first thing I am interested in.
dandanua 9mo ago
For newcomers my main tip is to use views for array slices (for example, via the @view and @views macros), since by default Julia creates copies of slices. Broadcast operation (the dot syntax) is another super useful instrument for speeding up vectorized operations. You can write fast GPU code with them without resorting to GPU kernels, in some cases. Although GPU kernel programming via CUDA.jl is convenient in Julia, once you get used to it.
galdauts 9mo ago
We have been running benchmarks to compare different languages relevant to high-performance computing and unfortunately Julia still lags behind even Numba-JIT-compiled Python. Perhaps my understanding of Julia is limited, but even the Rodinia SRAD program, which was originally written in Julia, performs faster in all other implementations that aren't Julia.
- hatmatrix 9mo ago
  Do you have an idea whether these are specific types of problems that is giving Julia poorer performance? From what I recall, people were reporting better speeds with Julia than with Numba (e.g., [1]). My impression was that you are basically able to bring more of your code to LLVM with Julia than Numba, so it would make sense. [1] https://gerritnowald.wordpress.com/2022/10/03/simulating-rotors-with-julia/ https://gerritnowald.wordpress.com/2022/10/03/simulating-rot...
  - galdauts 9mo ago
    Thank you for the article! We're mainly interested in floating-point performance and energy consumption w/r/t to solving differential equations and tridiagonal systems of equations, while running on a 128-core compute node. Our current results will likely only be presented in May, but here are last year's results: https://www.cs.uni-potsdam.de/bs/research/docs/papers/2025/lssp.pdf https://www.cs.uni-potsdam.de/bs/research/docs/papers/2025/l... Our Julia code is parallelised with FLoops.jl, but so far Numba has shown surprising performance benefits when executing code in parallel, despite being slower when executed sequentially. Therefore I can imagine that Julia might yield better results when run in a regular desktop environment.
    - jondea 9mo ago
      The JuliaParallel/rodinia repo says that the focus of those benchmarks is the CUDA versions. I suspect that the CPU versions have not had much optimization effort spent on them. Julia isn't a magic wand, but you can usually get within a factor of 2 of C++ with similar effort.
    - 9mo ago
LeanderK 9mo ago
there is still no vmap-like operation for GPUs in julia, right? How's Reactant coming along?
- stabbles 9mo ago
  There was a nice talk recently at FOSDEM about Reactant and Oceananigans.jl: https://fosdem.org/2026/schedule/event/TYF8ZD-accelerating_scientific_code_on_ai_hardware_with_reactant_jl/ https://fosdem.org/2026/schedule/event/TYF8ZD-accelerating_s...

73 points by tosh 9mo ago

pachico 9mo ago

Legitimate and honest question: in which circumstances would you choose Julia over more mainstream alternative like Go?

bandrami 9mo ago
Math. Places you might use Wolfram or Sage.
Human-Cabbage 9mo ago
Julia is aimed at scientific computing. It competes against Python with numpy/scipy, R, etc.
- ziotom78 9mo ago
  Correct, but I would add: Julia is better than Python+NumPy/SciPy when you need extreme speed in custom logic that can’t be easily vectorized. As Julia is JIT-compiled, if your code calls most of the functions just once it won’t provide a big advantage, as the time spent compiling functions can be significant (e.g., if you use some library heavily based on macros). To produce plots out of data files, Python and R are probably the best solutions.
  - jey 9mo ago
    And I would further add: In addition to performance, Julia's language and semantics are much more ergonomic and natural for mathematical and algorithmic code. Even linear algebra in Python is syntactically painful. (Yes, they added the "@" operator for matmul, but this is still true).
  - dgfl 9mo ago
    Disagree on the last statement. Makie is tremendously superior to matplotlib. I love ggplot but it is slow, as all of R is. And my work isn’t so heavy on statistics anyway. Makie has the best API I’ve seen (mostly matlab / matplotlib inspired), the easiest layout engine, the best system for live interactive plots (Observables are amazing), and the best performance for large data and exploration. It’s just a phenomenal visualization library for anything I do. I suggest everyone to give it a try. Matlab is the only one that comes close, but it has its own pros and cons. I could write about the topic in detail, as I’ve spent a lot of time trying almost everything that exists across the major languages.
    - dan-robertson 9mo ago
      I tried some Julia plotting libraries a few years ago and they had apis that were bad for interactively creating plots as well as often being buggy. I don’t have performance problems with ggplot so that’s what I tend to lean to. Matplotlib being bad isn’t much of a problem anymore as LLMs can translate from ggplot to matplotlib for you.
    - Certhas 9mo ago
      I love Makie but for investigating our datasets Python is overall superior (I am not familiar enough with R), despite Julia having the superior Array Syntax and Makie having the better API. This is simply because of the brilliant library support available in scikit learn and the whole compilation overhead/TTFX issue. For these workflows it's a huge issue that restarting your interactive session takes minutes instead of seconds.
    - versteegen 9mo ago
      I recently used Makie to create an interactive tool for inspecting nodes of a search graph (dragging, hiding, expanding edges, custom graph layout), with floating windows of data and buttons. Yes, it's great for interactive plots (you can keep using the REPL to manipulate the plot, no freezing), yes Observables and GridLayout are great, and I was very impressed with Makie's plotting abilities from making the basics easy to the extremely advanced, but no, it was the wrong tool. Makie doesn't really do floating windows (subplots), and I had to jump through hoops to create my own float system which uses GridLayout for the GUI widgets inside them. I did get it to all work nearly flawlessly in the end, but I should probably have used a Julia imGUI wrapper instead: near instant start time!
      - leephillips 9mo ago
        Are you referring to https://github.com/JuliaImGui/CImGui.jl https://github.com/JuliaImGui/CImGui.jl ?
        versteegen 9mo ago
        Yes. And I did port my GUI layer to CimGui.jl. The rest of it is pretty intertwined with Makie, didn't do that yet. The Makie version does look better than ImGui though.
  - ainch 9mo ago
    Even then, if you're familiar with NumPy it's pretty easy to switch to Jax's NumPy API, and then you can easily jit in Python as well.
    - JanisErdmanis 9mo ago
      As long as someone else does the porting and maintains the compatability between both subecosystems of thoose who prefer using Jax and thoose who prefer depending on the NumPy. Also not having zero overhead structs that one can in an array handicaps types of performance codes one can write.
markkitti 9mo ago
When I need to do serious math, I use Julia.
setopt 9mo ago
Scientific computing. AFAIK, library support for that in Go is almost nonexistent.
kryptiskt 9mo ago
Go is a total non-starter, it's not interactive at all. The competitors are things like Matlab, Mathematica, R or Python (with the right math libs). If you're weird you could use something like Haskell, APL or Lisp in this role, but you'd pay a hefty price in available libs.
- VorpalWay 9mo ago
  In what situations would a non-interactive language be a non-starter? I have never felt that I missed having a REPL when coding C++ or Rust. The only reason it is even useful in python is that the type info is laughably bad, so you need to poke things interactivly to figure out what shape of data you should even expect. (I'll take strong static typing every day, it is so much better.)
  - SatvikBeri 9mo ago
    REPLs/notebooks are really nice in situations where you don't know what you want ahead of time and are throwing away 90% of the code you write, such as trying to find better numerical algorithms to accomplish some goal, exploring poorly documented APIs (most of them), making a lot of plots for investigating, or working a bunch with matrices and Dataframes (where current static typing systems don't really offer much.)
    - VorpalWay 9mo ago
      Yeah, this is a entirely different domain than what I work in (hard real-time embedded and hard real-time Linux). Though poorly documented APIs exist everywhere, but they are not something you can rely on anyway: if it isn't documented the behaviour can change without it being a breaking change. It would be irresponsible to (intentionally) depend on undocumented behaviour. Rather you should seek to get whatever it is documented. Otherwise there is a big risk that your code will break some years down the line when someone tries to upgrade a dependency. Most software I deal with is long-lived. There is code I wrote 15 years ago that is still in production and where the code base is still evolving, and I see no reason why that wouldn't be true in another 15 years as well. At least you should write tests to cover any dependencies on undocumented behaviour. (You do have comprehensive tests right?)
wolvesechoes 9mo ago
It is highly interactive and dynamic, yet performant. And it is not only about scientific computing, for almost any application can take advantage of interactive, modifiable system, where you can explore your state at any point. In others, more static langs good debuggers help with this to lesser or larger extend, but it is not the same from my experience. So better question is: in which circumstances would you choose Julia over more mainstream-y alternative like Clojure? And here scientific and numerical angle comes to play. At the same time I think Julia is failed attempt, with unsolvable problems, but it is a different topic.
Certhas 9mo ago
On top of what others have said: In many situations the alternative to Julia isn't Go but C++ (or maybe Rust though its library support is lacking). E.g. if you are writing high-ish* performance algorithmic code that should also run on GPU. Julia also heavily prioritizes composability of libraries. And though that can be a source of bugs at times, there are things we are doing in Julia with one or two PhD students that would be practically impossible (as in require an order of magnitude more implementation work) in any other language.
huijzer 9mo ago
To replace uses where you would use Matlab or R probably. I prefer Julia over Matlab or R. So data science. For production code however, it's not great since it has no static typing. Imagine having your production code crash mid-execution with the error "Function foo not found". Only dynamic languages can do that to you.
- jondea 9mo ago
  I broadly agree that it can be hard to nail down Julia's behaviour but it does have static typing and I think it is more subtle. Function arguments and variables can be concrete types e.g. if you were implementing an approximation for sin, you could restrict arguments to Float32 if you knew it was only suitably accurate for that type.
  - huijzer 9mo ago
    > it does have static typing and I think it is more subtle. Yes sure Julia isn't fully dynamically typed, but that doesn't change the fact that it isn't fully static typed. If it was, it should be pretty easy to create static binaries and find bugs like "func not defined" at compilation time.
Joel_Mckay 9mo ago
Julia collapses entire programming paradigms into single character syntax, and often will transparently handle clean parallelism or cluster instance batching. https://docs.julialang.org/en/v1/manual/mathematical-operations/#man-dot-operators https://docs.julialang.org/en/v1/manual/mathematical-operati... Go is similar in many ways, but takes a performance hit in areas like Garbage collection. The Julia community is great, and performance projects may also be compiled into a binary image. =3
- ForceBru 9mo ago
  Judging by Julia's Discourse, compiling actual production Julia code into a standalone binary is highly nontrivial and ordinary users don't really know how and why to do this.
  - Joel_Mckay 9mo ago
    Example should still work: https://julialang.github.io/PackageCompiler.jl/dev/devdocs/binaries_part_2.html https://julialang.github.io/PackageCompiler.jl/dev/devdocs/b... They greatly improved the generated binary file size last year. ymmv with "--trim=unsafe-warn" =3
andriamanitra 9mo ago
If you need to deal with matrices Julia's built-in support for that kind of stuff is the best out of any language I've ever seen (and I've tried dozens of different languages). It's like having first-class numpy arrays without installing any third party packages, and the syntax is even more convenient than Python. The standard library is reasonably comprehensive (not quite as big as in Python or Ruby or Go, but it's usually more well-designed). It is also an excellent language for messing about because the language and especially the REPL have tons of quality-of-life features. I often use it when I want to do something interactively (eg. inspect a data set, draw a graph, or figure out what's going on with an Unicode string, or debug some bitwise trickery). What Julia is not great at is things where you need minimal overhead. It is performant for serious number crunching like simulations or machine learning tasks, but the runtime is quite heavy for simple scripting and command-line tools (where the JIT doesn't really get a chance to kick in).
qalmakka 9mo ago
My two cents: while Julia is arguably more complex than Go, it's type system and especially its data types (N-dimensional arrays, ...) make it way more suited anything that needs to process complex data, or do anything that's even closely related to geometry. `.|>` is wonderful and makes functional-like code easier, and that's just the tip of the iceberg, macros are also beautiful and absurdly useful. Also LLVM more often than not generates faster code than the Go backend, albeit the slowdown at startup in Julia programs is often a dealbreaker for small scripts and iteration in my experience Also, the REPL. Julia's REPL is vastly better than any other language REPL, by far. Python's is good but Julia is way better, even as a calculator for instance, it has fractions and it is more suited for maths
- dandanua 9mo ago
  Yeah, Julia's REPL deserves special attention as it allows to do the package management (by pressing "]"), look for the functions help ("?") and do shell operations (";") without leaving it.
xeonmc 9mo ago
Its syntax is great for math and has a comprehensive ecosystem of scientific computing libraries stewarded by that timelord guy from Men in Black 3.
dandanua 9mo ago
Julia is not an alternative to Go. It is the alternative to Python (slow) and to C++ (hard and complex). Go is fast and simple but doesn't have abstractions to create complex code required by math libraries.
a-french-anon 9mo ago
You want real macros and a type system actually designed instead of "grown" on top of C/Aleph.
SatvikBeri 9mo ago
We use Julia at our quant fund. We looked into it and several other alternatives 5 years ago as a more performant replacement for numpy/scipy/etc., and Go was one of the alternatives we considered, along with things like numba and writing C extensions. Julia won for a very simple reason: we tried porting one of our major pipelines in several languages, and the Julia version was both the fastest to port and the most performant afterwards. Plus, Julia code is very easy to read/write for researchers who don't necessarily have a SWE background, while Go or C++ are not. We started using Julia in the Research Infrastructure team, but other teams ended up adopting it voluntarily because they saw the performance gains.
sinnsro 9mo ago
While others have mentioned plenty of reasons, for this particular case I want to highlight 3 things: 1. Julia has great tooling for operations research/linear programming. JuMP provides an standardise interface to interact with solvers (e.g., Gurobi, CPLEX) via wrapper libraries. 2. I like its overall ergonomics. It is fast enough that a programmer might not need to use a compiled language for performance. The type system allows for multiple dispatch. And the syntax is more approachable than say Python for matrix algebra. 3. I would say the performance is overstated by the community but out of the box it is good enough to avoid languages like C/C++ to build solutions. The two-language problem in academia is real, and Julia helps to reduce that gap somewhat in certain fields.
- SatvikBeri 9mo ago
  > might not need to use a compiled language A very minor nit: Julia is a compiled language, but it has an unusual model where it compiles functions the first time they're used. This is why highly-optimized Julia can have pretty extreme performance. > I would say the performance is overstated by the community but out of the box it is good enough to avoid languages like C/C++ to build solutions. For about a year we had a 2-hour problem in our hiring pipeline where the main goal was to write the fastest code possible to do a task, and the best 2 solutions were in Julia. C++ was a close third, and Rust after that.
  - sinnsro 9mo ago
    > A very minor nit: Julia is a compiled language Caught. Should have just listed the usual suspects (C, C++, maybe Rust nowadays?). > and the best 2 solutions were in Julia. C++ was a close third, and Rust after that. Awesome. Which type of problem was this, if you can share?
    - SatvikBeri 9mo ago
      It was roughly "given this dataset with 100 time series, write code to calculate these statistics as performantly as possible. Make one single-threaded version and one using 4 cores." The C++ versions were around ~250 lines long, and the developers generally only had time to try one approach. While the Julia versions were around ~80 lines long, and the developers had time to try several approaches. I'm sure the best theoretically possible C++ version is faster than the best Julia version, but given that we're always working with time constraints, the performance per developer hour in Julia tends to be really good in my experience.
pjmlp 8mo ago
Besides all the listed points, Go's type system is relatively simple for the kind of stuff done in Julia, Mathematica, R, C++,...

Hasnep 9mo ago

There is also a section of Modern Julia Workflows [1] about optimisation that gives helpful, practical advice. [1] https://modernjuliaworkflows.org/optimizing/ https://modernjuliaworkflows.org/optimizing/

jdiaz97 9mo ago

I love Julia. It's a fun language, LLMs write it better than they write Python.

gugagore 9mo ago
Have you heard the thought that LLM hallucinations when coding within an API / framework are feature requests against the same? I have a suspicion that Julia, owing to multiple dispatch, has a sort of regularity that makes that you said plausible. Though there is just so much more Python to train on, any I bet they even do RL with validated rewards on Python, and probably not Julia.

stabbles 9mo ago

Back in the day I had trouble convincing my C++ friends to give Julia a try, because Julia's garbage collector was a showstopper. But if you follow these performance tips related to pre-allocation, in-place mutation, avoiding temporary allocations (and maybe avoiding cycling references), you don't struggle with GC performance issues. Looking back, I think the tooling Julia had from the start, combined with the REPL, made it actually really nice to fix these performance issues. Much better than compiling and linking a binary and running it through some heap profiler tool. You could simply do julia> @time f() x.y seconds (N allocations: M bytes) and iteratively improve part of the code base instead of profiling the entire application. (To be fair: back then escape analysis was not implemented in the compiler, and it was hard to avoid silly allocations)

VorpalWay 9mo ago
The issue with writing high performance code in GC languages is that you end up going out of your way writing things in a strange way to avoid the GC. At that point you might as well use a non-GC language. In my experience, the most natural way to write things in Rust is usually the fastest (or close enough) as well. Note: I don't know Julia specifically, but this does apply to other GC languages like Ocaml and Java. Try reading code in those languages that avoid the GC. It looks very strange. In python it is even worse: people try to avoid for loops because they are slower than list comprehensions for example (or at least used to, I haven't written much python for some years now).
- SatvikBeri 9mo ago
  There are some big advantages to having it in the same language. You can write the easy, non-performant version quickly and gradually refactor while having an easy test case. This is especially nice in situations where you expect to throw away a lot of the code you write, e.g. research. Also, you don't have to write most code in a super performance obsessed way – Julia makes it really easy to find the key 5% that needs to be rewritten. We've ported some tens of thousands of lines of numpy-heavy Python, and in practice our Julia code is actually more concise while being about 10x-100x more performant.

muragekibicho 9mo ago

My PhD advisor demanded I use Julia for my dissertation. Back then I was a junior programmer so Julia's one-based indexing absolutely threw me off. In retrospect, the PhD experience was miserable and using Julia contributed to my 'death by a thousand cuts'.

gozzoo 9mo ago
I have tried Julia few times and each time this is what stops me. I don't understand why they decided to make indexes R-like oposed to "all other languages"-like. My brain just stops working when i need to recalculate indexes and each time I'm wrong. Some people may not realize it, but when it comes to programming languages, ergonomics matter—a lot.
- leephillips 9mo ago
  “All other languages” such as Fortran, etc.? Why are you recalculating indices? I don’t think that any Julia program I’ve ever written would need to change if Julia adopted 0-based tomorrow. You don’t typically write C-style loops in Julia; you use array functions and operators, and if you need to iterate you write `for i in array ...`. “ergonomics matter” Definitely. Ergonomics is the main reason I enjoy Julia. Performance is a bonus.
- Certhas 9mo ago
  We had this discussion on here recently. It's really puzzling to me. Julia has the most ergonomic array interface I have worked with by far. How did 1 based indexing ever trip you up?
- Tarq0n 9mo ago
  That's just you being unable to let go of your biases? In languages with pointers giving primacy to offsets makes sense. In every other context aligning with natural language and math (first, second, 1..n inclusive) is perfectly logical.
- wolvesechoes 9mo ago
  And 1-based indices are much more natural and ergonomic to everyone that doesn't pretend to be a machine. When I think about n-th element of a vector, its offset is not the first thing I am interested in.

dandanua 9mo ago

For newcomers my main tip is to use views for array slices (for example, via the @view and @views macros), since by default Julia creates copies of slices. Broadcast operation (the dot syntax) is another super useful instrument for speeding up vectorized operations. You can write fast GPU code with them without resorting to GPU kernels, in some cases. Although GPU kernel programming via CUDA.jl is convenient in Julia, once you get used to it.

galdauts 9mo ago

We have been running benchmarks to compare different languages relevant to high-performance computing and unfortunately Julia still lags behind even Numba-JIT-compiled Python. Perhaps my understanding of Julia is limited, but even the Rodinia SRAD program, which was originally written in Julia, performs faster in all other implementations that aren't Julia.

hatmatrix 9mo ago
Do you have an idea whether these are specific types of problems that is giving Julia poorer performance? From what I recall, people were reporting better speeds with Julia than with Numba (e.g., [1]). My impression was that you are basically able to bring more of your code to LLVM with Julia than Numba, so it would make sense. [1] https://gerritnowald.wordpress.com/2022/10/03/simulating-rotors-with-julia/ https://gerritnowald.wordpress.com/2022/10/03/simulating-rot...
- galdauts 9mo ago
  Thank you for the article! We're mainly interested in floating-point performance and energy consumption w/r/t to solving differential equations and tridiagonal systems of equations, while running on a 128-core compute node. Our current results will likely only be presented in May, but here are last year's results: https://www.cs.uni-potsdam.de/bs/research/docs/papers/2025/lssp.pdf https://www.cs.uni-potsdam.de/bs/research/docs/papers/2025/l... Our Julia code is parallelised with FLoops.jl, but so far Numba has shown surprising performance benefits when executing code in parallel, despite being slower when executed sequentially. Therefore I can imagine that Julia might yield better results when run in a regular desktop environment.
  - jondea 9mo ago
    The JuliaParallel/rodinia repo says that the focus of those benchmarks is the CUDA versions. I suspect that the CPU versions have not had much optimization effort spent on them. Julia isn't a magic wand, but you can usually get within a factor of 2 of C++ with similar effort.
  - 9mo ago

LeanderK 9mo ago

there is still no vmap-like operation for GPUs in julia, right? How's Reactant coming along?

stabbles 9mo ago
There was a nice talk recently at FOSDEM about Reactant and Oceananigans.jl: https://fosdem.org/2026/schedule/event/TYF8ZD-accelerating_scientific_code_on_ai_hardware_with_reactant_jl/ https://fosdem.org/2026/schedule/event/TYF8ZD-accelerating_s...