> It's what home routers and similar devices ought to be running instead of Linux.
It's what professional routers do run. Well, some of them at least.
We used QNX at my last company, which made high-capacity IPSec gateways. We had control-plane boards and data-plane boards, with inter-board redundancy, which meant that if there was a failure on one of the boards, a standby was ready and functional within seconds.
Part of this was thanks to QNX's QNet, which made IPC transparent over the internal IP network of the system. You could launch and control processes on any other CPU running QNX+QNet, a "node" in the sytem.
It was very cool, and I miss it a bit. I certainly loved being able to kill and restart drivers, which were of course user-processes (QNX is a microkernel OS). Since I was doing driver development work, that was useful ;)
Having a proper (intra-application) messaging system makes a certain class of problems -- problems that you just get used to in Java, and Go, and Rust, and C/C++, and whatever -- just go away.
>Having a proper (intra-application) messaging system makes a certain class of problems -- problems that you just get used to in Java, and Go, and Rust, and C/C++, and whatever -- just go away.
While I haven't used Erlang, I have used other systems with nice messaging systems (PX4 autopilot and ROS) so I will try:
1) Data is passed between threads/processes using a message bus (essentially, a queue). This means, no need to synchronize data access, as every subscriber gets it's own message copy.
2) Suddenly, you need access to certain data from another module. If the program was architected as regular class hierarchy, you would somehow need to pass the reference to that required class instance or use a global function call. If there is a message bus where the required class is already publishing messages, you can simply subscribe to data from the required module and it is delivered via message bus.
3) You can replace modules easily. The only interface to other modules is via message bus, so you can replace the module with one that publishes the same type of messages.
4) If the message bus is designed correctly, you can move the modules/process to different machines, and they can access the message bus over network. Bus broker just sends the messages over TCP instead and that is totally transparent for both involved nodes.
I built something very close to this but it's closed source and very unlikely to ever be released as open source. But it's doable. About 4 man-years of work.
I don't have much experience in the field. Are you searching for something like Apache Kafka?
On the web page it states that Apache Kafka is a distributed streaming platform.
Kafka has four core APIs:
The Producer API allows an application to publish a stream of records to one or more Kafka topics.
The Consumer API allows an application to subscribe to one or more topics and process the stream of records produced to them.
The Streams API allows an application to act as a stream processor, consuming an input stream from one or more topics and producing an output stream to one or more output topics, effectively transforming the input streams to output streams.
The Connector API allows building and running reusable producers or consumers that connect Kafka topics to existing applications or data systems. For example, a connector to a relational database might capture every change to a table.
The problem with projects like Kafka is that they are geared towards cluster scenarios on beefy machine and cannot be embedded in other projects and used as a message bus.
An example for which Kafka is not a good fit: embedded system which reads a few sensors and does a bit of image processing. Such a system should really be compiled to one or multiple native binaries and does not really need JRE.
Wow, I forgot that even existed. Here I was thinking of every switch, firewall, and routing product they've done except this line. I guess it doesn't help that I've never had a reason to touch one as every carrier grade router I've used has been Juniper. I wonder why they went with a whole new platform based on QNX when you don't benefit from a realtime OS if all the packets are moved in hardware? Must be something about the pain of upgrades and reloads on other Cisco product lines and somehow QNX can minimize these outage windows.
I've still yet to meet someone who actually prefers Cisco over Juniper MX. I wonder who is buying these?
It's a highly-reliable, ultra-responsive, self-healing OS w/ plenty of middleware and supported architectures. Also easy to develop on. It's already 90% to their goal for their OS and software. Why not use what already works? If it makes them enough money, they could try to develop something similar in-house.
It's what professional routers do run. Well, some of them at least.
We used QNX at my last company, which made high-capacity IPSec gateways. We had control-plane boards and data-plane boards, with inter-board redundancy, which meant that if there was a failure on one of the boards, a standby was ready and functional within seconds.
Part of this was thanks to QNX's QNet, which made IPC transparent over the internal IP network of the system. You could launch and control processes on any other CPU running QNX+QNet, a "node" in the sytem.
It was very cool, and I miss it a bit. I certainly loved being able to kill and restart drivers, which were of course user-processes (QNX is a microkernel OS). Since I was doing driver development work, that was useful ;)