[hinkley]

I’ve heard that errors in native code called via FFI in BEAM code is the primary place where the runtime can behave uncharacteristically. I haven’t seen anyone in the community describe it this way but it has the feel of undefined behavior to it.

There’s apparently some heightened interest in Rust for these purposes because its guarantees offer some additional robustness here.

But having JIT for the BEAM changes the calculus of whether it’s worth maintaining your code in two languages for a speed improvement that comes with additional liabilities. It will be interesting to see what libraries and tools become pure as the JIT covers more territory.

[toast0]

When you call into native code, you're explicitly opening the door to letting whatever happen happen. It's not undefined, it's a clearly defined escape hatch to do whatever. There's rules to follow, but it's the honor system, BEAM doesn't care if you do or not, but you'll have to live with the decisions you make.

[pjmlp]

Calling into native is by definition the "unsafe" code block of managed languages, even if you are calling into Rust, unless you explicitly validated the code of the dependency being loaded.

There are zero guarantees that the Rust code is correct (free of logical errors), or makes use of unsafe in ways that are properly correct, and given cargo, you also need to validate every dependency that is brought into the shared library.

The only guarantees are that it will abort/panic on bounds checking, numeric overflows and whatever unsafe code it has (regardless of its correctness), is explicitly marked in unsafe code blocks.

[rozap]

It's super exciting, but the JIT in its current form doesn't offer the kind of speedup that something like FFI into Rust or C provides. Also there are lots of great libraries in the Rust/C ecosystems that sometimes you need. Fortunately FFI is not hard, and with the relatively recent addition of dirty schedulers and with the Rustler library, it doesn't block the schedulers and it is safe, which were the two biggest issues.

[imtringued]

There are two problems. Firstly, you don't want a crash in C code to take down your reliable Erlang VM. Secondly, external code has to play nice with the reduction counter and Rust doesn't offer benefits over other languages in this regard.