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)?
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(...) ?
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.
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.
If this were me I’d evaluate the robustness of the client libraries. Is the rust version more feature complete? Would you be the one rolling the elixir version from scratch?
One recent run in I had with this was parsing mp3 id3 tags. There are a few Elixir libraries and one that marshalls to Rust. The rust version takes more to compile and requires some extra hoops but the underlying library is more feature complete than a few of the Elixir versions. I mostly want to grab something and go, especially at the prototype phase I was in. I never strive for dependency-free applications, I have to be reeeallly convinced to roll my own anything. That’s usually a last resort.
If either library saw feature parity and very active code bases I’d choose always Elixir. I’ll generally have an easier experience based on everyone else’s recommendations.
Well in that case it seems you have your answer – if the Elixir library is not up to the task then go with the Rust NIF or external tool. My answer was with the context of “if you have a choice”. If you don’t have the choice then it’s a different game entirely.
Though I’m not sure what was “nobody cares” addresses at.
Would you care to share what are those libraries that don’t have -mature- implementation in elixir but do in rust.
According to your posts, the workload is not cpu bound. If correct, then use elixir, it’ll be easier.
Much have been said about you should stick with a pure Elixir approach, then only move on to Rust NIF when there is significant benefit in doing so. I want to point out the CGI style System.cmd interface is most likely not what you want, should you decide that neither pure Elixir nor Rust NIF is good enough for you.
If you must use an external process, then the only valid reason is that you need to keep significant state in that external process. The best way to communicate with a stateful external process is via a port. Rust offers an excellent async library, Tokio, to make that happen. You would need to write a couple hundred lines of Rust code to wrap the Rust library though.
