I believe Q/Kdb+ to have the most natural implementation of IPC that I've seen, as long as you can keep all your gear inside Q.
To connect to another host you just do:
remote:hopen `:server:port;
The port number is specified with -p on the command line. To send messages:
answer:remote "sum x"
or if strings are repulsive to you you can pass in an expression like: answer:remote (`sum;x). `sum here is a symbol which is like a reference to a variable (or function). You can also pass a literal function for the remote host to execute, since they're just data.
You can also do asynchronous calls using the negative value of the handle (which is just a file descriptor int, wildly enough): neg[remote] (`incViews;`welcomepage;1)
Completely natural and simple. The only issue that I'm aware of is a 2gb limit for each message. Built-in functions can split your data into blocks to transmit large amounts.
The in-memory representation of data and the network representation are essentially the same. So there's no costly per-byte packing or unpacking going on, simply a memcpy(). In terms of performance and power use (environmental impact) this is a huge win.
It's trivial to expose data to the outside world by creating a web server. Simply define a function called .z.ph (or .z.pp for POST). This one evaluates the URL requested as a Q expression and returns the result as json.
.z.ph:{.j.j value x 0}
Being able to build services as simply as this allows you to begin to think about the microservice as the unit of program composition, rather than classes, functions, or modules. Microservices have their own issues, but that's a topic for a later rant.
To connect to another host you just do:
The port number is specified with -p on the command line. To send messages: or if strings are repulsive to you you can pass in an expression like: answer:remote (`sum;x). `sum here is a symbol which is like a reference to a variable (or function). You can also pass a literal function for the remote host to execute, since they're just data.You can also do asynchronous calls using the negative value of the handle (which is just a file descriptor int, wildly enough): neg[remote] (`incViews;`welcomepage;1)
Completely natural and simple. The only issue that I'm aware of is a 2gb limit for each message. Built-in functions can split your data into blocks to transmit large amounts.
The in-memory representation of data and the network representation are essentially the same. So there's no costly per-byte packing or unpacking going on, simply a memcpy(). In terms of performance and power use (environmental impact) this is a huge win.
It's trivial to expose data to the outside world by creating a web server. Simply define a function called .z.ph (or .z.pp for POST). This one evaluates the URL requested as a Q expression and returns the result as json.
Being able to build services as simply as this allows you to begin to think about the microservice as the unit of program composition, rather than classes, functions, or modules. Microservices have their own issues, but that's a topic for a later rant.