Live data from Hacker News

Elixir and Rust is a good mix

fly.io

1–10 of 165 posts

Re: Elixir and Rust is a good mix

#4
I used this in past, but there were a lot of people saying that NIFs/ports are dangerous to use. Did any of this change or are there tried and tested practices that can be applied? What I used this for wasn't critical app so I didn't mind it going down.

IIRC one threat was Rust sharing memory with BEAM which could exhaust it and cause OOM crash?

Re: Elixir and Rust is a good mix

#6

I used this in past, but there were a lot of people saying that NIFs/ports are dangerous to use. Did any of this change or are there tried and tested practices that can be applied? What I used this for wasn't critical app so I didn't mind it going down. IIRC one threat was Rust sharing memory with BEAM which could exhaust it and cause OOM crash?

Nif's are always a risk to deploy cause they run embedded in the Beam runtime. That said we all use many nif's to do all kinds of stuff and its fine.

I go into this in the article a little but but the ruslter team has made dirtycpu and dirtyio macro's to help reduce the risks.

Re: Elixir and Rust is a good mix

#7
I used to use Elixir, but the lack of static types got to me (especially since I prefer the type-driven development methodology). Using Rust afterwards was great, plus it was faster than the BEAM. I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend language? I've been using Axum and it works pretty well. The only time I had to do FFI with Rust was with Flutter via flutter_rust_bridge, for running a CRDT library (automerge) that was implemented in Rust, for offline app functionality.

Re: Elixir and Rust is a good mix

#8

I used this in past, but there were a lot of people saying that NIFs/ports are dangerous to use. Did any of this change or are there tried and tested practices that can be applied? What I used this for wasn't critical app so I didn't mind it going down. IIRC one threat was Rust sharing memory with BEAM which could exhaust it and cause OOM crash?

I wouldn't use the word dangerous. NIFs and (linked in) ports are a risk, yes. You're loading native code, and you don't have intrinsic protection against it doing naughty things that alter the underlying shared state in unapproved ways. Things like writing to improper addresses, closing improper filehandles, opening filehandles and leaking them, leaking memory, other improper use of syscalls, or just running for too long.

The only proper solution is to audit and understand the code you're running, but hoping it's fine often works too; maybe formal methods, but to a first approximation, nobody uses those. Did you audit all of ERTS and/or OTP? I'm guessing probably not, but it's there to review if you run into a problem.

IMHO, it's not worrying about if BEAM will crash; worry about it not crashing instead. If your Rust NIF ties up a scheduler with an infinite loop, that has the potentially to lock up the whole BEAM once another scheduler needs to do something that requires full cross scheduler coordination.

BEAM can certainly crash on OOM; although I recommend setting a ulimit to ensure it will, because when it crashes, you can recover. I've also run into situations where instead of crashing or being killed by the OS OOM killer (which is close enough to crashing), the OS gets into some tricky to debug state where your application is neither functioning nor killed. Sometimes, you even get into a state where BEAM is making progress, but very slowly; that's a fate worse than death.

If you follow the Erlang philosophy, you'll have a recovery strategy from crashes or other deaths. Heart can be used to turn completely blocked into death, although I never used it professionally. But you've still got to worry about working but not well.

Re: Elixir and Rust is a good mix

#9

I used to use Elixir, but the lack of static types got to me (especially since I prefer the type-driven development methodology). Using Rust afterwards was great, plus it was faster than the BEAM. I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend language? I've been using Axum and it works pretty well. The only time I had to do FFI with Rust was with Flutter via flutter_rust_bridge,…

Everyone have different needs. For us, OTP on top of pre-emptive lightweight threads and a REPL in production is a huge winner for troubleshooting, finding performance bottlenecks, and reliability.

Re: Elixir and Rust is a good mix

#10

I used to use Elixir, but the lack of static types got to me (especially since I prefer the type-driven development methodology). Using Rust afterwards was great, plus it was faster than the BEAM. I guess, why not use Rust entirely instead of as a FFI into Elixir or other backend language? I've been using Axum and it works pretty well. The only time I had to do FFI with Rust was with Flutter via flutter_rust_bridge,…

> why not use Rust entirely instead of as a FFI into Elixir

Because many times you value fault-tolerance and distribution more than performance.

Post reply on HN