# Julia stability vs Rust for Scientific Computing

**URL:** <https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094>\
**Category:** Optimization (Mathematical)\
**Tags:** question\
**Created:** [May 12, 2026, 11:59pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094 "2026-05-12T23:59:54Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [May 13, 2026, 10:09pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/21 "2026-05-13T22:09:40Z")

</div>

this is an interesting list of examples, thanks. the `quantile!` and `foldr` bugs should definitely be fixed! and as a side note, I think `Statistics.jl` could use more maintainers so fixing `quantile!` might be an easy first contribution; it looks like a kwarg forwarding typo.

I’ll just note that the `invmod` bug was already fixed in 1.13+, and some of these don’t really look like bugs in the first place (e.g. the `pinv` one, or the `Diagonal(d)` one is not a bug — that is user error).

both the `findmin` examples are symptoms of known warts in the `reducedim` machinery, and have a fix in [WIP: The great pairwise reduction refactor · Pull Request #58418 · JuliaLang/julia](https://github.com/JuliaLang/julia/pull/58418) unfortunate, yes, but the solution is quite hard. hopefully there will be more progress on this in proximal releases.

I think

> What it reports if you ask the same for, say, numpy?

is really the key question here. although of course maybe `numpy` won’t yield a list as fun for two reasons:

- it is a much more battle hardened library with an order of magnitude more users than Julia over a much longer period of time
- it covers a smaller API surface than “Julia + all of its stdlibs”. so the equivalent comparison would be to ask for bugs across _any_ python stdlib.

so results like this, I think, are more evidence that “bugs exist in Julia” (of course they do) and not evidence of “bugs in Base are a practical concern,” the question posed by the OP. I have myself found bugs in Julia, and I have devoted many hours of volunteer time fixing bugs in Julia. but I have also myself found bugs in the Python ecosystem, including “correctness” bugs in `Polars`, `SciPy`, `cvxpy`, `networkx`, some of which cost me full days of debugging. we can see, just browsing the issue trackers, [xarray has its own `quantile` woes](https://github.com/pydata/xarray/issues/9302), or a simple call to [`scipy.stats.linregress([0, 1], [0, 1])`](https://github.com/scipy/scipy/issues/24684) was returning incorrect fit results.

I do not mean to pick on those packages, I appreciate them and use them frequently. it is just to re-re-re-emphasize the point that has been made several times upthread that really _nothing_ is completely safe from correctness bugs and all users of all software should carefully validate their results.

For OP’s question “should I use Julia” I say if you think it will be a good fit, please do! The language gets better for each person using it, exploring different corners, writing new packages, and yes finding issues to report about bugs or performance bottlenecks.

P.S. speaking only for myself I think critical views should be welcomed. the fact that @yurivish sticks around for so long is testament that they care about the development of the language & community at least a little bit 😉 . I see no reason to believe this list was provided in bad faith (even though it does come with more implied pessimism than I personally share), and it was actually quite useful! I had no idea about the `foldr` bug and now I’m going to go ~~have my AI~~ fix it.

---

<div class="post-metadata">

**Author:** ![araujoms](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/araujoms/32/217734_2.png) [@araujoms](https://discourse.julialang.org/u/araujoms)\
**Post date:** [May 13, 2026, 10:57pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/22 "2026-05-13T22:57:05Z")

</div>

Since OP was asking about Rust, I think it would be more relevant to consider its linear algebra libraries. The most popular seem to be `nalgebra` and `faer`, which are roughly comparable to `LinearAlgebra`. It will surprise absolutely nobody to see that both have plenty of bugs: [Issues · dimforge/nalgebra · GitHub](https://github.com/dimforge/nalgebra/issues) and [Issues · sarah-quinones/faer-rs · GitHub](https://github.com/sarah-quinones/faer-rs/issues)

---

<div class="post-metadata">

**Author:** ![Antipath1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/antipath1/32/221404_2.png) [@Antipath1](https://discourse.julialang.org/u/Antipath1)\
**Post date:** [May 13, 2026, 11:09pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/23 "2026-05-13T23:09:22Z")

</div>

Hi @gunner, to steer things back to your core questions about stability, Operations Research, and the Rust vs. Julia comparison:

While I’ve only been using Julia for about half a year, I have had a really nice experience so far with Julia. I have not encountered any correctness issues, but they certainly do exist (as they do in Python, Rust, C++, or literally any language), but I have found the Julia language to be quite nice. Note, while Rust is a nice language, it does not magically solve most issues, only a certain class of issues concerning memory (Julia does have a garbage collector, which is also a solution to that problem) and data races.

What I want to say is that the most important thing is not actually how good the language is concerning its libraries and base, but instead to use modern best practices and have a good CI/CD pipeline catching errors and validating against external data. Now I will not pretend I know anything about operations research, but if it is possible to validate against data that you know is correct from external sources, that is absolute gold, since that will not only catch problems in established libraries and the language itself (rare), but problems you yourself created (extremely common). Note, none of this is Julia or Rust specific. Whatever you choose, a good CI/CD pipeline is probably the best you can do for correctness bugs.

Now Julia seems highly stable for standard use, as long as you are not actively playing around with compiler internals much, but I do not think you will need to worry about that in operations research. Automatic differentiation will probably take a while between Julia releases to reach the newest version.

The “instability” or “correctness issues” that often get highlighted, like the recent tangent in this thread using LLM-generated reports, seem to me like often synthetic edge cases or outright hallucinations rather than structural flaws you encounter in production. Relying on LLMs to parse bug trackers also conflates user error or tooling artifacts with actual mathematical correctness issues, making it a poor benchmark for language evaluation. (I want to say there is a certain irony in using an LLM to find correctness issues).

Julia also has the big advantage of having the ability to work interactively which is harder in Rust a language and you might spend a lot of time fighting the borrow checker and waiting for compilation. On the other hand, type stability in Julia is crucial to stability, and man are there sometimes weird reasons why the compiler can not correctly specialize in certain cases (though I got all of them to work after a time, just want to highlight that Julia has things one has to worry about that just don’t exist in Python or Rust).

I just think the most important part concerning correctness and stability does not come from the language but from the decision outside the language choice. Good luck with your projects, whichever language you choose!

---

<div class="post-metadata">

**Author:** ![yurivish](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yurivish/32/307_2.png) [@yurivish](https://discourse.julialang.org/u/yurivish)\
**Post date:** [May 14, 2026, 12:40am UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/24 "2026-05-14T00:40:47Z")

</div>

Just wanted to say that I spoke up since my article was mentioned, and I think some of the concerns still apply. I keep re-auditing stuff every few years in a hope to come back to using Julia someday, but don’t think that I feel comfortable yet. With Julia I always seem to run into fairly severe issues quickly and differentially often relative to other technologies, which is a perspective I don’t often see represented here.

I have a feeling of grudging respect when it comes to Rust, and the ways the type system fosters composable and reliable software have impressed me. But I don’t find myself _enjoying_ Rust anywhere near the degree that I enjoy using Julia (when it works), or Mathematica, or Clojure, partly because it lacks the tactile feeling of live feedback due to the compile-and-run cycle. But when concerns like reliability, code size, or performance take precedence it’s one of the tools I use.

Also, can confirm that this is accurate (and thank you @adienes):

> [@adienes](#):
>
> P.S. speaking only for myself I think critical views should be welcomed. the fact that @yurivish sticks around for so long is testament that they care about the development of the language & community at least a little bit 😉 . I see no reason to believe this list was provided in bad faith (even though it does come with more implied pessimism than I personally share), and it was actually quite useful! I had no idea about the `foldr` bug and now I’m going to go ~~have my AI~~ fix it.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [May 14, 2026, 4:41am UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/25 "2026-05-14T04:41:52Z")

</div>

> [@Antipath1](#):
>
> like the recent tangent in this thread using LLM-generated reports, seem to me like often synthetic edge cases or outright hallucinations rather than structural flaws you encounter in production.

It’s good to be skeptical of LLM-generated reports that haven’t been vetted by a human with sufficient knowledge, and I would consider it poor practice to spam maintainers with unvetted LLM outputs. On the other hand, it’s also not rigorous to dismiss LLM reports like this without vetting, and a one-off in an informal forum doesn’t amount to spam. Just to do one little bit of vetting, which should probably be branched into another topic if it catches on:

```julia-auto
julia> using LinearAlgebra: givens, I

julia> R = givens(1.,1.,1,2)[1] * givens(1.,1.,2,3)[1] # lazy rotation
LinearAlgebra.Rotation{Float64}(LinearAlgebra.Givens{Float64}[LinearAlgebra.Givens{Float64}(2, 3, 0.7071067811865475, 0.7071067811865475), LinearAlgebra.Givens{Float64}(1, 2, 0.7071067811865475, 0.7071067811865475)])

julia> R' # lazy adjoint rotation
LinearAlgebra.AdjointRotation{Float64, LinearAlgebra.Rotation{Float64}}(LinearAlgebra.Rotation{Float64}(LinearAlgebra.Givens{Float64}[LinearAlgebra.Givens{Float64}(2, 3, 0.7071067811865475, 0.7071067811865475), LinearAlgebra.Givens{Float64}(1, 2, 0.7071067811865475, 0.7071067811865475)]))

julia> R*Matrix(I,3,3) # visualize the 3x3 rotation
3×3 Matrix{Float64}:
  0.707107 0.5 0.5
 -0.707107 0.5 0.5
  0.0 -0.707107 0.707107

julia> R'*Matrix(I,3,3) # ...and its supposed adjoint rotation
3×3 Matrix{Float64}:
 0.707107 -0.5 0.5
 0.707107 0.5 -0.5
 0.0 0.707107 0.707107

julia> (R*Matrix(I,3,3))' # this looks more right, adjoint=inverse here
3×3 adjoint(::Matrix{Float64}) with eltype Float64:
 0.707107 -0.707107 0.0
 0.5 0.5 -0.707107
 0.5 0.5 0.707107

julia> R*(R'*[1.,0,0]) # expect [1.,0,0] by * associativity, adjoint=inverse
3-element Vector{Float64}:
  0.8535533905932735
 -0.1464466094067262
 -0.4999999999999999

julia> R*((R*Matrix(I,3,3))'*[1.,0,0])
3-element Vector{Float64}:
  0.9999999999999998
 -5.551115123125783e-17
  0.0

```

I’d consider that one substantiated. As for a Rust comparison, I stared at `nalgebra` for a bit, but I couldn’t figure out how to compose 2 Givens rotations. Not surprising, I maybe spent 2 hours total writing Rust in my life.

---

<div class="post-metadata">

**Author:** ![Antipath1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/antipath1/32/221404_2.png) [@Antipath1](https://discourse.julialang.org/u/Antipath1)\
**Post date:** [May 14, 2026, 6:12am UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/26 "2026-05-14T06:12:10Z")

</div>

Fair point, and also thanks for vetting the example. You are right it is a bug in LinearAlgebra. To clarify this a bit, I don’t want to say LLMs are incapable of surfacing real issues. I have more of the concern of the venue and context of this whole post.

Someone asked a high-level structural question about language suitability and received multiple constructive responses. And then someone drops a block of unvetted LLM output that heavily derails the conversation. Just the dropping of an LLM output forces the community to do exactly what you just did, vetting the output line by line, right in the middle of a thread that is supposed to be about the suitability of Rust vs Julia.

Though I think you might have highlighted my point a bit, which is primarily that in Julia, you found a real bug, and in Rust, you hit a massive usability wall trying to figure out how to use nalgebra. Whatever someone chooses, they are going to hit ecosystem friction, gaps in documentation (we all collectively should write sooooo much more documentation (I am no better in this regard than anyone else, unfortunately)), and plain bugs. And that is why I think rigorous CI pipelines and external safety validation are so immensely important, regardless of language choice. In an ideal world, we would have a gigantic CI infrastructure testing all of the most important Julia packages in a bunch of weird configurations, but unfortunately, none of us is rich enough for that. ☹

I think we are kind of on the same page on the need for rigor, but maybe this whole thing would be better served in an issue tracker on GitHub or a separate discussion thread so this thread can return to the OP’s questions.

---

<div class="post-metadata">

**Author:** ![greatpet](https://avatars.discourse-cdn.com/v4/letter/g/e495f1/32.png) [@greatpet](https://discourse.julialang.org/u/greatpet)\
**Post date:** [May 14, 2026, 9:36am UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/27 "2026-05-14T09:36:17Z")

</div>

> [@yurivish](#):
>
> But I don’t find myself _enjoying_ Rust anywhere near the degree that I enjoy using Julia (when it works), or Mathematica, or Clojure.

Going off topic, Wolfram Research seems to invest very little into supporting large-scale software development in Mathematica, in terms of both language features and surrounding tools, making Mathematica almost a write-only language. The interactive programming experience with the native notebook app, however, is top-notch, and puts Jupyter notebook to shame. Julia is at least a middle ground that incorporates modern software engineering practices while retaining an interactive workflow and a math’y syntax. I migrate my Mathematica code to Julia whenever I can, but it’s not always possible.

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [May 14, 2026, 10:31am UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/28 "2026-05-14T10:31:28Z")

</div>

I woke up this morning and saw @adienes hadn’t gotten to this quite interesting (though concerning!) one:

> [@yurivish](#):
>
> `foldr(*, Iterators.flatten([["a","b"],["c","d"]]))` `"badc"` `"abcd"` Right-associative reduce over a flattened sequence doesn’t give the same result as over a pre-flattened array.

I _think_ I found a simple fix [Fix interaction between `foldr` and `Iterators.flatten` · Pull Request #61806 · JuliaLang/julia](https://github.com/JuliaLang/julia/pull/61806) but we’ll see if review / the full test suite surfaces any problems with it.

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

**Edit:** I also did [fix forwarding of `beta` kwarg in `quantile!(::AbstractArray...)` · Pull Request #205 · JuliaStats/Statistics.jl](https://github.com/JuliaStats/Statistics.jl/pull/205) to address

> [@yurivish](#):
>
> `quantile!(reshape([1.,2,3,4,5],5,1), [.25,.5,.75]; alpha=0, beta=1)` `[1.5, 3.0, 4.5]` `[1.25, 2.5, 3.75]` The `beta` keyword is silently ignored for matrix inputs; you get a _different quantile definition_.

---

<div class="post-metadata">

**Author:** ![isaacsas](https://avatars.discourse-cdn.com/v4/letter/i/f6c823/32.png) [@isaacsas](https://discourse.julialang.org/u/isaacsas)\
**Post date:** [May 14, 2026, 11:51am UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/29 "2026-05-14T11:51:40Z")

</div>

What prompt did you use here? Given this found some good bugs it might be helpful for there to be some more semi-regular use of AI to search for language bugs. That seems something that could be automated, similar to how @ChrisRackauckas automates a lot of SciML boilerplate maintenance via AI-generated PRs these days.

---

<div class="post-metadata">

**Author:** ![sdanisch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sdanisch/32/1406_2.png) [@sdanisch](https://discourse.julialang.org/u/sdanisch)\
**Post date:** [May 14, 2026, 12:25pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/30 "2026-05-14T12:25:39Z")

</div>

What annoys me a bit about @yurivish blogpost is not that its wrong or anything, but the framing that it’s somehow unique to Julia, and that people keep bringing it up as a “well, its proven that Julia is a mess”. Of course if they were too annoying for @yurivish to do their everyday work, its a very fair point, and if they found something that works better, great!

But there are millions of happy Julia users and in general it’s pretty normal to find bugs in software if you look for it.  
Secondly, if you compare a 20 year old industry standard with millions in funding to a 3 year old library written by some Phd, the latter one is bound to fail on many metrics.  
To be fair, that might be the point of the blogpost, but it ignores the dimension of how things will be in the future and that it’s not necessarily an architectural problem and also not across the whole ecosystem.

I think there’s also a mindset split, some people just like to have things more strict and avoid bugs by having their compiler proof everything, and others like more freedom and are fine with occasional mishaps. I’m pretty deep in the latter group while wanting performance, therefore Julia is pretty perfect for me (btw, I haven’t had a single Julia bug in the recent 6 years or more, and most of the dependencies I use are really stable).  
If you’re in the former group, I don’t think Julia is as good (compared to e.g. Rust), although I still think its much better in that regard than Python architecturally.  
Regarding Rust, I’ve just recently read a pretty interesting blogpost (sadly cant find it right now) on how the Rust compiler only helps you avoid ~5-20% of classic correctness and security bugs, and the rest still needs having lots of testing and hardening - and part of the current image of security for Rust has mainly been because of security by obscurity, and now that its used more, people start finding pretty big bugs.

Just for the fun of it, I put claude on Python, and it also found some eye watering correctness issues (to be fair, I haven’t taken the time to verify and judge them, but it seems like that’s a similar situation for the Julia version):

| Library | Reproducer | Got | Expected | Why it matters |
| --- | --- | --- | --- | --- |
| stdlib | `random.choices(['a','b','c'], weights=[-1,5,1], k=10000)` | `Counter({'b': ~8000, 'c': ~2000})` | error or proportional sampling | Negative weight on `'a'` silently shifts |
| mass to the next bucket. Validation only catches the case where the total ≤ 0. | | | | |
| stdlib | `random.choices(['a','b','c'], cum_weights=[5,2,7], k=10000)` | `Counter({'a': ~2800, 'c': ~7200})` | error on non-monotone | Non-monotone `cum_weights` makes `'b'` |
| unselectable. No validation. | | | | |
| stdlib | `statistics.fmean([1,2,3], weights=[-1,1,1])` | `4.0` | error or value in `[1,3]` | “Mean” of three values in `[1,3]` returns 4 — outside the convex hull. |
| stdlib | `json.dumps({1: 'a', '1': 'b'})` | `'{"1": "a", "1": "b"}'` | error or merge | Produces invalid JSON with duplicate keys; round-trip silently drops one entry. Same for |
| `{True:'a','true':'b'}`. | | | | |
| stdlib | `json.dumps({1: 'a', '1': 'b'}, sort_keys=True)` | `TypeError: '<' not supported between str and int` | succeed | Internal sort runs before the documented int→str key |
| coercion. | | | | |
| stdlib | `urlparse('http://example.com/?').geturl()` | `'http://example.com/'` | unchanged | Trailing `?` (empty query) and `#` (empty fragment) silently stripped — breaks |
| signing/canonicalization round-trips. | | | | |
| stdlib | `a=dt(2026,11,1,1,30,tz=NY,fold=0); b=a.replace(fold=1); len({a,b})` | `1` | `2` | Two different absolute instants compare equal and dedupe in `set`/`dict` even though |
| `a.timestamp() != b.timestamp()`. | | | | |
| stdlib | `dt(2026,3,8,1,30,tz=NY) + timedelta(hours=1)` | `2026-03-08 02:30 EST` (a wall time the timezone says doesn’t exist) | `03:30 EDT` | `timedelta` arithmetic on aware |
| datetimes is wall-clock, not absolute. | | | | |
| numpy | `x = np.array([1,2,3], dtype=np.int8); np.where(x>1, x, 1000)` | `array([-24, 2, 3], dtype=int8)` | error or upcast | `1000` silently truncates against the array dtype. |
| `x[0]=1000`, `x.fill(1000)`, `np.full(3,1000,np.int8)` all raise — `np.where` is the silent outlier. | | | | |
| numpy | `np.array([np.nan, np.inf, 1e20]).astype(np.int64)` | `array([INT64_MIN, INT64_MIN, INT64_MIN])` (RuntimeWarning only) | `ValueError` | `np.array([nan], dtype=np.int64)` |
| raises; `astype` produces garbage. Same call, two contracts. | | | | |
| numpy | `np.histogram([1, 2, 3, np.nan, 5])` | `ValueError: autodetected range of [nan, nan] is not finite` | histogram of the four finite values | One NaN among four finite values |
| poisons auto-range. | | | | |
| numpy | `np.unique([1, np.nan, np.nan, 2])` vs `np.unique([[1,np.nan],[1,np.nan]], axis=0)` | first collapses NaNs → `[1,2,nan]`; second does NOT collapse | same semantics flat vs | |
| axis | Same operation, two answers. | | | |
| numpy | `np.intersect1d([1, np.nan], [2, np.nan])` vs `np.union1d([1, np.nan], [2, np.nan])` | `[]` vs `[1, 2, nan]` | consistent NaN semantics | Union collapses NaNs, intersection |
| treats them as unequal. | | | | |
| numpy | `np.isin([1, np.nan, 2], [np.nan])` | `[False, False, False]` | matches `unique`’s view | A third NaN semantic in the same family of set ops. |
| numpy | `x = np.random.randn(63); np.fft.irfft(np.fft.rfft(x))` | length **62** array, max err **~3.1** against `x` | round-trip identity | `rfft` discards parity; `irfft` defaults |
| to even length. No warning when input was odd; silent data corruption. | | | | |
| numpy | `np.average([1, 2, 3], weights=[-1, 1, 1])` | `4.0` | error or value in `[1, 3]` | Same negative-weight pattern as Python’s `random.choices` / `statistics.fmean`. |
| numpy | `np.argmin([1.0, np.nan, 0.5, 2.0])`; `np.argmax([1.0, np.nan, 0.5, 2.0])` | `1` and `1` | `2` and `3` | The NaN slot wins both argmin AND argmax. |
| numpy | `np.median([1, np.nan, 2])` | `nan` | `1.5` (or hard error) | Silent NaN propagation; need `np.nanmedian`. `statistics.median` raises instead. |
| numpy | `np.maximum(1, np.nan)` vs `np.fmax(1, np.nan)` | `nan` vs `1.0` | one consistent semantic | Two functions, same name shape, opposite NaN behavior. |
| numpy | `np.searchsorted([1, 2, 3, 4, np.nan], np.nan)` | `4` (i.e. _before_ the existing NaN) | well-defined | Insertion point for NaN lands inside the NaN run. |
| numpy | `np.array([1, 'two', 3.0]).dtype` | `dtype('<U32')` | error or `object` | Silent stringification; `arr[0] == 1` is now `False`. |
| numpy | `np.nansum([np.nan, np.nan])` | `0.0` | `nan` or empty-input error | “Sum of these values” is 0 when every value is NaN. |
| numpy | `np.outer(np.eye(2), np.eye(2)).shape` | `(4, 4)` | `(2, 2, 2, 2)` Kronecker-like | `np.outer` silently flattens 2-D inputs to 1-D. |
| numpy | `A=np.zeros((2,3,4)); B=np.zeros((2,4,5)); np.dot(A,B).shape` | `(2, 3, 2, 5)` | `(2, 3, 5)` (batched matmul) | `np.dot` does tensor contraction, not batched matmul. `A @ B` |
| does the latter; they diverge at 3-D. | | | | |

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [May 14, 2026, 12:40pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/31 "2026-05-14T12:40:04Z")

</div>

> [@sdanisch](#):
>
> Regarding Rust, I’ve just recently read a pretty interesting blogpost (sadly cant find it right now) on how the Rust compiler only helps you avoid ~5-20% of classic correctness and security bugs, and the rest still needs having lots of testing and hardening - and part of the current image of security for Rust has mainly been because of security by obscurity, and now that its used more, people start finding pretty big bugs.

While it’s definitely true that Rust’s compiler only catches a minority of bug types, I do think there’s more to it than just security by obscurity.

I think it has more to do with the fact that Rust appeals primarily to people who are very interested and motivated by correctness concerns, and they have developed an overall culture of people that spend a lot of time thinking about nasty corner-cases of API design, and ways to systematically avoid them.

So the compiler features basically served as a ‘seed’ that caused a correctness focused culture to crystalize around it. This is great for them, but it should be noted that it’s not without tradeoffs, just like how Rust’s technical features aren’t without tradeoffs.

Rust developers being very concerned with corner-cases, know that a lot of these things are typically caused by weird interactions between features, so when in doubt their preferred solution is to just limit the number of ways these different features can interact.

These design choices _do_ have real impacts that are felt when using these languages. It’s not just that Rust’s compiler is fussy. The language \*design\* is extremely fussy, and the third party libraries are (mostly) fussy because they have a fussy culture.

I think we do pretty good, especially in comparison to every julia dev’s favourite punching bag (Python), but it is just true that we expose a larger surface area for weird things to happen than a language like Rust, and most of our developers don’t spend nearly as much time worrying about weird ways our code can go wrong as Rust developers do.

---

<div class="post-metadata">

**Author:** ![sdanisch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sdanisch/32/1406_2.png) [@sdanisch](https://discourse.julialang.org/u/sdanisch)\
**Post date:** [May 14, 2026, 1:15pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/32 "2026-05-14T13:15:05Z")

</div>

I do agree 😉 I do feel much better about a http library written in rust than in Julia for various reasons like this! My point was more like, you can’t avoid all kind of bugs just with language design 😉

---

<div class="post-metadata">

**Author:** ![mihalybaci](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mihalybaci/32/13528_2.png) [@mihalybaci](https://discourse.julialang.org/u/mihalybaci)\
**Post date:** [May 14, 2026, 1:26pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/33 "2026-05-14T13:26:22Z")

</div>

I am mostly a Julia hobbyist, so not exactly the target audience for your question (though I am trying to use more Julia at work). But I would like to add one thing.

The main reason I don’t worry about the long-term future of the language is how many talented folks there are in the community who care enough to devote their time to Julia’s development. As we just saw in this thread, @yurivish posted a list of valid bugs and possible missing features, and within ~2 hours @stevengj had a proposed fix for one of them and within ~12 hours @mason had fixes for another two! That’s incredible to me!

If you do start programming in Julia and hit roadblocks, performance issues, or bugs, the people here are more than willing to help. Just search for posts like “My code in X language is slower than Julia”, and look at all the replies.

In the end though, the best test might just be to code the same (small) project in Julia and Rust and see which one works best for your needs.

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [May 14, 2026, 2:14pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/34 "2026-05-14T14:14:34Z")

</div>

> [@sdanisch](#):
>
> I do agree 😉 I do feel much better about a http library written in rust than in Julia for various reasons like this! My point was more like, you can’t avoid all kind of bugs just with language design 😉

Yeah, and conversely, I’m not sure I’d really trust the Rust community to do a better job making an ODE solver library or a Libm implementation than the julia folks, especailly because the sorts of ‘correctness’ issues one encounters with these numerical projects are just not the sorts of issues the core Rust community is very familiar with.

---

<div class="post-metadata">

**Author:** ![Deduction42](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/deduction42/32/9206_2.png) [@Deduction42](https://discourse.julialang.org/u/Deduction42)\
**Post date:** [May 14, 2026, 2:50pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/35 "2026-05-14T14:50:52Z")

</div>

As a short response to the _original_ question from @gunner. You have to consider if your use case fit’s the language’s vision

- Julia’s main foucus is _scientific computing_ which is more mature in Julia than Rust.
- Julia’s SciML ecosystem is developed by experts in the field and tested over numerous applications; you will not find a package ecosystem more fit for this purpose anywhere else
- You are doing _research_ where _time to prove your idea_ is critical, if you’re doing a graduate degree, you don’t want to be doing longer than you need to be. You need a language that is easy to prototype in. Rust is not it.

Rust is better at robust systems programming and application development and there are far more programmers in that field than in scientific computing. Because of this, many people criticize Julia for not solving their problems, but Julia was never _purpose built_ for most people’s problems. Julia is _primarily built_ to solve problems that arise in the numerical computing, simulation, and SciML space. Julia is niche, but niche is good if your unique problems are in that niche. Numerical computing is a completely different beast than app development, and it deserves a unique language to deal with the issues you see in that space.

If you want a good example of a Python package that does numerical heavy lifting under the hood, [PySR](https://github.com/MilesCranmer/pysr) is an excellent example that I learned a lot from. It uses [SymbolicRegression.jl](https://github.com/astroautomata/SymbolicRegression.jl). In fact, the author of these packages, @MilesCranmer, is also implemented his symbolic regression tool in Rust. If there is anyone who can authoritatively answer all your questions on this subject, it’s him.

---

<div class="post-metadata">

**Author:** ![nhz2](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nhz2/32/44428_2.png) [@nhz2](https://discourse.julialang.org/u/nhz2)\
**Post date:** [May 14, 2026, 3:47pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/36 "2026-05-14T15:47:25Z")

</div>

> [@Antipath1](#):
>
> In an ideal world, we would have a gigantic CI infrastructure testing all of the most important Julia packages in a bunch of weird configurations, but unfortunately, none of us is rich enough for that. ☹

We already more or less have this. [GitHub - JuliaCI/NanosoldierReports: A repository for human-readable reports generated by the Nanosoldier.jl CI system. · GitHub](https://github.com/JuliaCI/NanosoldierReports) tests all the Julia packages and [GitHub - Seelengrab/Supposition.jl: A Julia implementation of choice sequence based PBT, inspired by Hypothesis · GitHub](https://github.com/Seelengrab/Supposition.jl) is an almost magic tool for generating weird configurations (no LLM needed).

I used Supposition.jl heavily when making ZipArchives.jl and you can compare the bug reports [Issues · JuliaIO/ZipArchives.jl · GitHub](https://github.com/JuliaIO/ZipArchives.jl/issues) with the latest version of the rust library it was initially based on [Issues · zip-rs/zip2 · GitHub](https://github.com/zip-rs/zip2/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug)

---

<div class="post-metadata">

**Author:** ![wsmoses](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wsmoses/32/26497_2.png) [@wsmoses](https://discourse.julialang.org/u/wsmoses)\
**Post date:** [May 14, 2026, 5:12pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/37 "2026-05-14T17:12:04Z")

</div>

Since I saw autodiff mentioned on the Julia front (with Enzyme), I’m just going to chime in with a fun fact that Rust is also developping a std::autodiff ([std::autodiff - Rust](https://doc.rust-lang.org/beta/std/autodiff/index.html)), which also calls into Enzyme!

That said the Julia ecosystem for autodiff is a lot more feature-complete than the current rust one (but they’re also working on it too!).

---

<div class="post-metadata">

**Author:** ![Satvik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/satvik/32/20486_2.png) [@Satvik](https://discourse.julialang.org/u/Satvik)\
**Post date:** [May 14, 2026, 5:20pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/38 "2026-05-14T17:20:40Z")

</div>

I’ll just chime in quickly to say we’ve been using Julia as the main research/data language at our hedge fund since 2021. In that time, we’ve only really run into one major issue, which is the fact that some of the built-in Julia functions like use SIMD and there’s no easy way to turn that off, leading to slightly different results on different hardware. But that’s very common in numerical ecosystems (e.g. Python does the same thing) and a fairly niche issue.

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [May 14, 2026, 5:20pm UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/39 "2026-05-14T17:20:46Z")

</div>

wow, is that a surprising choice to put it so first class in `std` namespace? it seems surprising to me, but maybe Rust users are more autodiff-happy than I assumed?

---

<div class="post-metadata">

**Author:** ![ZuseZ4](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zusez4/32/49755_2.png) [@ZuseZ4](https://discourse.julialang.org/u/ZuseZ4)\
**Post date:** [June 5, 2026, 4:52am UTC](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/40 "2026-06-05T04:52:12Z")

</div>

Rust compiler developer here. Our compiler (rustc) is a lot less “hackable” than the julia compiler, so without putting Enzyme into rustc it was effectively impossible to use. We are working on improving that, e.g. via reflection and rustc\_public (stable\_mir). [GitHub - NVlabs/cuda-oxide: cuda-oxide is an experimental Rust-to-CUDA compiler that lets you write (SIMT) GPU kernels in safe(ish), idiomatic Rust. It compiles standard Rust code directly to PTX — no DSLs, no foreign language bindings, just Rust. · GitHub](https://github.com/NVlabs/cuda-oxide) is using such an interface already. Until such APIs become usable for Enzyme we’ve added it into rustc. I wouldn’t expect it to reach stable Rust and instead be outsourced into a crate (package) once we have the infra in place.

[Previous page](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094.md?page=1)

[Next page](https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094.md?page=3)