3 ms·
Until someone re-implements the process isolation and other battle-hardened distributed systems characteristics of BEAM/OTP in a rust stack, it certainly seems
by gfodor 8y ago
Until someone re-implements the process isolation and other battle-hardened distributed systems characteristics of BEAM/OTP in a rust stack, it certainly seems like embedding Rust as NIFs into erlang/elixir seems like a nice option to make up for the perf deficiencies you mention (though doesn't cover the memory concerns.)
I have not tried doing it, but I'd imagine the safety guarantees of Rust are a nice thing to have to reduce the risks involved around NIF callouts. I believe Discord recently posted that they are doing this, and I'm interested in hearing about their results.
edit: Google is my friend. https://github.com/hansihe/rustler https://github.com/hansihe/rustler
- ilovecaching 8y agoI think they're being reimplemented in Kubernetes. Kubernetes provides scale-ability, fault tolerance, and the pieces you need to build robust distributed systems. There's no need for this from the language itself. It's actually disadvantageous to mix Erlang and Kubernetes, because Erlang really wants a stable set of node names. It's not a good fit for the way in which we're doing fault tolerance in the cloud. Erlang focuses on not crashing the BEAM, by letting processes crash while allowing graceful degradation of service. Supervisors are akin to Kubernetes deployments. Processes are pods. The pods themselves should be designed to crash gracefully.
- arianvanp 8y agoBEAM on Kubernetes is certainly possible: https://github.com/bitwalker/libcluster https://github.com/bitwalker/libcluster just not by default
- qohen 8y agoIn case it's of interest, Sonny Scroggin gave a talk last March at Code BEAM SF (i.e. the rebranded Erlang Factory) on writing NIFs in Rust, if you're interested: https://www.youtube.com/watch?v=F86JXaCPowo https://www.youtube.com/watch?v=F86JXaCPowo (Sonny is a core team-member of the Phoenix framework).