# Integrating Julia with Rust?

**URL:** <https://discourse.julialang.org/t/integrating-julia-with-rust/121745>\
**Category:** General Usage\
**Created:** [October 25, 2024, 11:12am UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745 "2024-10-25T11:12:04Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![anon91151494](https://avatars.discourse-cdn.com/v4/letter/a/838e76/32.png) [@anon91151494](https://discourse.julialang.org/u/anon91151494)\
**Post date:** [October 25, 2024, 5:29pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/21 "2024-10-25T17:29:54Z")

</div>

> [@DNF](#):
>
> As far as I’ve understand, there’s lots of replacements for pip, because it’s considered out of date.

I’ve tried some of the alternatives and I didn’t really see any improvement over `pip+venv`. Without `venv`, you’re into having a system-wide environment, which I assume we all agree is not a good idea? (eg: You are likely to get conflicts between different projects.)

I have used `miniconda`/`conda`/`anaconda` quite a lot too. I use it on Windows because it’s a convenient way to get a Python install. However, I don’t like it as much as it tends to fail to resolve dependencies more often. Also it works a bit different from pip. I don’t recall exactly why it is different, so I won’t risk providing incorrect information here but essentially when I was looking into it I concluded it was less general purpose. I think I’m correct to say pip has a wider range of packages than conda, and that the two don’t work well together. (If at all?)

There are other things, `poetry` comes to mind, but iirc that’s basically a wrapper around pip with some support for uploading your packages to the main pip repo/server. Maybe I misremember this too, and it’s something else rather than `poetry`.

When I looked into the different options my conclusion was that pip was the most simple and straightforward option to use and it was sufficient in what it does to be useful. It’s also widely used, which helps, because then everyone uses a standard tooling.

> [@adienes](#):
>
> genuine question as someone with little experience with Rust or Cargo: what do you like about it that Julia can’t provide?

To answer your question here, yes it may be that I just don’t like the UX.

eg: What could be more simple than

- `cargo test`
- `cargo build --release`
- `cargo run`
- or `cargo run --bin NAME`

It works anywhere within your project repository.

By contrast, to run tests in Julia

```shell
user@linux$ julia runtest.jl

```

is the closest alternative. Not bad, but you have to be in the `test` directory. (Where `runtest.jl` lives.)

I’m still trying to figure out the most convenient way to run a “binary application”. You have to be somewhere in `src`, probably. Again, maybe I’m wrong here, I’m still new to it.

* * *

Maybe I can say something more intelligent by saying with cargo, if you want to install a package, you just run `cargo install PACKAGE`.

On the other hand, what should I do with Julia?

- One option is to run the REPL, `using Pkg` and then `Pkg.add("PACKAGE")`. Personally, I don’t like it. Even with `pip`, one can do

```shell
user@linux$ ./.venv/bin/activate
user@linux$ (.venv) pip3 install PACKAGE

```

I agree, there are problems with this. How do you deploy with Docker? Actually, there are good solutions. You set your entrypoint to

```julia
/project_name/.venv/bin/python3 -m /project_name/path/to/module

```

or, because you are in Docker, you install packages “systemwide” and don’t bother with venv. I prefer to use `venv` still, because it is consistent.

To go back to Julia, another option is:

```shell
user@linux$ julia
julia> ]
(@1.11) pkg> add PACKAGE

```

Here’s the thing. I don’t know how you productionize this.

To go back to the first option, is it a good idea to write

```julia
using Pkg
Pkg.add("PACKAGE")

```

at the top of a Julia script which is the main entrypoint for an “application”? I’m not sure about this. You are mixing _ **code** _ with _ **environment** _. No other language works this way. Is it better? Worse? Why? I don’t know. (Yet)

> [@adienes](#):
>
> not to turn this into a python-dogpile but I think if anybody has spent more than 5 minutes with pip and [Pkg.jl](https://juliahub.com/ui/Packages/General/Pkg) each and still equates them that’s cause for concern lol

Well - why? It seems a lot of people here don’t like pip much. I’m not sure I understand why. In the Python world, I would suggest it is almost universally liked.

Can you tell me a problem it has that you have difficulty with? It’s possible I can suggest a slightly different way of using it which is better for the developer experience. (Something I’m very keen on being good btw.)

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 25, 2024, 5:34pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/22 "2024-10-25T17:34:45Z")

</div>

> [@jonniedie](#):
>
> There are some workarounds, but nothing really that great. `DaemonMode` helps for the restarts

You never strictly have to restart Julia. Yes, you can’t change structs, so you need to work around that, I do a lot of my\_struct2, my\_struct\_3 etc.

Revise.jl handles everything else (and there may be a package for structs, I do not recall).

I’m thinking since structs are a know problems, and hard to work around at full speed, could some development mode for the REPL only work? Indirection solves a lot of problems, and I think it could work around this one too, at least give the illusion you can change anything at runtime (though with speed-penalty).

I would also like a developer mode at least or non-default allowing rearranging structs, closing the (potential) speed gap with Rust, improving on C++'s defaults like Rust does. Rust and Mojo also allow eager deallocation (Julia has workarounds in Bumper.jl package), at least Mojo improves on C++ that way, Julia could also by default.

> [@jonniedie](#):
>
> the fact that you can’t just `dlclose` a Rust library (at least on Linux) and have to restart the Julia REPL every time you need to make a change to the Rust code.

[Not sure why, a Linux problem, not Julia’s? And even if unsolvable:]

That seems similar to the (known) struct redefinition problem. Something I overlooked, as not inherent to Julia development, only for interop. I suppose you can rename to my\_lib2.so, my\_lib3.so etc. Maybe some package could automate, only to be used in development?

> [@anon91151494](#):
>
> Without `venv`, you’re into having a system-wide environment

See --project=. option.

I used to run with no options cumulative massive global environment. It has huge downsides, and make Pkg look much worse than it is, seeing frequent downgrades and other problems etc. But it’s misusing Julia, all avoidable.

---

<div class="post-metadata">

**Author:** ![jlapeyre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlapeyre/32/4514_2.png) [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)\
**Post date:** [October 25, 2024, 6:05pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/23 "2024-10-25T18:05:19Z")

</div>

> [@anon91151494](#):
>
> ```julia
> user@linux$ julia runtest.jl
> 
> ```
> 
> is the closest alternative. Not bad, but you have to be in the `test` directory. (Where `runtest.jl` lives.)

This is not true. It’s possible, but not a recommended way to run a test suite.

`Pkg.test()` runs the test suite for the currently active package.  
And `Pkg.test("foo"; julia_args=["--inline"])` does what it looks like does.

I recommend at a minimum reading the doc string for `Pkg.test` and `test` in the `pkg` repl. Then you could make more constructive comments.

---

<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:** [October 25, 2024, 6:18pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/24 "2024-10-25T18:18:09Z")

</div>

> [@anon91151494](#):
>
> I’m not sure I understand why. In the Python world, I would suggest it is almost universally liked.

we must live in very different Python worlds 😅.

- the resolver is VERY slow sometimes. even for medium size projects it might take several minutes
- It can try to download like a billion versions of the same package trying to find one that’s compatible
- it does said compatibility checks a lot of the time by just… fully downloading and checking rather than a smarter approach based on compat bounds
- the resolver isn’t even correct a lot of the time. I frequently find that for the same set of core dependencies the order in which I add / install them can be the difference between a clean install and a “no compatible versions found”
- the requirements.txt files do not disambiguate between direct dependencies and transitive dependencies (in Julia these are the Project.toml and Manifest.toml files) so pinning versions of direct dependencies while allowing transitive dependencies to freely upgrade (or add more or remove) is quite cumbersome
- the setup scripts can run… arbitrary code. and if the author of the package did something not super robust and you start getting like PATH issues or its trying to use the wrong environment within the setup script, god help you

---

<div class="post-metadata">

**Author:** ![anon91151494](https://avatars.discourse-cdn.com/v4/letter/a/838e76/32.png) [@anon91151494](https://discourse.julialang.org/u/anon91151494)\
**Post date:** [October 25, 2024, 6:23pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/25 "2024-10-25T18:23:51Z")

</div>

> [@Palli](#):
>
> > [@anon91151494](#):
> >
> > Without `venv`, you’re into having a system-wide environment
> 
> See --project=. option.
> 
> I used to run with no options cumulative massive global environment. It has huge downsides, and make Pkg look much worse than it is, seeing frequent downgrades and other problems etc. But it’s misusing Julia, all avoidable.

To clarify my point here - I was not suggesting run Julia without using environments. (Using global environments.)

I suppose the difference to Rust is Cargo knows when it is inside a project, because it sees a Project.toml somewhere in the directory stack.

With Julia it’s explicit. You have to say `--project=.`. I don’t see why it couldn’t be changed to be automatic, like Rust Cargo.

> [@jlapeyre](#):
>
> This is not true. It’s possible, but not a recommended way to run a test suite.
> 
> `Pkg.test()` runs the test suite for the currently active package.  
> And `Pkg.test("foo"; julia_args=["--inline"])` does what it looks like does.
> 
> I recommend at a minimum reading the doc string for `Pkg.test` and `test` in the `pkg` repl. Then you could make more constructive comments.

This is that isn’t an improvement, it’s actually much _worse_ for two reasons:

- you cannot productionize this because it requires a human to manually load the REPL, and run `using Pkg` then `Pkg.test()`. That means you cannot integrate this as part of CICD. The only way you could make this part of automated testing would be to write a short script which calls `using Pkg; Pkg.test()`, in which case you might as well just run `julia runtest.jl` from the command line
- second point is minor. In the context of human interaction with tests: It requires you to type more characters. It’s a lot less convenient than just running `julia runtests.jl` from the command line

Regardless if you are a human or a machine, it’s worse.

---

<div class="post-metadata">

**Author:** ![anon91151494](https://avatars.discourse-cdn.com/v4/letter/a/838e76/32.png) [@anon91151494](https://discourse.julialang.org/u/anon91151494)\
**Post date:** [October 25, 2024, 6:29pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/26 "2024-10-25T18:29:37Z")

</div>

> [@adienes](#):
>
> the setup scripts can run… arbitrary code. and if the author of the package did something not super robust and you start getting like PATH issues or its trying to use the wrong environment within the setup script, god help you

Nobody should be manually modifying the `PATH`, If somebody has released a package with some `PATH` hackery in it then they’re just making use of bad engineering practices - not sure what else to say.

I _know_ that lots of posts on stack overflow (etc) will contain information about doing this, but it’s the wrong solution. It seems to be a mistake on behalf of the language designers that this was allowed. I’ve never seen a legitimate use for it.

> [@adienes](#):
>
> the requirements.txt files do not disambiguate between direct dependencies and transitive dependencies (in Julia these are the Project.toml and Manifest.toml files) so pinning versions of direct dependencies while allowing transitive dependencies to freely upgrade (or add more or remove) is quite cumbersome

I agree with you this is a potential issue, but again I can’t honestly say I have seen it come up often, if at all.

In regards to your other points, yes I don’t disagree - these are all possibilities. But again, I haven’t personally seen them actually occur in real systems very often, if at all.

When things **do** go wrong, usually re-creating the `requirements.txt` file is the quickest solution.

Again, I agree _it’s a pretty trash solution and it shouldn’t be the way things are_. So yes, generally I agree with you but I think the impact of these things is often overstated, and relatively easily mitigated.

---

<div class="post-metadata">

**Author:** ![tecosaur](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tecosaur/32/23206_2.png) [@tecosaur](https://discourse.julialang.org/u/tecosaur)\
**Post date:** [October 25, 2024, 6:38pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/27 "2024-10-25T18:38:41Z")

</div>

> [@anon91151494](#):
>
> With Julia it’s explicit. You have to say `--project=.`. I don’t see why it couldn’t be changed to be automatic, like Rust Cargo.

It’s automatic like Cargo if you

```julia
export JULIA_PROJECT="@."

```

However, unfortunately this is not the default behaviour. I believe security reasons have been cited as the main reason why.

> [@anon91151494](#):
>
> - you cannot productionize this because it requires a human to manually load the REPL

Calling `julia -e 'using Pkg; Pkg.test()'` works too, but I agree it’s more awkward than `cargo test`. Arguably this is rather mitigated by being able to “sit in” the Julia REPL while developing, but I can see how this doesn’t help the new-user experience.

---

<div class="post-metadata">

**Author:** ![jonniedie](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jonniedie/32/12842_2.png) [@jonniedie](https://discourse.julialang.org/u/jonniedie)\
**Post date:** [October 25, 2024, 6:39pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/28 "2024-10-25T18:39:43Z")

</div>

> [@Palli](#):
>
> You never strictly have to restart Julia. Yes, you can’t change structs, so you need to work around that, I do a lot of my\_struct2, my\_struct\_3 etc.

This is in context of my `dlclose` comment, in which you _always_ have to restart if you want your Rust changes to take affect.

> [@Palli](#):
>
> I suppose you can rename to my\_lib2.so, my\_lib3.so etc. Maybe some package could automate, only to be used in development?

Maybe this would be possible. But I think we’d also have to make some changes where the code gets loaded as well, which sounds like it would be pretty prone to error. Plus I don’t really love the idea of having a bunch of these loaded and not getting closed.

> [@anon91151494](#):
>
> Possibly a dumb suggestion but can you write unit tests on the Rust side for your Rust implementations, thus cutting out the need to load code with Julia?

Our flight code is written in Rust and our physics simulation is written in Julia. There are a lot of things we can (and do) unit test on the Rust side, but that misses the important parts of how physics interacts with the system, especially when doing controls work.

---

<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:** [October 25, 2024, 6:40pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/29 "2024-10-25T18:40:48Z")

</div>

> [@tecosaur](#):
>
> believe security reasons have been cited as the main reason why.

> **[GitHub - StefanKarpinski/Nefarious.jl: all your base are belong to me](https://github.com/StefanKarpinski/Nefarious.jl)**
>
> all your base are belong to me

---

<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:** [October 25, 2024, 6:43pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/30 "2024-10-25T18:43:11Z")

</div>

> [@anon91151494](#):
>
> using Pkg; Pkg.test()

A common way to do this is `julia -e 'using Pkg; Pkg.test()'`. I agree with you that it’s not quite as nice as Cargo.

There is a significant advantage to the REPL workflow though: you don’t have to recompile. With Revise, if you run tests in a REPL, modify your code, and rerun tests, it’ll be much, much faster – including significantly faster than Rust.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 25, 2024, 6:53pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/31 "2024-10-25T18:53:05Z")

</div>

What are people’s _subjective_ experience for calling Julia from Rust (or the other way around, or even both direction in same project)? I like to hear from people that have actually used it? I know it’s easy to call C, also since C is an easy language, the package **jlrs** is certainly large, I think because of complexity in Rust. It seems e.g. it adds a Julia string type for interop:

> <https://github.com/Taaitaaiger/jlrs/blob/6bd0e8a1670fa83ab0d6d0c941ee41c00d95c3cc/jlrs/src/data/managed/string.rs#L23-L26>

> [@anon91151494](#):
>
> I would imagine calling to and from different languages is inefficient.

No it’s not. Already very fast to or from Julia, for e.g. Rust and Python. Some limitations apply currently e.g. for MATLAB, then no zero-copy.

> [@anon91151494](#):
>
> For example, to call Julia you presumably have to spin up a copy of the compiler process, then start it off running some Julia code.

No, already not _strictly_ needed. E.g. if you call Julia from Rust, you could be calling a precompiled package. You just want to make sure all the code, or for the relevant types is precompiled. It’s been a problem before, some learning curve, but see below on `juliac` that eliminates that. There are also other alternative AOT compilers.

In some cases JIT might be used, and in general _for generic code_, but that wouldn’t apply calling from Rust(?). The future (in 1.12-DEV already) is `juliac` where you compile apps or libraries AOT. Such is already available with many restrictions (for e.g. 1.10), juliac with almost none (e.g. none compared to Rust I believe)

> [@anon91151494](#):
>
> but why not just use Julia?

Yes, why not? 🙂 Most of the time you can “just”, meaning only use Julia. But I was answering for those that want to use those two languages (or any two+) together. It’s not a goal per se, but valuable if you have working code in another language already.

Julia has pros and cons (well any language).

Rust has also pros (better for concurrency, than most any language; Mojo also good for, I believe, with ownership model, though parallelism more of its goal) and cons. If you do not need concurrency (as opposed to parallelism) I doubt I would use Rust.

> [@anon91151494](#):
>
> You want the dynamic nature of Julia, but in Rust.

I didn’t say that, yes if I wanted to use Rust. I think it’s just not possible to change Rust to be easier in that or many other ways.

---

<div class="post-metadata">

**Author:** ![anon91151494](https://avatars.discourse-cdn.com/v4/letter/a/838e76/32.png) [@anon91151494](https://discourse.julialang.org/u/anon91151494)\
**Post date:** [October 25, 2024, 6:58pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/32 "2024-10-25T18:58:06Z")

</div>

> [@tecosaur](#):
>
> Arguably this is rather mitigated by being able to “sit in” the Julia REPL while developing, but I can see how this doesn’t help the new-user experience.

I think you already know what I am about to say, but just to emphasize this point:

- _ **what do you do when it is time to go to production** _

I understand that many people who are using Julia who are data analysts of some kind never think about such things because they never need to.

I’ve worked in both fields so I’ve seen it from both sides.

Allow me to define what I mean by _going to production_ in case it was not obvious. (It may not be depending on what kinds of firms you have worked for and in which roles.)

Going to production essentially means deploying some application to a server somewhere which is not managed by human interaction on a day-to-day basis. An _automated_ system.

Think along the lines of the webserver for this discourse website. A version of the code which runs discourse is installed on some server somewhere, someone started it from a command line, and then logged out of the system and presumably hasn’t needed to touch it except for upgrades and maintenance.

This is what I mean. An environment where (among other things) _there is no REPL_.

---

<div class="post-metadata">

**Author:** ![tecosaur](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tecosaur/32/23206_2.png) [@tecosaur](https://discourse.julialang.org/u/tecosaur)\
**Post date:** [October 25, 2024, 6:59pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/33 "2024-10-25T18:59:20Z")

</div>

> [@anon91151494](#):
>
> This is what I mean. An environment where (among other things) _there is no REPL_.

You just call the relevant command-line `julia` form? I feel like there’s a communication mishap going on here.

---

<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:** [October 25, 2024, 7:07pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/34 "2024-10-25T19:07:42Z")

</div>

> [@anon91151494](#):
>
> I understand that many people who are using Julia who are data analysts of some kind never think about such things because they never need to.
> 
> I’ve worked in both fields so I’ve seen it from both sides.

I very much appreciate all the perspective you’re bringing to this conversation. I do just want to gently note that a great number of users (including myself) here also have to “go to prod” and have also seen things from both sides. So yes, many users are notebook-only analyst types; but be careful about reducing everyone to that demo.

---

<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:** [October 25, 2024, 7:10pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/35 "2024-10-25T19:10:09Z")

</div>

Going to production in Julia at my company involves making a Docker image with the whole environment, which then runs something like `julia our_app.jl`. It’s the same workflow we use for Python.

It’s not as nice as languages that have a clean binary, like Java or Go – we end up needing pretty big Docker images in practice.

---

<div class="post-metadata">

**Author:** ![anon91151494](https://avatars.discourse-cdn.com/v4/letter/a/838e76/32.png) [@anon91151494](https://discourse.julialang.org/u/anon91151494)\
**Post date:** [October 25, 2024, 7:13pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/36 "2024-10-25T19:13:13Z")

</div>

> [@jonniedie](#):
>
> Our flight code is written in Rust and our physics simulation is written in Julia. There are a lot of things we can (and do) unit test on the Rust side, but that misses the important parts of how physics interacts with the system, especially when doing controls work.

Possibly dumb suggestion #2:

Can you write _integration tests_ and deploy those tests to a _UAT system_.

In other words (maybe)

- you write a standard, repeatable, input which you feed into your Rust flight control
- you monitor from the Rust flight control some outputs
- you spin up a server which hosts both your Julia physics simulation and your Rust flight controller
- you check to see if your output matches a previously saved output within certain tolerances
- run all of this using Docker and CICD
- this in combination with specific unit tests for your Rust and Julia codes should give some pretty strong guarantees about consistency

A possible issue I foresee with this is if you get different outputs tracking down why there is a difference could be - let’s say - at least non-trivial.

> [@Satvik](#):
>
> There is a significant advantage to the REPL workflow though: you don’t have to recompile.

Is having to compile that much of a barrier? You can often split code into modules, and you don’t need to compile everything everytime. I would argue all you are doing is moving your “waiting for compile delay” from one place to another.

What I would agree with you on is how certain things can interrupt your thinking.

- imaging you’re working on some complicated statistics/data science project
- the mental overhead of playing whack-a-mole with the Rust borrow checker is probably too much of a distraction
- so you use Julia
- but Julia takes a bit of time to compile your code at runtime, startup and initialize etc
- but Rust takes some time to compile your code before running
- is Julia better than Rust because of when it spends its time compiling or is it better because you have less mental overhead to manage. Isn’t it the same with Python?
- Python is super slow and will probably take all night to run our simulations. On the other hand, Rust runs our sims in 10 minutes, but it takes 1 minute to compile. Are we choosing Rust? No - because we don’t want the distractions of the borrow checker

> [@Palli](#):
>
> No, already not _strictly_ needed. E.g. if you call Julia from Rust, you could be calling a precompiled package. You just want to make sure all the code, or for the relevant types is precompiled. It’s been a problem before, some learning curve, but see below on `juliac` that eliminates that. There are also other alternative AOT compilers.

This is an interesting point. Thanks for raising this.

> [@Palli](#):
>
> I didn’t say that, yes if I wanted to use Rust. I think it’s just not possible to change Rust to be easier in that or many other ways.

It’s ok - I also want this.

> [@tecosaur](#):
>
> You just call the relevant command-line `julia` form? I feel like there’s a communication mishap going on here.

Yes exactly - my point being _you can’t_ spawn a REPL and type

```julia
julia> using Pkg
julia> Pkg.test()

```

or

```julia
julia> Pkg.add(...)

```

Sorry hope my point is clear now?

> [@Satvik](#):
>
> Going to production in Julia at my company involves making a Docker image with the whole environment, which then runs something like `julia our_app.jl`. It’s the same workflow we use for Python.
> 
> It’s not as nice as languages that have a clean binary, like Java or Go – we end up needing pretty big Docker images in practice.

I think this is a good solution. I have no objections to this - makes sense to me and it works well.

---

<div class="post-metadata">

**Author:** ![tecosaur](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tecosaur/32/23206_2.png) [@tecosaur](https://discourse.julialang.org/u/tecosaur)\
**Post date:** [October 25, 2024, 7:15pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/37 "2024-10-25T19:15:25Z")

</div>

> [@anon91151494](#):
>
> > [@tecosaur](#):
> >
> > You just call the relevant command-line `julia` form? I feel like there’s a communication mishap going on here.
> 
> Yes exactly - my point being _you can’t_ spawn a REPL and type

The communication mishap continues 🤣

If I could interest you in taking a second look at my message:

> You just call the relevant **command-line** `julia` form?

---

<div class="post-metadata">

**Author:** ![anon91151494](https://avatars.discourse-cdn.com/v4/letter/a/838e76/32.png) [@anon91151494](https://discourse.julialang.org/u/anon91151494)\
**Post date:** [October 25, 2024, 7:19pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/38 "2024-10-25T19:19:24Z")

</div>

> [@tecosaur](#):
>
> The communication mishap continues 🤣
> 
> If I could interest you in taking a second look at my message:

yeah dude I’m not disagreeing with you - somewhere previously it was suggested spinning up a REPL to run the test suite was the best approach…

Sorry for the confusion!

---

<div class="post-metadata">

**Author:** ![tecosaur](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tecosaur/32/23206_2.png) [@tecosaur](https://discourse.julialang.org/u/tecosaur)\
**Post date:** [October 25, 2024, 7:21pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/39 "2024-10-25T19:21:07Z")

</div>

All good. I think those comments are around when you’re _developing_ a Julia package _for_ production. In that scenario, I am pretty happy with `pkg> test`.

All of the REPL stuff can be done at the command line though when you need to bundle it up/ship it, it’s just a more complex invocation than with cargo.

---

<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:** [October 25, 2024, 7:27pm UTC](https://discourse.julialang.org/t/integrating-julia-with-rust/121745/40 "2024-10-25T19:27:57Z")

</div>

> [@anon91151494](#):
>
> Is having to compile that much of a barrier? You can often split code into modules, and you don’t need to compile everything everytime. I would argue all you are doing is moving your “waiting for compile delay” from one place to another.
> 
> What I would agree with you on is how certain things can interrupt your thinking.
> 
> - imaging you’re working on some complicated statistics/data science project
> - the mental overhead of playing whack-a-mole with the Rust borrow checker is probably too much of a distraction
> - so you use Julia
> - but Julia takes a bit of time to compile your code at runtime, startup and initialize etc
> - but Rust takes some time to compile your code before running
> - is Julia better than Rust because of when it spends its time compiling or is it better because you have less mental overhead to manage. Isn’t it the same with Python?
> - Python is super slow and will probably take all night to run our simulations. On the other hand, Rust runs our sims in 10 minutes, but it takes 1 minute to compile. Are we choosing Rust? No - because we don’t want the distractions of the borrow checker

Imagine you’re doing TDD. You load up the REPL with Revise.jl, your first run of tests takes ~1 minute due to compilation. Then you modify the code to add some tests and change functionality, and rerun tests. This now takes 5 seconds, and you find some failing tests. You change something else, rerun, 5 seconds.

This isn’t just moving the compile delay, it’s changing it from ~O(n) to O(1)

In my experience Rust takes ~1 minute to compile + test every time, even if your modules are relatively small, because it frequently recompiles dependencies. But my experience is a couple of years out of date, this could have changed.

[Previous page](https://discourse.julialang.org/t/integrating-julia-with-rust/121745.md?page=1)

[Next page](https://discourse.julialang.org/t/integrating-julia-with-rust/121745.md?page=3)