# Introducing Rust alongside C in Julia's source tree?

**URL:** <https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559>\
**Category:** Internals & Design\
**Created:** [January 9, 2025, 1:56am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559 "2025-01-09T01:56:11Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)\
**Post date:** [January 9, 2025, 1:56am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/1 "2025-01-09T01:56:11Z")

</div>

Just curious if anyone has ever raised the question of introducing Rust inside the Julia source tree, alongside C? I know that the Linux kernel has recently started this in their C source to improve memory safety: [Rust for Linux - Wikipedia](https://en.wikipedia.org/wiki/Rust_for_Linux). Since Julia’s GC is now multithreaded, and compilation is moving this way as well, I feel like the memory safety guarantees of Rust compared to C would help prevent any issues that could arise. Having experienced several bugs from race conditions inside Julia itself from 1.11’s multithreaded GC alone ([#56761](https://github.com/JuliaLang/julia/issues/56871), [#56759](https://github.com/JuliaLang/julia/issues/56759), [#56735](https://github.com/JuliaLang/julia/issues/56735)), I feel like the increasing complexity of the Julia runtime would be well-supported by moving parts of it to Rust, where there is more memory safety. In addition, the Julia community seems pretty on board with Rust, since `juliaup` is written with it.

(I do realise that this decision would lie with only a handful people though. Just planting some seeds.)

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [January 9, 2025, 1:58am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/2 "2025-01-09T01:58:28Z")

</div>

see [Building Julia with MMTk using BinaryBuilder by udesou · Pull Request #56989 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/56989)

---

<div class="post-metadata">

**Author:** ![d-netto](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/d-netto/32/212022_2.png) [@d-netto](https://discourse.julialang.org/u/d-netto)\
**Post date:** [January 9, 2025, 2:37am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/3 "2025-01-09T02:37:06Z")

</div>

> Having experienced several bugs from race conditions inside Julia itself from 1.11’s multithreaded GC alone

The bulk of the multithreaded GC was introduced in 1.10 and the GC threading changes between 1.10 and 1.11 were minimal.

As mentioned [here](https://github.com/JuliaLang/julia/issues/56871#issuecomment-2555802541), [here](https://github.com/JuliaLang/julia/issues/56759#issue-2719868161) and [here](https://github.com/JuliaLang/julia/issues/56735#issue-2712254017) these issues don’t reproduce on 1.10, so they don’t seem thread safety issues with Julia GC itself.

Indeed, the `mallocarrays` structure refactored in [gc: improve mallocarrays locality by vtjnash · Pull Request #56801 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/56801) was [present in 1.9](https://github.com/JuliaLang/julia/blob/8e5136fa2979885081cd502d2210633dff1d2a1a/src/gc.h#L272) when the GC was single threaded.

The other fix PR [Utilize bitshifts correctly in signals-mach.c when storing/reading the previous GC state by gbaraldi · Pull Request #53868 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/53868) refactors a bunch of bit twiddling we got wrong when manipulating the GC bits.

Not sure how using Rust would help here.

---

<div class="post-metadata">

**Author:** ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)\
**Post date:** [January 9, 2025, 2:53am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/4 "2025-01-09T02:53:15Z")

</div>

> [@d-netto](#):
>
> Indeed, the `mallocarrays` structure refactored in [gc: improve mallocarrays locality by vtjnash · Pull Request #56801 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/56801) was [present in 1.9](https://github.com/JuliaLang/julia/blob/8e5136fa2979885081cd502d2210633dff1d2a1a/src/gc.h#L272) when the GC was single threaded

I think this didn’t show up on 1.10 because `Memory` hadn’t been introduced at that point, even though the underlying data structure had a memory leak (since my code allocates tons of arrays). It sounds like we still don’t know what that bug was from though, only there was some leak from that structure(?). Rust would help greatly for such leaks, via ownership/lifetimes, no?

> [@Oscar\_Smith](#):
>
> see [Building Julia with MMTk using BinaryBuilder by udesou · Pull Request #56989 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/56989)

This sounds pretty interesting. Is there a devdocs guide somewhere? Or maybe it’s literally just landing?

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [January 9, 2025, 3:04am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/5 "2025-01-09T03:04:53Z")

</div>

The first part (adding support for MMTK if you compile your own copy of it) landed yesterday, and the 2nd part (binarybuilder support so you can get it if you compile Julia regularly with the right build flag set) is the PR I linked which isn’t merged. Expect more devdocs on this sort of thing closer to release.

---

<div class="post-metadata">

**Author:** ![d-netto](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/d-netto/32/212022_2.png) [@d-netto](https://discourse.julialang.org/u/d-netto)\
**Post date:** [January 9, 2025, 3:36am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/6 "2025-01-09T03:36:45Z")

</div>

> It sounds like we still don’t know what that bug was from though, only there was some leak from that structure(?). Rust would help greatly for such leaks, via ownership/lifetimes, no?

I can think of two possible explanations for this bug.

One explanation (unlikely), is that we somehow got the list implementation wrong. This seems like a software engineering issue that could have been solved by implementing a high-quality container inside Julia and covering it with extensive unit testing, or using a well-tested implementation provided by some language’s standard library (e.g. C++'s STL).

Rust could have helped here, but it would have helped just because it’s a language with a rich and well-tested standard library, not because of its memory safety properties (after all, the [linked list implementation provided by their standard library](https://github.com/rust-lang/rust/blob/e26ff2f9086fc449b963df578f8641c31846abe6/library/alloc/src/collections/linked_list.rs#L173) has a considerable amount of unsafe code that manipulates raw pointers). It doesn’t differ from C++ here.

The other explanation for this bug that I can think of is that the list has a very poor layout that’s fragmenting Libc’s allocator and making it request more and more pages. This is an issue of the underlying allocator and we could be vulnerable to that even if we used Rust.

---

<div class="post-metadata">

**Author:** ![d-netto](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/d-netto/32/212022_2.png) [@d-netto](https://discourse.julialang.org/u/d-netto)\
**Post date:** [January 9, 2025, 3:50am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/7 "2025-01-09T03:50:14Z")

</div>

That being said, Rust seems like a fine language for implementing GCs. Steve Blackburn’s team even wrote a paper about it: [https://www.steveblackburn.org/pubs/papers/rust-ismm-2016.pdf](https://www.steveblackburn.org/pubs/papers/rust-ismm-2016.pdf).

I just don’t see how it would be better than other languages at solving the particular issues outlined above.

---

<div class="post-metadata">

**Author:** ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)\
**Post date:** [January 9, 2025, 8:43am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/8 "2025-01-09T08:43:20Z")

</div>

> [@d-netto](#):
>
> not because of its memory safety properties (after all, the [linked list implementation provided by their standard library](https://github.com/rust-lang/rust/blob/e26ff2f9086fc449b963df578f8641c31846abe6/library/alloc/src/collections/linked_list.rs#L173) has a considerable amount of unsafe code that manipulates raw pointers).

This isn’t correct - you couldn’t write such code unless you were to write `unsafe { ... }`, which loses all memory safety guarantees provided by the compiler and is almost always avoided. In other words this would not be normal Rust code.

Safe Rust doesn’t allow you to write code exactly as you would in C - because such patterns aren’t memory safe. It requires a redesign to satisfy the safety requirements. Which helps prevent issues such as leaks and races.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [January 9, 2025, 8:56am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/9 "2025-01-09T08:56:16Z")

</div>

> [@MilesCranmer](#):
>
> Just curious if anyone has ever raised the question of introducing Rust inside the Julia source tree, alongside C?

Yes: [Julia better rewritten in rust?](https://discourse.julialang.org/t/julia-better-rewritten-in-rust/84151)

One problem no one raised about Rust is that in BinaryBuilder we don’t have Rust toolchains for i686-w64-mingw32, aarch64-freebsd and riscv64-linux, because they are either unsupported by rustup or have incompatible runtimes with what we use. Which means we can’t compile Julia dependencies for those platforms, which would significantly complicate Julia build system there.

---

<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:** [January 9, 2025, 8:57am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/10 "2025-01-09T08:57:52Z")

</div>

> [@MilesCranmer](#):
>
> the Linux kernel has recently started this in their C source to improve memory safety

That has hit a snag, but more for philosophical and political reasons than anything to do with Rust’s merits. The more disheartening thing is how it exposed that the wider community still viewed Rust in Linux as an optional experiment at best, a tumor at worst.  
[Rust in Linux lead retires rather than deal with more “nontechnical nonsense” - Ars Technica](https://arstechnica.com/gadgets/2024/09/rust-in-linux-lead-retires-rather-than-deal-with-more-nontechnical-nonsense/)

> [@MilesCranmer](#):
>
> This isn’t correct - you couldn’t use this code unless you were to write `unsafe { ... }`

Users definitely routinely call code with `unsafe` blocks even if they don’t write any personally. [Pushing to a vector](https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#2400) has one, a blogpost estimated [7.5k/35k](https://aws.amazon.com/blogs/opensource/verify-the-safety-of-the-rust-standard-library/) of standard library functions are unsafe. Everything gets unsafe deep down, the advantage of Rust is that its idea of safety is a statically knowable language semantic.

---

<div class="post-metadata">

**Author:** ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)\
**Post date:** [January 9, 2025, 8:58am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/11 "2025-01-09T08:58:55Z")

</div>

> [@giordano](#):
>
> Yes: [Julia better rewritten in rust?](https://discourse.julialang.org/t/julia-better-rewritten-in-rust/84151)

That thread is different. It’s about _rewriting Julia_ in Rust. I’m not suggesting that. Just introducing Rust into the source tree, like what Linux did.

(That thread also looks to not motivate their question by anything, whereas this thread is motivated by real concerns about memory safety)

---

<div class="post-metadata">

**Author:** ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)\
**Post date:** [January 9, 2025, 9:11am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/12 "2025-01-09T09:11:25Z")

</div>

> [@Benny](#):
>
> Users definitely routinely call code with `unsafe` blocks even if they don’t write any personally. [Pushing to a vector](https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#2400) has one, a blogpost estimated [7.5k/35k](https://aws.amazon.com/blogs/opensource/verify-the-safety-of-the-rust-standard-library/) of standard library functions are unsafe. Everything gets unsafe deep down, the advantage of Rust is that its idea of safety is a statically knowable language semantic.

This is introducing confusion between direct use of unsafe code (unsafe) and indirect use of unsafe in safe abstractions (safe). Of course everything is unsafe deep down, but there’s a difference here. Those internal methods within LinkedList are actually unsafe to call and shouldn’t be used.

---

<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:** [January 9, 2025, 9:30am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/13 "2025-01-09T09:30:48Z")

</div>

Internals are discouraged already, the unsafety is the lesser factor there. You’re technically right, but I’m trying to say it doesn’t mean you shouldn’t use either at all, it’s that you have to handle either carefully. Rust marking unsafe code makes it easier to analyze and handle, Julia started to mark public API for similar purposes. We’re not going to get a safe-Rust linked list anytime soon, so if we need a linked list now, no reason not to handle it carefully. Whether we need a linked list is a different question, often answered “no.”

---

<div class="post-metadata">

**Author:** ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)\
**Post date:** [January 9, 2025, 11:48am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/14 "2025-01-09T11:48:05Z")

</div>

> [@giordano](#):
>
> One problem no one raised about Rust is that in BinaryBuilder we don’t have Rust toolchains for i686-w64-mingw32, aarch64-freebsd and riscv64-linux, because they are either unsupported by rustup or have incompatible runtimes with what we use. Which means we can’t compile Julia dependencies for those platforms, which would significantly complicate Julia build system there.

Thanks for the info. Could you expand on why these are incompatible? I see these toolchains in rustup, for example

```julia
> rustup target list | grep -e riscv64 -e i686-pc -e aarch64-unknown-none
aarch64-unknown-none
aarch64-unknown-none-softfloat
i686-pc-windows-gnu
i686-pc-windows-gnullvm
i686-pc-windows-msvc
riscv64gc-unknown-linux-gnu
riscv64gc-unknown-linux-musl
riscv64gc-unknown-none-elf
riscv64imac-unknown-none-elf

```

e.g., isn’t “`i686-pc-windows-gnu`” completely compatible with “`i686-w64-mingw32`”? And similarly there look to be multiple options for `riscv64-linux`.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [January 9, 2025, 11:59am UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/15 "2025-01-09T11:59:53Z")

</div>

> [@MilesCranmer](#):
>
> isn’t “`i686-pc-windows-gnu`” completely compatible with “`i686-w64-mingw32`”?

No:

> <https://github.com/rust-lang/rust/issues/79609>
>
> \### Summary
> 
> When cross-compiling from a Linux distribution that provides SLJL… mingw32, linker errors about \`libunwind\` symbols are a known issue (https://github.com/rust-lang/rust/issues/12859). The generally-accepted workaround is to disable exception handling (via \`-C panic=abort\`) which should disable the need to collect backtraces and eliminate the linker errors. This works on a 1.43.0 toolchain, but is broken on 1.44.0-1.48.0
> 
> \### Example of error
> Here's an example of the error, running within the \[\`BinaryBuilder.jl\` cross-compilation environment\](https://github.com/JuliaPackaging/BinaryBuilder.jl).
> 
> \`\`\`
> \# cat hello\_world.rs 
> fn main() {
> println!("Hello, World!");
> }
> \# /opt/x86\_64-linux-musl/bin/rustc --target=i686-pc-windows-gnu -C panic=abort -o /tmp/testsuite/i686-w64-mingw32/rust/hello\_world/hello\_world.exe hello\_world.rs
> error: linking with \`i686-w64-mingw32-gcc\` failed: exit code: 1
> |
> = note: "i686-w64-mingw32-gcc" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-Wl,--large-address-aware" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/rsbegin.o" "-L" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib" "/tmp/testsuite/i686-w64-mingw32/rust/hello\_world/hello\_world.hello\_world.7rcbfp3g-cgu.0.rcgu.o" "/tmp/testsuite/i686-w64-mingw32/rust/hello\_world/hello\_world.hello\_world.7rcbfp3g-cgu.1.rcgu.o" "/tmp/testsuite/i686-w64-mingw32/rust/hello\_world/hello\_world.hello\_world.7rcbfp3g-cgu.2.rcgu.o" "/tmp/testsuite/i686-w64-mingw32/rust/hello\_world/hello\_world.hello\_world.7rcbfp3g-cgu.3.rcgu.o" "/tmp/testsuite/i686-w64-mingw32/rust/hello\_world/hello\_world.hello\_world.7rcbfp3g-cgu.4.rcgu.o" "/tmp/testsuite/i686-w64-mingw32/rust/hello\_world/hello\_world.hello\_world.7rcbfp3g-cgu.5.rcgu.o" "/tmp/testsuite/i686-w64-mingw32/rust/hello\_world/hello\_world.hello\_world.7rcbfp3g-cgu.6.rcgu.o" "/tmp/testsuite/i686-w64-mingw32/rust/hello\_world/hello\_world.hello\_world.7rcbfp3g-cgu.7.rcgu.o" "-o" "/tmp/testsuite/i686-w64-mingw32/rust/hello\_world/hello\_world.exe" "/tmp/testsuite/i686-w64-mingw32/rust/hello\_world/hello\_world.1oeskw8cnf06rbmk.rcgu.o" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib" "-Wl,--start-group" "-Wl,-Bstatic" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libstd-fe449066d03836b9.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libpanic\_abort-905e0827b1faa99b.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libobject-b5919c53897ea4e7.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libaddr2line-09e1099705854178.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libgimli-a13132083f96cf01.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/librustc\_demangle-1a2a881500c3aa11.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libhashbrown-12335b7735858229.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/librustc\_std\_workspace\_alloc-03e236d940d65c13.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libunwind-67ee36f8c83e0d23.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libcfg\_if-551dfddd5bf52674.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/liblibc-119051673c0a64ec.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/liballoc-e4d213396c740246.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/librustc\_std\_workspace\_core-09a82c5ce50e9376.rlib" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libcore-e59a5606ba4e2b3b.rlib" "-Wl,--end-group" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libcompiler\_builtins-c634db1b8ae16db1.rlib" "-Wl,-Bdynamic" "-ladvapi32" "-lws2\_32" "-luserenv" "-lgcc\_eh" "-l:libpthread.a" "-lmsvcrt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "/opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/rsend.o"
> = note: /opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libstd-fe449066d03836b9.rlib(std-fe449066d03836b9.std.3uongtsb-cgu.0.rcgu.o): In function \`ZN64\_$LT$std..backtrace..BytesOrWide$u20$as$u20$core..fmt..Debug$GT$3fmt17h42ce8df8b153bc33E':
> /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\\/library\\std\\src/backtrace.rs:231: undefined reference to \`\_Unwind\_Resume'
> /opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libstd-fe449066d03836b9.rlib(std-fe449066d03836b9.std.3uongtsb-cgu.0.rcgu.o): In function \`ZN4core3ops8function6FnOnce9call\_once17h47abe59cb2be30c1E':
> /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\\library\\core\\src\\ops/function.rs:227: undefined reference to \`\_Unwind\_Resume'
> /opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libstd-fe449066d03836b9.rlib(std-fe449066d03836b9.std.3uongtsb-cgu.0.rcgu.o): In function \`ZN4core3ops8function6FnOnce9call\_once17h48798ced7406d4f4E':
> /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\\/library\\std\\src\\io/stdio.rs:563: undefined reference to \`\_Unwind\_Resume'
> /opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libstd-fe449066d03836b9.rlib(std-fe449066d03836b9.std.3uongtsb-cgu.0.rcgu.o): In function \`ZN4core3ops8function6FnOnce9call\_once17h0a2adbee20aeb7b2E':
> /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\\library\\core\\src\\ops/function.rs:227: undefined reference to \`\_Unwind\_Resume'
> /opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libstd-fe449066d03836b9.rlib(std-fe449066d03836b9.std.3uongtsb-cgu.0.rcgu.o): In function \`ZN71\_$LT$alloc..vec..IntoIter$LT$T$GT$$u20$as$u20$core..ops..drop..Drop$GT$4drop17h9354c90820e79e8dE':
> /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\\library\\alloc\\src/vec.rs:3069: undefined reference to \`\_Unwind\_Resume'
> /opt/x86\_64-linux-musl/toolchains/1.48.0-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/libstd-fe449066d03836b9.rlib(std-fe449066d03836b9.std.3uongtsb-cgu.0.rcgu.o):/rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\\library\\core\\src\\ptr/mod.rs:175: more undefined references to \`\_Unwind\_Resume' follow
> collect2: error: ld returned 1 exit status
>           
> 
> error: aborting due to previous error
> \`\`\`
> 
> \### Testing with multiple versions
> 
> I use the following script to install new versions of \`rustc\`:
> 
> \`\`\`bash
> \#!/bin/bash
> \# Usage: change\_win32\_toolchain.sh \[version\]
> 
> TOOLCHAIN\_VER=${1:-1.48.0}
> rustup toolchain add ${TOOLCHAIN\_VER}
> rustup target add --toolchain ${TOOLCHAIN\_VER} i686-pc-windows-gnu
> 
> \# Copy crt2.o in to rust, see https://github.com/rust-lang/rust/issues/32859#issuecomment-573423629
> cp /opt/i686-w64-mingw32/i686-w64-mingw32/sys-root/lib/crt2.o /opt/x86\_64-linux-musl/toolchains/${TOOLCHAIN\_VER}-x86\_64-unknown-linux-musl/lib/rustlib/i686-pc-windows-gnu/lib/crt2.o
> 
> \# Set this new toolchain as the default for all invocations of \`rustc\`
> export RUSTUP\_TOOLCHAIN=${TOOLCHAIN\_VER}-x86\_64-unknown-linux-musl
> \`\`\`
> 
> \### Version it worked on
> 
> This works on Rust 1.43.0.
> 
> \### Version with regression
> 
> This does not work on Rust 1.44.0-1.48.0

> [@MilesCranmer](#):
>
> And similarly there look to be multiple options for `riscv64-linux`.

> <https://github.com/JuliaPackaging/Yggdrasil/blob/a9b28744937ada4bee7c111053646fc979854f47/0_RootFS/Rust/build_tarballs.jl#L58>

---

<div class="post-metadata">

**Author:** ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)\
**Post date:** [January 9, 2025, 1:00pm UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/16 "2025-01-09T13:00:15Z")

</div>

> [@giordano](#):
>
> No:
> 
> [Passing `-C panic=abort` still attempts to link in `libunwind` when targeting `i686-pc-windows-gnu` on `v1.44+` · Issue #79609 · rust-lang/rust · GitHub](https://github.com/rust-lang/rust/issues/79609)

Would this [reply](https://github.com/rust-lang/rust/issues/79609#issuecomment-987107562) be possible?

* * *

Re Yggdrasil:

```julia
    # riscv64-unknown-linux-gnu # toolchain is not available

```

Oh, well this is just because the name changed. It’s now [`riscv64gc-unknown-linux-gnu`](https://doc.rust-lang.org/rustc/platform-support/riscv64gc-unknown-linux-gnu.html).

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [January 9, 2025, 2:29pm UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/17 "2025-01-09T14:29:24Z")

</div>

The Julia runtime is a bit unusual. It is not actually a terribly big or complicated program, and we generally try to move anything we can into Julia.

The code generation part of the runtime uses C++ because that’s really the only first-class API for LLVM. The way it uses C++ has been criticized by real C++ programmers as “C with method calls”, which is entirely accurate and intentional. I suspect that using Rust to interface with LLVM would be a major impediment and cause us to have to wait not only for new LLVM releases but for Rust interfaces to LLVM to catch up to those releases, and of course it’s an extra layer of potential bugs. So I don’t think replacing code generation stuff with Rust would be a win.

Then there’s the basic OS runtime stuff. This is written in C and could more plausibly be implemented in Rust. However, a very large amount of this would have to be unsafe. As I said, it’s a very unusual program: it inherently needs to do a lot of unsafe (in the Rust sense) low level memory manipulation and does very little dynamic memory allocation that isn’t subsequently managed by Julia’s own GC. There’s a very small amount of concurrent data structure work, but it’s pretty minimal and unlikely to grow or change too much. Rust could maybe help there, but it seems better to keep the runtime as simple and lowest common denominator as possible, which favors C.

---

<div class="post-metadata">

**Author:** ![MilesCranmer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/milescranmer/32/21070_2.png) [@MilesCranmer](https://discourse.julialang.org/u/MilesCranmer)\
**Post date:** [January 9, 2025, 4:12pm UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/18 "2025-01-09T16:12:06Z")

</div>

Thanks Stefan - I really appreciate you taking the time to think this through and share a thorough explanation. Your reasoning about simplicity makes perfect sense, especially given Julia’s philosophy of moving more into Julia itself. The MMTk work seems like an interesting exploration in this space and I’m excited to see that progress.

---

<div class="post-metadata">

**Author:** ![Craig\_Hamel](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/craig_hamel/32/202434_2.png) [@Craig\_Hamel](https://discourse.julialang.org/u/Craig_Hamel)\
**Post date:** [January 10, 2025, 6:53pm UTC](https://discourse.julialang.org/t/introducing-rust-alongside-c-in-julias-source-tree/124559/19 "2025-01-10T18:53:41Z")

</div>

Over the holidays I did mess around with trying to implement parts of the julia runtime in rust via [inkwell](https://thedan64.github.io/inkwell/inkwell/index.html) as an LLVM generator just as a fun exercise to learn a little rust and learn some of the inter-workings of IR that was a mystery to me prior. [pest](https://pest.rs/) also made it really easy to make a pretty robust parser/lexer for “most” of of the language with out too much thought.

I got as far as implementing a mirror of `Symbol`, `DataType`, `Val`, etc. and some of `boot.jl` in `Base` before I started getting over my head and it turning into more than a “fun side project”.

But like @StefanKarpinski mentioned there is a lag in the rust LLVM wrappers and LLVM itself. I was using LLVM 14 I think to get everything to play nice.

The lack of file IO support in the MPI wrappers in the rust ecosystem could also be a detriment to some of the julia ecosystem.