[petre]

> nearly always find a module that would accomplish a specific task I needed

Then you didn't have to write PC/SC smartcard code in Perl. Also most of the MQTT clients are crap, only Net::MQTT::Message is useful but then you have to write the network client yourself and if you also need TLS, good luck, the modules doing that have like 200+ failed tests. CPAN is great but if you need anything out of the ordinary you'll probably find modules in a state of disrepair, abandoned in 2010.

[HankB99]

That's unfortunate but I suppose a consequence of a less active ecosystem. I don't recall dealing with that back in the day but it doesn't surprise me now, particularly with more recent technologies like MQTT.

I have written MQTT clients in Python and the module support was good. But then I discovered it was easier (for the most part) to use the Mosquitto cli utilities and pipe stuff to/from them. For cases where that was awkward, it was easy enough to write in C and use the PAHO libraries directly.

[petre]

Yes, Python, Ruby and JavaScript have better MQTT libraries. I managed to write an async Perl client using POE (the networking code was already heavily using it, otherwise I wouldn't even pick POE since it's awful and also dead) and Net::MQTT::Message. Piping output into mosquitto_pub/sub was out of the question, since this was no hack but rather a service that streams data into the broker.

I suspect writing it in Ruby with async would also prove problematic, but there are the ruby-mqtt and async-io gems and one would use the MQTT::Packet for formatting messages and Async::IO for the networking code. Still a lot less painful than what I did with POE and Net::MQTT::Message.

MQTT.js is async already, you just import and use it in the browser, Node.js, probably Deno as well. Easy. It took literally five minutes to get the client enpoint working in the browser over WebSockets. One could even do it from the browser console.