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.
nesarkvechnep•7mo ago
My experience is, people don't know jack about OS IPC.
pjmlp•7mo ago
Unfortunately.
relistan•7mo ago
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.
dzonga•7mo ago
for the app I don't even think they need all that chicanery. but i'm not an architecture astronaut.
fridder•7mo ago
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."
pjmlp•7mo ago
UNIX IPC is not files based, this is exactly one scenario where "everything is a file" fails, so I don't quite follow.
manchmalscott•7mo ago
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.
pjmlp•7mo ago
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?
relistan•7mo ago
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.
relistan•7mo ago
Try googling for the solution you would have used here and report back ;)
pjmlp•7mo ago
nesarkvechnep•7mo ago
pjmlp•7mo ago
relistan•7mo ago
dzonga•7mo ago
fridder•7mo ago
pjmlp•7mo ago
manchmalscott•7mo ago
pjmlp•7mo ago
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?
relistan•7mo ago
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.
relistan•7mo ago