TL;DR. Why programming business apps is all about messaging.
I have been programming since the early days of Delphi. The event-driven nature of building Windows apps is rather intuitive and Delphi makes it easy and very usable.
Except that it is about developing Windows, and not open source.
In a world of information explosion where attention is fleeting, open source is the only way to do software and application development. The barrier to entry is next to nothing. Knowledge is commodity but action is not.
In the world of free software (open source is just another name for the same thing), the notion of keeping knowledge to yourself (or one entity) is rather outdated. If you cling to that notion, you don’t even have the slightest clue if your idea will take off.
Therefore, it is better to open source your idea, project or anything you deemed worth publishing.
Then and only then will you know if the market will gravitate around your idea.
This is how I become fascinated with messaging-based architecture like those being espoused by NSQ, Project Iris and Scalable Protocols. I have been familiar with event-driven programming (like Delphi and Node.js) but to paraphrase Alan Kay, the essence of OOP is messaging.
Which leads me to remind you that this is not about OOP or the demerits of class-based OOP.
This is all about messaging and in particular, using messaging-based software written in Go.
It is compiled, and better than C, Delphi or any other compiled programming languages. You deploy with just a binary. It is even cross-platform.
The days of selling software is over!
What’s not to love?
Since Go was released, the market is awash with not just good software but *awesome* software.
Suddenly, the marketplace has access to a really good foundation for building system software.
Since Go was released in 2009, we are entering the Golden Age in software production.
That is, we are entering an age where experts build software and developers build applications.
This is a very important distinction.
Not everyone can be experts but the average Joe can be a potential developer.
This is not about disparaging the average developer. If you are still looking for a full-stack developer, you won’t find them on planet Earth because there is no such kind of person.
If you are a developer, you are either a front-end or back-end developer.
A full-stack developer is a unicorn.
Which brings us to back-end development.
Since the release of NSQ, NATS, Docker and others, we delegate complexity to experts.
As a developer, your task is to develop business applications, not system software.
Leave complexity to the experts.
There is a reason why you don’t need to have a PhD on one area of computing because computing as an industry is broad just like in medicine.
You have to specialize on one and only one domain because that domain is broad enough to pre-occupy your lifetime!
To illustrate, consider operations.
If you still live in the old school of thought regarding clustering, you still wrangle with IP addresses or instance-based clustering.
Well, that was in the 20th century.
In the 21st century, you use name-based clustering (in particular DHT-based clusters).
Because it is easier and you leave complexity to the experts (or rather to the system).
In this century, you tackle complexity if you’re an expert (or has the requisite PhD or substantial experience). It’s not enough to be an expert. You also need to have usability chops so mere mortals may use your software in an intuitive fashion.
If you’re an application developer, you just need to know the interface. The system software is a black box. You don’t need to know the internals (unless you’re an expert).
In the 21st century, developing business applications is just one use case of messaging.