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.

Second, there is object-oriented programming. We have seen that the class-based OOP experiment is a failure. Prototype-based OOP (like JavaScript and Lua) and interface-based OOP (like Go) are better at effectively modeling reality.

Third, there is functional programming which is basically about higher-order functions (again, JavaScript and Go comes to mind).

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).

And lastly, there is message-passing paradigm. But I do not want to use Erlang. And JavaScript is hobbled by its single-thread model. So for this project, let’s just say I want the Go community to fully realize the potential of messaging-based architecture.

courtesy of DZone

In particular, I want to address the following:

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.

Locality is already present with Project Iris and NSQ. Two other Go packages namely mangos and EventBus deal with interprocess and intraprocess respectively so they are inherently local.

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.

Like what you read? Give IT MARKETPLACE a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.