Julia stability vs Rust for Scientific Computing

Hi everyone! I’ve been seriously considering investing time into Julia for scientific computing and operations research, and I genuinely want it to succeed: the promise of high-level syntax with near-C performance is incredibly appealing.

That said, I recently came across discussions like “What’s is bad about Julia” (updated as December 2025) or “Why I no longer recommend Julia” which mention issues such as bugs in Base and general instability in parts of the ecosystem (The fact that sampling from a probability density could produce an incorrect result is scary to me). I’m trying to understand how much of that still applies today.

For those of you actively using Julia in scientific or production contexts:

  • How stable is the language and its core libraries right now?
  • Are bugs in Base still a practical concern, or have things matured significantly in recent versions?
  • How confident are you relying on Julia for long-term, correctness-critical work (e.g., optimization, simulations, OR models)?

To give more context, my use cases within operations research include building my own solvers (especially metaheuristics) and calling them from Python, as well as running discrete-event simulations in a language that’s significantly faster than Python.

One thing that gives me pause is the comparison with Rust. Even though Rust is newer than Julia, it seems like nobody really questions the stability of the language itself, especially in terms of correctness guarantees. That contrast makes me hesitate.

I’m also weighing alternatives, and part of me wonders whether it’s unreasonable to consider Rust for operations research workflows, given the higher development overhead.

Would really appreciate candid perspectives—especially from people who’ve used Julia in non-trivial, real-world projects.

Hi @gunner, welcome to the forum :smile:

To future readers: These posts have a tendency to go off the rails somewhat, so please consider whether you have a useful experience (positive or negative) to share before posting. Let’s not get into a side conversation about various closed issues from many years ago.

Since you mention OR, I’ll reply as one of the maintainers of JuMP.jl and https://jump.dev.

How stable is the language and its core libraries right now?

Very. Julia’s v1.0 release was in 2018. Things have slowly matured, but there have been no breaking changes. Code that you wrote in 2018 would still work with the latest Julia version. Third-party packages have their own release cadence.

Are bugs in Base still a practical concern, or have things matured significantly in recent versions?

No, and to be honest, they never really were. All software has bugs. Even very expensive commercial software. Just take a look at the release notes of Gurobi: Fixed Issues in Gurobi Optimizer 13.0 - Gurobi Optimizer Reference Manual. There are multiple correctness bugs in every release. See also the 1.5k issues in SciPy Issues · scipy/scipy · GitHub. You shouldn’t trust any software to be correct without careful validation.

Most of the issues happened when you combined two unrelated packages together. Julia doesn’t have formal interfaces, so this can work magically, but it can also lead to issues if the packages don’t share a common set of assumptions. When combining packages it is important to trust but verify.

How confident are you relying on Julia for long-term, correctness-critical work (e.g., optimization, simulations, OR models)?

Very. How long is long-term for you? JuMP has been in development for 13 years. JuMP’s v1.0 release was in March 2022, and since then we have made no breaking changes. You might compare the stability of JuMP to alternative modelling languages in Python…

especially from people who’ve used Julia in non-trivial, real-world projects.

Take a look at some of the videos from old JuMP-dev workshops:

Lots of JuMP users are in the energy modelling space. Checkout my blogpost where we cover all the various thing that people have been doing:

Open Energy Modeling at JuMP-dev | JuMP.

part of me wonders whether it’s unreasonable to consider Rust for operations research workflows, given the higher development overhead

Take a look at the Clarabel solver: Home · Clarabel jl/rs

They have a Julia implementation, where they prototype new features etc GitHub - oxfordcontrol/Clarabel.jl: Clarabel.jl: Interior-point solver for convex conic optimisation problems in Julia. · GitHub

They also have a Rust implementation GitHub - oxfordcontrol/Clarabel.rs: Clarabel.rs: Interior-point solver for convex conic optimisation problems in Rust. · GitHub, which is a more polished version of the solver.

There’s no right answer to the Julia/Rust choice. It’s a trade-off and people will pick different points on the trade-off curve depending on what is right for them.