I am designing an app to manage RabbitMQ workers given certain rules. For example:
I originally thought of writing it in Go because it is compiled & I could simply compile the app to the target OS & daemonize it. However, my concept design involves having a loop that gathers data every Y seconds & passes it through a decision engine. The engine would then raise events that would be listened to by other goroutines to either spawn or kill workers.
I've found the Emission library which would acommodate this, but I read a comment somewhere that it might not be thread safe. Honestly, my knowledge of Go & threaded programming are not sufficient to properly evaluate if this library would accomplish what I need or if this is even possible in Go.
I could write this very quickly in NodeJS and even get it compiled using nexe. However, I wanted to learn a new language, I liked the targeted compilation in Go, and that it can be multi-threaded beyond the goroutines themselves.
Is this possible or am I trying to shoehorn something into Go that it wasn't designed to do? Would it be better to accomplish the same goals differently or to just use a different language all together?
I had not seen Emission library before which could work very neatly to send different messages to your workers. This could also be achieved by using channels which would be a more flexible implementation but also more cumbersome if you do not know the language.
I would certainly read on channels but be very careful as broadcasting through channels is not straightforward. Take a look at this example (https://rogpeppe.wordpress.com/2009/12/01/concurrent-idioms-1-broadcasting-values-in-go-with-linked-channels/)
Overall I would take a look at Tunny (https://github.com/Jeffail/tunny) to manage workers it already has most of the implementation done for you.
Go is a very good language for i/o intensive apps, particularly if they involve messaging. However, your use case appears to concern managing RabbitMQ rather than messaging. For this purpose, Go has rather less that makes it stand out in its favour.
You might want to stand back and consider the system as a whole. How much of it needs to use RabbitMQ? If that is an open question, you might find that the lightweight goroutines and channels are a useful tool. Just maybe, you can implement parts of your system that use MQ directly in a Go program. But if you try this, remember that the fundamental CSP model is of synchronous / blocking message passing, quite different from the MQ model. Buffering, queueing, asynchronous operations etc are layered on top of this primitive behaviour.
If your intention really is just managing RabbitMQ, maybe take a look at the rabbitmq-http project to help you make up your mind.