5 ms·

With all this effort required (as the author points out), I start to wonder if a better solution is to communicate via RPC over local sockets. There will be so

With all this effort required (as the author points out), I start to wonder if a better solution is to communicate via RPC over local sockets. There will be some overhead, but it might be a wash considering calling over a FFI often involves similar overhead to marshall / unmarshall objects. And the simplicity gains would be massive.

layer8 2y ago
Why over a socket? You could perform the same protocol more efficiently with normal functions in-process. Maybe we need a standard serializing LPC protocol just using the platform ABI. Or maybe this comes down to something like ZeroMQ in-process.
- marklar423 2y ago
  Mostly because sockets are supported by everything today, and they're easy to understand. What you're describing would certainly work but it looks similar to what the OP did in the blog post, with all the complexity it comes with.
  - layer8 2y ago
    The OP doesn’t serialize. My proposal would still serialize as with RPC, but instead of passing the data over a socket, just pass the data as a binary blob over a regular function call.
    - spongebobstoes 2y ago
      The main thing on my mind is that the build system would become more bespoke when doing it that way, compared to running a few processes that interact with each other. The overhead of socket read+write is typically much less than the serialization overhead, although both can be optimized to the point of irrelevance for many applications. It's also interesting because it ends up looking like a microservices architecture, except all on one machine (even all in one process tree).
- marklar423 2y ago
  https://zeromq.org/ https://zeromq.org/ -> TIL really cool, thanks for the pointer.
masfuerte 2y ago
COM [1] was a solution to these problems thirty years ago. In-process it's just function calls. Cross-process COM has automatic marshalling for standard types ("automation types") or you can define custom marshalling that does whatever you want. WinRT [2] is a more modern version. It builds on COM and (among other things) provides the basis for the latest UI frameworks in Windows. [1]: https://en.wikipedia.org/wiki/Component_Object_Model https://en.wikipedia.org/wiki/Component_Object_Model [2]: https://en.wikipedia.org/wiki/Windows_Runtime https://en.wikipedia.org/wiki/Windows_Runtime
- nsguy 2y ago
  A long time ago I worked on a project where we needed to distribute an in process COM object, so we moved it to DCOM, instantiated multiple instances, and that worked! All in all COM was a fairly pleasant technology. Not really that different than gRPC (e.g. idl vs. proto).

layer8 2y ago

Why over a socket? You could perform the same protocol more efficiently with normal functions in-process. Maybe we need a standard serializing LPC protocol just using the platform ABI. Or maybe this comes down to something like ZeroMQ in-process.

marklar423 2y ago
Mostly because sockets are supported by everything today, and they're easy to understand. What you're describing would certainly work but it looks similar to what the OP did in the blog post, with all the complexity it comes with.
- layer8 2y ago
  The OP doesn’t serialize. My proposal would still serialize as with RPC, but instead of passing the data over a socket, just pass the data as a binary blob over a regular function call.
  - spongebobstoes 2y ago
    The main thing on my mind is that the build system would become more bespoke when doing it that way, compared to running a few processes that interact with each other. The overhead of socket read+write is typically much less than the serialization overhead, although both can be optimized to the point of irrelevance for many applications. It's also interesting because it ends up looking like a microservices architecture, except all on one machine (even all in one process tree).
marklar423 2y ago
https://zeromq.org/ https://zeromq.org/ -> TIL really cool, thanks for the pointer.

masfuerte 2y ago

COM [1] was a solution to these problems thirty years ago. In-process it's just function calls. Cross-process COM has automatic marshalling for standard types ("automation types") or you can define custom marshalling that does whatever you want. WinRT [2] is a more modern version. It builds on COM and (among other things) provides the basis for the latest UI frameworks in Windows. [1]: https://en.wikipedia.org/wiki/Component_Object_Model https://en.wikipedia.org/wiki/Component_Object_Model [2]: https://en.wikipedia.org/wiki/Windows_Runtime https://en.wikipedia.org/wiki/Windows_Runtime

nsguy 2y ago
A long time ago I worked on a project where we needed to distribute an in process COM object, so we moved it to DCOM, instantiated multiple instances, and that worked! All in all COM was a fairly pleasant technology. Not really that different than gRPC (e.g. idl vs. proto).