Go-Based Messaging Project Challenge
This generation of programmers have seen five major programming paradigms since Alan Turing conceptualized the Turing Machine (I know there are a lot more but I am concentrating on at least five).
First, there is imperative programming. State or effects reside in control structures (sequence, loop, decision). Immutable data can be contained in functions. Imperative programming is about consumer pulling data from producer.
Fourth, there is reactive programming which is the opposite of imperative programming. Reactive programming is about producer pushing data to consumer (hat tip to Erik Meijer for this idea).
In particular, I want to address the following:
- Channels are not enough by Alexey Kachayev. To quote Karl Seguin in his “The Little Go Book”
There’s little to say about goroutines other than they’re effective and simple (simple to use anyway). It’s a good abstraction. Channels are more complicated. I always think it’s important to understand basics before using high-level wrappers. I do think learning about concurrent programming without channels is useful. Still, channels are implemented in a way that, to me, doesn’t feel quite like a simple abstraction. They are almost their own fundamental building block. I say this because they change how you write and think about concurrent programming.
- Which leads to my next goal: “Parallelism is more important than concurrency”.
- Which leads to the ultimate goal: “Use message passing, not RPC”.
For beginners, the key characteristic of message passing is locality.
To quote the Actor model,
Locality means that in processing a message, an Actor can send messages only to addresses that it receives in the message, addresses that it already had before it received the message.
My challenge to the Go community is to utilize message-passing paradigm to its fullest because this is the least-known among programming paradigms but has a great potential in dealing with code complexity.
The key here is to minimize control plane and maximize the data plane.
Leave a comment here, post your GitHub project or share your story on how you effectively use NSQ, Project Iris, mangos, EventBus or other Go package related to message passing, message queue, job queue, etc.
This is not necessarily about Actors and STM. This is about how can we remix ideas from other languages and incorporate it to your project (by reducing channels and goroutines into higher level of interface like “Scalability Protocols” for example).
Preferred deliverables are Go binaries so your project must be an executable or a library. However, Docker-based projects are also welcome.
Make your mark. Leave an impact. Want to sponsor this project? Organize an event around this theme? Questions? Just tweet us at @itmarketplc.
Update: Watch for development of Nomad Project. It aims to be the DevOps-friendly version of Kubernetes and Mesos.
Do you want to be a developer, and sustain a fun and meaningful IT Marketplace? Just click HERE.