@dale good point about safety-critical systems – the systems I’ve worked on thus far do not fall into this category (irrigation, waste water monitoring, etc).
A big reason I went down the NATS path (over MQTT) is because it is written in Go, and thus integrates more easily with all the other pieces I’ve written. One of my goals with SimpleIoT is that it be easy to deploy (one binary for small systems). I don’t want separate database servers, messaging servers, etc. An embedded database like sqlite or bbolt can easily handle a moderate size system. A single server can easily service 1000’s of devices. For systems that can tolerate a few hours of outage, the time to rebuild a failed server is acceptable in the rare instances a cloud server actually does fail (it has never happened to me yet).
For larger “enterprise” projects with a team of people, operations is not a big deal, but as I maintain several IoT systems for small customers, I’m always looking for ways to simplify operations. Not having to stand up and monitor 4 services is a big savings. Likewise, configuring and integrating the various cloud IoT offerings (AWS, Azure, etc) likewise is non-trivial.
A lot of cloud development has moved to Go in recent years for various reasons. The more I work with Go (both development and operations), the less interesting C++ and Java are to me. Go has a culture of simplicity that is refreshing. (example: try configuring NGINX vs Caddyserver). So for me, the protocol itself is a consideration, but also the big picture.
Having a MQTT server implementation in Go (as part of NATS) is super interesting to me as well. I would like to eventually support the MQTT protocol once that happens and perhaps switch to that if it makes sense for device communication. But, NATS is working just fine for now.