undefined | Better HN

0 pointstoast01y ago0 comments

Oh I see. If you need to isolate your native code from your BEAM, then you've got several options.

a) run the native code as a separate process; either a port program, a c-node, or just a regular program that you interact with via some interprocess communication (sockets, pipes, signals, a shared filesystem, shared memory segments if you're brave)

b) some sort of sandybox thing; like compile to wasm and then jit back to (hopefully) safe native.

c) just run the native code, it's probably fine, hopefully. My experience with NIFs is that they are usually very short code that should be easy to review, so this isn't as bad as it sounds...

If your native code is short, option c is probably fine; if your native code is long, option a makes more sense. If you want to make things harder without real justification, b sounds good :P

0 comments

hinkley1y ago

I suspect the confusion of priorities comes from running native code that’s time consuming and wanting it to horizontally scale with your cluster, which is easier if you try to let the beam do it.

While what is easier for those of us not working on the beam is to put the glitchy code into its own service and put up with the maintenance overhead.

But when you have one or two solutions the friction to move to three becomes difficult. People start talking about how having dozens will be chaos. While true, sometimes you really do just need three and it’s not a slippery slope.

toast0OP1y ago

> sometimes you really do just need three

If it's worth doing, it's worth doing three times.

j / k navigate · click thread line to collapse