# Blog post: Rust vs Julia in scientific computing

**URL:** <https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711>\
**Category:** Offtopic\
**Tags:** rust\
**Created:** [July 17, 2023, 10:17pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711 "2023-07-17T22:17:20Z")\
**Posts on this page:** 20\
**Page:** 6

<div class="post-metadata">

**Author:** ![j\_u](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/j_u/32/219081_2.png) [@j\_u](https://discourse.julialang.org/u/j_u)\
**Post date:** [July 20, 2023, 9:02pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/101 "2023-07-20T21:02:41Z")

</div>

I have to admit that I got a feeling it could be much more difficult then Julia and the adventure could be indeed time consuming, however, frustrating …? This is surprising.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [July 20, 2023, 9:07pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/102 "2023-07-20T21:07:06Z")

</div>

> [@xiaoxi](#):
>
> It is very difficult, very frustrating and time consuming.

I started learning C++ recently, with no prior experience with static languages, and I’m so far finding it surprisingly straightforward. Julia experience is tremendously helpful.

How hard is Rust compared to C++?

---

<div class="post-metadata">

**Author:** ![xiaoxi](https://avatars.discourse-cdn.com/v4/letter/x/a9adbd/32.png) [@xiaoxi](https://discourse.julialang.org/u/xiaoxi)\
**Post date:** [July 20, 2023, 9:08pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/103 "2023-07-20T21:08:44Z")

</div>

> [@j\_u](#):
>
> I have to admit that I got a feeling it could be much more difficult then Julia and the adventure could be indeed time consuming, however, frustrating …? This is surprising.

> [@DNF](#):
>
> How hard is Rust compared to C++?

Learning Rust is very frustrating because until you understand how Rust manages memory and the borrow checker, you will be fighting the compiler.

For instance, this piece of code doesn’t compile.

```julia-auto
let s1 = String::from("hello");
let s2 = s1;
println!("{}, world!", s1);

```

---

<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:** [July 20, 2023, 9:10pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/104 "2023-07-20T21:10:57Z")

</div>

I’ve heard the opposite, but it’s very dependent on where people come from, I suppose. A couple other blogs from dual-citizen Julian-Rustaceans love Rust, they acknowledge that its different model of variables and memory (closer to C++'s) would be difficult for Julians (more like Python’s) to learn, and even C++ people griped about the borrow-checking, but they say it’s not worse than any other unfamiliar thing, and it only gets that reputation because it’s new to so many people. I haven’t jumped into Rust myself so I can’t speak from personal experience.

The borrow checker isn’t that hard to grasp, at least on a broad level imo. We need a GC for mutable instances because we can’t guarantee we didn’t leave some references around. The analogy breaks down a bit because mutability is more a property of variables and references, but Rust’s ownership guarantees that references don’t outlive their origin and that you can’t have \>1 mutable reference to the same thing at a time (which is the reason why mutable types exist in Julia). So it makes sense why they don’t need a GC and don’t run into data races.

---

<div class="post-metadata">

**Author:** ![mrufsvold](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mrufsvold/32/31600_2.png) [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)\
**Post date:** [July 20, 2023, 9:24pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/105 "2023-07-20T21:24:49Z")

</div>

I tried to jump into Rust. I didn’t get stuck on the Borrow Checker so much as the mechanics of unwrapping Option Types. The concept is simple enough, but know what options there are, the syntax for catching them, and what do in chains of methods with many different options really threw me. It wasn’t any harder than any new thing, but Rust has many compounding new things that can make it hard to focus on learning any one of them. I didn’t even make it to `impl` blocks and the like because it was just too much for me at the time.

I have nothing but respect for Rust, to be clear. But its learning curve is definitely steeper than just a memory management model.

---

<div class="post-metadata">

**Author:** ![xiaoxi](https://avatars.discourse-cdn.com/v4/letter/x/a9adbd/32.png) [@xiaoxi](https://discourse.julialang.org/u/xiaoxi)\
**Post date:** [July 20, 2023, 9:53pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/106 "2023-07-20T21:53:53Z")

</div>

> [@mrufsvold](#):
>
> Rust has many compounding new things that can make it hard to focus on learning any one of them.

> Thanks to a consistent focus on ergonomics, Rust has become considerably easier to use over the last few years. Companies building large teams of Rust users report that the typical onboarding time for a Rust engineer is around 3-6 months. Once folks learn Rust, they typically love it. Even so, many people report a sense of high “cognitive overhead” in using it, and “learning curve” remains the most common reason not to use Rust. The fact is that, even after you learn how the Rust borrow checker works, there remain a lot of “small details” that you have to get just right to get your Rust program to compile.

> **[Rust Lang Roadmap for 2024 | Inside Rust Blog](https://blog.rust-lang.org/inside-rust/2022/04/04/lang-roadmap-2024.html)**
>
> Want to follow along with Rust development? Curious how you might get involved? Take a look!

---

<div class="post-metadata">

**Author:** ![Mo8it](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mo8it/32/32649_2.png) [@Mo8it](https://discourse.julialang.org/u/Mo8it)\
**Post date:** [July 20, 2023, 10:09pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/107 "2023-07-20T22:09:31Z")

</div>

> [@j\_u](#):
>
> How difficult it is to learn for a non-professional programmer?

Learning Julia is easier than learning Rust for sure. Learning to write highly optimized Julia code teaches you a lot of things that are very helpful while learning Rust.

Having to use composition instead of inheritance in Julia does make getting into Rust also easier.

I would recommend learning Julia first if you are in the scientific computing field and then starting with [THE Rust book](https://doc.rust-lang.org/stable/book/). Not only because it makes learning Rust easier, but because knowing Julia is also a very good skill in scientific computing.

It takes some weeks to about 2 months to be confident in writing Rust code. You could compare it a bit to the [results from Google](https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html).

> [@j\_u](#):
>
> Is there a support for quantum computing?

There where two talks about quantum computing in Rust in the conference. You can check them out on YouTube: [https://www.youtube.com/@ScientificComputinginRust](https://www.youtube.com/@ScientificComputinginRust)

> [@j\_u](#):
>
> How would you assess its environment directly related to machine learning?

I don’t have experience in machine learning in Rust, but this website could be a good resource: [https://www.arewelearningyet.com/](https://www.arewelearningyet.com/)

> [@j\_u](#):
>
> I have to admit that I got a feeling it could be much more difficult then Julia and the adventure could be indeed time consuming, however, frustrating …? This is surprising.

For me personally, it was not frustrating, but you have to unlearn some patterns from other languages. Maybe it was not that frustrating to me because I did not directly start to code in Rust and read the first chapters of the book first. I would definitely recommend against starting to code before going through the first chapters.

Compared to C++, Rust is in my opinion easier. Most importantly, there is no SEGFAULT which is very hard to debug in C++. The tooling in Rust is also much better than in C++.

---

<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:** [July 20, 2023, 10:11pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/108 "2023-07-20T22:11:28Z")

</div>

Interesting benchmark, but given your analysis, I have this suggested edit to benchmark the steps separately:

```julia
function pushtest(v, m)
  # the m push!es should take almost all the time
  sizehint!(v, m) # does nothing if already m capacity
  for i in 1:m push!(v, i) end
  empty!(v) # prevent memory leak, should keep capacity
end

function settest(v, m)
  for i in 1:m v[i] = i end
  v
end

function benchmarkalloc2()
  m = 2^14 # not repeated n times
  v = @btime sizehint!(Int[], $m)
  @btime pushtest($v, $m)
  v = @btime Vector{Int64}(undef, $m)
  @btime settest($v, $m)
  nothing
end

```

And the result:

```julia
julia> benchmarkalloc2() # Julia v1.8.3, if it matters
  382.187 ns (2 allocations: 128.12 KiB)
  80.779 μs (0 allocations: 0 bytes)
  394.334 ns (2 allocations: 128.05 KiB)
  1.422 μs (0 allocations: 0 bytes)

julia> benchmark_alloc() # original benchmark on my machine
  23.232 ms (512 allocations: 32.03 MiB)
  2.890 ms (512 allocations: 32.01 MiB)

```

So the array allocation steps are comparable (I don’t think the dozen ns is a real advantage, probably just OS jitter), and the `push!`ing to a whole vector is really ~57x slower than `setindex!`ing the whole vector. The original benchmark mixing them together kind of averaged that difference to only ~8x. Of course replicate this on your own version and machine for consistent numbers.

This seems like a good opportunity to optimize the `push!` implementation, and it seems a much larger magnitude than the 30% speedup the ccall issue could address, though that was on a much older version so who knows what it’ll be now.

I do have a question about the Rust benchmark, is there any way you could display allocations over the course of the `main` call as well? Is it at all possible that the Rust compiler is smart enough to lift that allocation out of the loop and just sets the length to 0 each iteration?

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [July 20, 2023, 11:04pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/109 "2023-07-20T23:04:21Z")

</div>

Just some remarks while reading through your blog post:

1. _Fearless concurrency_: Yes, that is indeed a neat showcase of Rust’s ownership model. Originally invented to handle memory, but also helpful in other cases.  
In case of concurrency, there are other abstractions which prevent data races though. Imho, _channels_ support many reusable and composable [concurrency patterns](https://go.dev/talks/2012/concurrency.slide#1). Fortunately, Julia has channels out of the box even though they appear a bit under-documented as compared to Clojure or Go.

2. _Static analysis_: A well-designed static type system certainly helps in refactoring, i.e., giving that nice feeling that everything still works. So does tooling and testing though. Interestingly, many refactoring techniques have been explored and developed in Smalltalk which – compared to today’s languages – still has superior tooling, e.g., for automatically adding member variables or changing call signatures, despite being dynamically typed. Admittedly, tooling is still somewhat lacking in Julia.

3. _Error handling_: Here, static languages seem to lean towards tagged unions, i.e., sum types, nowadays whereas many dynamically typed languages prefer untagged unions and nil-punning. Both have their merits and trade-offs, but in the end writing safe code requires to design for and think of errors one-way or the other: On the one hand, sum types force you to do so. On the other hand, they can be annoying to chain through long computations and have you fall into the habit to just pass `None` along. Thus, in any case, writing safe programs requires discipline in any language. Also keep in mind, that Julia brings a runtime and errors will not necessarily end the program, but might be fixed interactively – see [here](https://thenewstack.io/nasa-programmer-remembers-debugging-lisp-in-deep-space/) for a Lisp legend.

4. _Interfaces_: Here, I mostly agree. Rust as well as other statically typed languages distinguish between parametric, i.e., functions with one implementation and possibly parameterized, trait-bound arguments, and ad-hoc polymorphism, i.e., methods of traits which can be implemented differently for different types, though and only the latter functionalities can be extended. Julia is more flexible in this respect in that all functions are generic _and_ support multiple implementations. Guess that `LinearAlgebra` or `ChainRules` might be a good place to look for examples where this enables easier or more performant implementations by defining methods for handling specific type combinations.

5. _Performance_: Would you consider `Box<dyn SomeTrait>` as a performance footgun in Rust? That type seems similar to a non-concrete type in Julia, e.g., `Ref{Real}`.

Thanks for writing this up. It’s always nice to contrast and discuss programming languages: Flame wars for life 😉

---

<div class="post-metadata">

**Author:** ![Mo8it](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mo8it/32/32649_2.png) [@Mo8it](https://discourse.julialang.org/u/Mo8it)\
**Post date:** [July 20, 2023, 11:22pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/110 "2023-07-20T23:22:24Z")

</div>

I did use [Valgrind’s DHAT](https://valgrind.org/docs/manual/dh-manual.html) without the outer loop with `n`:

```julia
# With an empty main function
$ valgrind --tool=dhat ./target/release/benchmark_alloc
…
==360== Total: 2,157 bytes in 10 blocks
…

# With m = 2^14
$ valgrind --tool=dhat ./target/release/benchmark_alloc
…
==365== Total: 133,229 bytes in 11 blocks
…

# Abstract the allocations of the empty main function
$ math 133229 - 2157
131072

# The expected size for m = 2^14 and 8 bytes for usize
$ math 8 x 2^14
131072

```

The vector is allocated.

But I did improve measuring the time for Rust in the blog post.

---

<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:** [July 20, 2023, 11:32pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/111 "2023-07-20T23:32:02Z")

</div>

> [@Mo8it](#):
>
> I did use [Valgrind’s DHAT](https://valgrind.org/docs/manual/dh-manual.html) without the outer loop with `n`:

To clarify, I wanted to know if a fresh vector is allocated per iteration, for a total of n times over the program, or if it allocates it once and reuses it per iteration as an optimization. If you mean you’re using DHAT on versions of your benchmark code without the `0..n` loop, you would not have captured that detail.

---

<div class="post-metadata">

**Author:** ![Mo8it](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mo8it/32/32649_2.png) [@Mo8it](https://discourse.julialang.org/u/Mo8it)\
**Post date:** [July 20, 2023, 11:46pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/112 "2023-07-20T23:46:37Z")

</div>

Oh, I thought you wanted to check if the compiler does not optimize out the whole vector because it is not read from.

I did run DHAT on the code currently in the blog post (with outer loop having n = 2^8) and I get the following:

```julia
==115== Total: 33,557,613 bytes in 267 blocks

```

Which is more than `2^8 * 2^14 * 8 = 33,554,432`.

I think the advantage of Rust is that it keeps track of the capacity internally:

> <https://github.com/rust-lang/rust/blob/399b068235ceea440540539b3bfd1aeb82214a28/library/alloc/src/vec/mod.rs#L1828-L1830C9>

Where Julia just outsources dealing with the capacity into C:

> <https://github.com/JuliaLang/julia/blob/d080fe6c9bbc2076a7228d43f2651831ef7f8bac/base/array.jl#L1117>

> <https://github.com/JuliaLang/julia/blob/d080fe6c9bbc2076a7228d43f2651831ef7f8bac/base/array.jl#L1070-L1071>

---

<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:** [July 21, 2023, 12:20am UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/113 "2023-07-21T00:20:58Z")

</div>

It seems certain that a new vector is allocated each iteration in Rust as well.

> [@Mo8it](#):
>
> Julia just outsources dealing with the capacity into C:

Yes, Arrays and some other Core types are implemented in C, and many things are not exposed to the Julia side. For example, `fieldnames(Vector{Int})` gives `()`, but we know that there must be metadata. I too had tracked the difference between `push!` and `setindex!` to `jl_array_grow_end` and `jl_array_grow_at_end`, the code being in array.c. As for the performance difference, I’m guessing it’s not ccall overhead but actually the algorithm.

The following is probably not relevant enough to scientific computing to be in your blog, and nobody would alter internal code on their own. But IIRC Rust bootstrapped its way to being written almost entirely in Rust down to the lowest level. I don’t know how different internal and probably unsafe Rust is, but when Rustaceans dig deep they don’t run into a different language. That’s a point in Rust’s favor, if the comparison was for core language developers.

There is a discussion on how to pull Arrays to the Julia side to wrap a buffer type on the C side, but I can’t find the link right now. In any case, I don’t think there’s a plan to put this into action soon, not much need for an overhaul instead of small fixes.

---

<div class="post-metadata">

**Author:** ![j\_u](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/j_u/32/219081_2.png) [@j\_u](https://discourse.julialang.org/u/j_u)\
**Post date:** [July 21, 2023, 12:23am UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/114 "2023-07-21T00:23:41Z")

</div>

> [@Mo8it](#):
>
> For me personally, it was not frustrating, but you have to unlearn some patterns from other languages.

Thanks for this intro and summary @Mo8it! Just to clarify, I did not say frustrating. Actually, I’ve always been finding it, I mean coding, as quite a lot of fun. Will take a look at Rust, hope to learn at least a bit about it in practice.

---

<div class="post-metadata">

**Author:** ![Mo8it](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mo8it/32/32649_2.png) [@Mo8it](https://discourse.julialang.org/u/Mo8it)\
**Post date:** [July 21, 2023, 1:07am UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/115 "2023-07-21T01:07:24Z")

</div>

> [@bertschi](#):
>
> Would you consider `Box<dyn SomeTrait>` as a performance footgun in Rust? That type seems similar to a non-concrete type in Julia, e.g., `Ref{Real}`.

No. Although it is known to have an overhead by using the heap and [performing dynamic dispatch](https://doc.rust-lang.org/book/ch17-02-trait-objects.html#trait-objects-perform-dynamic-dispatch), using it is explicit and therefore will not be an accident or a surprise. Something being a “footgun” means that it happens without an intention; “unintentionally behaves self-destructive”, [says wiktionary](https://en.wiktionary.org/wiki/shoot_oneself_in_the_foot).

In contrast to Julia silently propagating an abstract type like `Any`, Rust will not put an instance inside a `Box` unless you explicitly tell it to.

---

<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:** [July 21, 2023, 4:20am UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/116 "2023-07-21T04:20:34Z")

</div>

> [@Mo8it](#):
>
> In contrast to Julia silently propagating an abstract type like `Any`, Rust will not put an instance inside a `Box` unless you explicitly tell it to.

On top of this, there actually is a `Box` footgun in Julia:

```julia
julia> function foo()
         x = 1
         x = 2
         bar(y) = x,y # closure captures x as a field
       end
foo (generic function with 1 method)

julia> foo().x
Core.Box(2)

```

`Box` acts like a featureless `Ref{Any}`, and it’s there because the captured variable is reassigned, so the closure’s field type is made mutable. For now, the compiler can only infer `Core.Box` for a mutable field, and since it represents the same captured variable `x`, `x` is also type-unstable, even though it would be stable without the closure. This issue can’t be improved in all cases, say if `bar(y) = x=y`, then `foo()` could never infer `bar.x` to be anything specific because `y` could be anything. However, there are many cases like this that surprise people because the compiler is otherwise much better than them at type inference.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [July 21, 2023, 5:41pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/117 "2023-07-21T17:41:18Z")

</div>

9 posts were split to a new topic: [Is accessing an `undef` array undefined behavior?](https://discourse.julialang.org/t/is-accessing-an-undef-array-undefined-behavior/101899)

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 21, 2023, 9:53am UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/120 "2023-07-21T09:53:04Z")

</div>

> [@bertschi](#):
>
> Also keep in mind, that Julia brings a runtime and errors will not necessarily end the program, but might be fixed interactively – see [here](https://thenewstack.io/nasa-programmer-remembers-debugging-lisp-in-deep-space/) for a Lisp legend.

Note that [the conditions-restarts kind of error handling from Common Lisp](https://gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html) is not available in Julia.

Errors are caught, or not, and then they end the program. But you can’t go back to the inside of the stack to fix them.

---

<div class="post-metadata">

**Author:** ![ToucheSir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/touchesir/32/14411_2.png) [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)\
**Post date:** [July 21, 2023, 3:44pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/121 "2023-07-21T15:44:29Z")

</div>

> [@Benny](#):
>
> There is a discussion on how to pull Arrays to the Julia side to wrap a buffer type on the C side, but I can’t find the link right now. In any case, I don’t think there’s a plan to put this into action soon, not much need for an overhaul instead of small fixes.

As I recall the last word on this was the proposal linked in [Buffer types for array backend by Tokazama · Pull Request #48728 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/48728#issuecomment-1557833352). At the time it felt like there was a heightened sense of urgency given how many issues this would unblock, but perhaps someone in the know can provide an update since there’s been no news since?

> [@Mo8it](#):
>
> No. Although it is known to have an overhead by using the heap and [performing dynamic dispatch](https://doc.rust-lang.org/book/ch17-02-trait-objects.html#trait-objects-perform-dynamic-dispatch), using it is explicit and therefore will not be an accident or a surprise. Something being a “footgun” means that it happens without an intention; “unintentionally behaves self-destructive”, [says wiktionary](https://en.wiktionary.org/wiki/shoot_oneself_in_the_foot).
> 
> In contrast to Julia silently propagating an abstract type like `Any`, Rust will not put an instance inside a `Box` unless you explicitly tell it to.

Another thing not mentioned here but germaine to the performance discussion is that dynamic dispatch in Julia will box _all_ arguments to a method, whereas in Rust I believe it’s closer to vtable call semantics in C++. Tying this back to the discussion about array stuff, it seems to be mostly an artifact of how the C side of the Julia runtime and its calling conventions are designed, so in theory there’s more performance to be found for dynamic dispatch in Julia. That said, I only know of highly experimental compiler proposals which have tried to tackle this angle thus far.

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [July 21, 2023, 4:46pm UTC](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711/125 "2023-07-21T16:46:25Z")

</div>

Fair enough. In the end it’s probably just preference between, Julia, dynamic with optional static dispatch or, Rust, with static dispatch and explicit dynamic … Guess I made my choice long ago 😉

[Previous page](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711.md?page=5)

[Next page](https://discourse.julialang.org/t/blog-post-rust-vs-julia-in-scientific-computing/101711.md?page=7)