Hacker News Reader

Comment by chippiewill | Hacker News Reader

Actually I think it's more complicated than that. Pub/sub is a natural fit for robotics in a prototyping sense, but it's a poor fit for real-time systems which makes it harder to productionise something based on ROS. Especially safety critical systems.

"Just" a multi-threaded app and calling functions isn't really a good replacement. For something really basic, sure, but the modularity that ROS introduces, and the core principle of having serialisable recordable messages delivers a lot of value once you start building large systems - particularly those that can span multiple physical machines. But pub-sub is _too_ general as a concurrency model, if ROS had adopted something more constrained that was provably deterministic and was amenable to real time analysis then a lot of its concerns would go away.

View on HN

It would also help to have compile-time guarantees about which nodes are running.

But I always like to say, why spend 5ns calling a function when you could spend 1ms waiting for a context switch or 50ms for the next event loop to tick over? Even modern microcontrollers are blindingly fast, and the majority of the time they spend these days is because of our brain-dead architecture decisions, not due to the underlying problem that actually needs solving.

> It would also help to have compile-time guarantees about which nodes are running.

I haven't had a chance to try it yet, but in theory I like the idea of something like Zenoh Flow to describe the larger data flow graph. https://zenoh.io/blog/2023-02-10-zenoh-flow/

> But I always like to say, why spend 5ns calling a function when you could spend 1ms waiting for a context switch or 50ms for the next event loop to tick over?

I think your context switch timing is off by several orders of magnitude, but regardless these things aren't one extreme or the other. For sharing data across threads, to an external system, or logging and visualization I still like pub/sub (and I've seen more than my share of horrible abuse), but it definitely shouldn't be treated as one size fits all.

In a best case, yes I've exaggerated wildly. But in a latency sensitive system, waiting for the message to get to the front of the queue could really take that time. Different queue priorities help, but really, why not just do a function call? To me, anything that isn't just a function call should really need to be justified. But I guess it's all design decisions.

Reply on news.ycombinator.com