Two backend microservices that could talk over regular OS IPC, or eventually something like gRPC, while making DevOps life easy, instead it became "how many languages can we place into a single executable" kind of exercise.

one restriction on the OS side that comes from Erlang and thus by extension Elixir(from the erlang FAQ: "9.12 Why can't I open devices (e.g. a serial port) like normal files? Short answer: because the erlang runtime system was not designed to do that. The Erlang runtime system's internal file access system, efile, must avoid blocking, otherwise the whole Erlang system will block. This is not a good thing in a soft real-time system. When accessing regular files, it's generally a reasonable assumption that operations will not block. Devices, on the other hand, are quite likely to block. Some devices, such as serial ports, may block indefinitely. There are several possible ways to solve this. The Erlang runtime system could be altered, or an external port program could be used to access the device. Two mailing list discussions about the topic can be found here and here."

UNIX IPC is not files based, this is exactly one scenario where "everything is a file" fails, so I don't quite follow.

Try googling for the solution you would have used here and report back ;)

In the article it’s pretty clear that they do put the go code in a separate executable and it connects over the BEAMs existing node RPC.

Indeed, they did.

Now can you explain why a needless C wrapper around Go code, or the BEAM usage around it, in such a kludge contraption, are an improvement over plain OS IPC capabilities, or OS agnostic IPC like gRPC?

Author here. I know all about POSIX IPC (nearly 30 years UNIX admin here). It's not supported on the BEAM in a sensible way. Not to mention that if it were implemented, it would almost certainly violate the sensible failure domain management of the Erlang/BEAM ecosystem and OTP.

As for GRPC: we don't use it anywhere else. So we'd have needed all of the tooling on two stacks, calling patterns without native error handling that we'd have had to implement, and instead we have a thin wrapper that allows the Elixir app to call Go like native Elixir code. GRPC would have been worse in almost every way.

My experience is, people don't know jack about OS IPC.

Unfortunately.

Author here. Nearly 30 years as a UNIX sysadmin. Yes, I know about POSIX ipc. It's not well supported on the BEAM, and anyway would violate most of what makes Erlang/Elixir apps so robust. Not really an option worth even considering.

for the app I don't even think they need all that chicanery. but i'm not an architecture astronaut.