[jerf]

The ideal situation for this sort of code is to basically treat it as marshalling code, which is often ugly by its nature, and have the "payload" processing be significantly larger than this, so it gets lost as just a bit of "cost of doing business" but is not the bulk of the code base.

Writing safe NIFs has a certain intrinsic amount of complication. Farming off some intensive work to what is actually a Go node (or any other kind of node, this isn't specific to Go) is somewhat safer, and while there is the caveat of getting the data into your non-BEAM process up front, once the data is there you're quite free.

Then again, I think the better answer is just to make some sort of normal server call rather than trying to wrap the service code into the BEAM cluster. There's not actually a lot of compelling reasons to be "in" the cluster like that. If anything it's the wrong direction, you want to reduce your dependency on the BEAM cluster as your message bus.

(Non-BEAM nodes have no need to copy using tail recursion to process the next state. That's a detail of BEAM, not an absolute requirement. Pattern matching out of the mailbox is a requirement... a degenerate network service that is pure request/response might be able to coincidentally ignore it but it would be necessary in general.)

[pdimitar]

In my 8.5 years of Elixir practice I found it much easier to just use a Rust NIF or, in extreme cases, publish to an external job queue. Had success with one of Golang's popular ones (River); you schedule stuff for its workers to do their thing and they publish results to Kafka. Was slightly involved but IMO much easier than trying to coax Golang / Java / C++ / Rust nodes join a BEAM cluster. Though I am also negatively biased against horizontal scaling (distribution / clusters) so there's also that.