OrontaMedu
In a project there’ll be lots of background tasks run by DynamicSupervisor.
Each task will be making network requests to an external service and is expected to run for a few or 10-20 minutes. And a task will need to save a result into a DB.
The way a task makes an network request could be in one of 2 ways:
(1) via an Elixir library – ExternalLib.make_request(a, b, c)
(2) via an non-Elixir library (in Rust): System.cmd("external_utility", [a, b, c])
Note that both (1) and (2) are black-boxes – they may not be modified. They may only be used.
The (2) in this case is more flexible, faster, more properly implemented and generally is preferable – compared to (1).
Question: from the point of view of Elixir, background tasks, ability to run, manage them, get a return result and so on … – could the Elixir library (1) be better still than the non-Elixir one (2)?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
D4no0
Are you willing to sacrifice all the benefits of elixir for some performance? If yes then go with 2.
LostKobrakai
Yes. With external programs you have to marshall communication in both directions. Staying with elixir means you don’t need to do that.
dimitarvp
Not sure you can have something be faster when it hits the network. The CPU is just waiting for a response.
And in your case you don’t even have a Rust library to call in-process, you have an external tool.
I’d say stick to Elixir unless the Rust tool is bringing critically important benefits.
jarmo
You can use Oban for running background jobs in Elixir. Can’t see any reason why this might be a bad choice.
OrontaMedu
Which benefits? Why sacrifise in this case?
OrontaMedu
What’s "Rust library to call in-process, "? Calling Rust via NIF and Rustler?
dimitarvp
Yes, exactly that.
OrontaMedu
The job that the exteranl utility in Rust or Elixir library will do is to send several network requests. As well as returning a result to the calling Elixir code which then will be saved into a DB.
There’ll be no computation.
Do you claim implemeting it via NIF and Rustler would still be better than calling it as an utility via
System.cmd(...)?dimitarvp
I am prone to being preachy and absolutist sometimes so maybe I am not the best person to give an answer… but I am leaning to “yes”.
To me calling something in-process has less things that can go wrong. Though seriously, tools that are well-behaved are probably just as safe. (“Well-behaved” in this instance means “they respect shell conventions when having to stream data in/out from/to stdin/stdout”).
Of course I’d also seriously consider just doing the whole thing in Elixir if I can get away with it. As mentioned above, disk or network I/O are 1000x more time-expensive compared to CPU-intensive tasks so who cares if your code that will need 350ms to get back an answer from an external server is written in Rust, Go, Haskell or even Ada or Brainfuck?
Even more supporting my conclusion then. I/O-bound tasks can be written in whatever. You don’t need Rust for that; Rust is for when you need every last bit of performance and minimal memory pressure.
OrontaMedu
Nobody cares. But that’s not the reason of the utility being written in Rust, for it – the external utility in Rust – itself depends on yet other libraries which do exist in Rust and don’t in Elixir. Or at least in Elixir some of them aren’t mature, up to date and maintaned.