Take your mind back to around 2005-2006. The world was very simple: the “enterprise” used a Java stack or a Windows stack, and the rest of the world used … whatever. Mostly, the non-enterprise world was Perl, Python or PHP, with a smattering of weird stuff here and there.
Ruby hit it big with Rails around 2006, and you could not read a single tech blog or news aggregator with references to Rails or `gem install`. Everyone was cranking out code into the green-field Ruby ecosystem. The masses of tech punditry wrote terabytes of text about how Rails was going to infiltrate the enterprise soon, and how in-demand Ruby and especially Rails programmers (now called “ninjas” and “rockstars”) were.
It never happened, of course. Rails remains a popular and excellent choice for a wide array of applications on the web, but its largest users (eg, Twitter) have since abandoned it. They did so for many reasons: some good, like performance, and some not-so-good, like …
Well everyone dropped their in-progress Rails app like a hot rock and picked up node, especially after the 2011 release of npm. Here was a brand-new green-field package-manager ecosystem for early adopters to stake a name and a claim.
It never happened, of course. Node.js remains a popular and excellent choice for a wide array of applications on the web, but its largest users (eg, TJ Holowaychuk) have since abandoned it. They did so for many reasons: some good, like performance, and some not-so-good, like …
In 2009 a bunch of programmers at Google decided they wanted a better way to write the C/C++ programs that drive the core of Google’s stack. The result was Go …
**And on and on and on**. You can play this stupid game all the way back to ENIAC.
If the language your tech team is pushing is the one on top of the blogs and news aggregators, there’s a non-zero chance they are making the decision in part of not wholly because of perceived pressure to be “current”.
Make no mistake: everyone is guilty of this. Moreover, each of these “foo is better than bar” events **does** move the bar forward in some way. Not that Go is better than Node which is better than Ruby, but each has a chance to address flaws inherent in the design of earlier programs.
That said, I often find what is now often referred to as “Hacker News-driven development” to be far more difficult and dangerous than just doing the hard work of fixing bugs. “But Foo has far greater support for concurrency!” is a great argument if your metrics show concurrency is a problem; it’s sloppy thinking if you have no users and just want a new toy.
Moreover, HN-driven development often results in big blind spots with the platforms you have. A great example is Python. A lot of people went from Python 2.x to Go, citing bugs, performance problems, or a need for greater concurrency, without ever testing out the asyncio stuff in Python, or checking to see if their pet bugs were fixed. Go was a shiny new toy with the intellectual thrill of learning a new thing; porting to Python 3 was just hard, possibly boring work. Who needs *that* shit?
Yes, I think Go is a bad language that ignores decades of programming language research to solve a specific problem Google has. Google’s massive rep as tech innovator makes everyone think it’s good: after all, Google uses it!
But the point of this rant is to not criticize Go, it’s to illustrate that “Go is going to solve all our problems!” is a bunch of bullshit, because the most likely scenario is in 2-3 years the newest, hippest platform (an out-of-left-field Perl resurgence? Elm? INTERCAL?) will suddenly become the solution to all our problems.