What we did to settle the debate was to ask an entry level dev that was just starting if he was interesting in writing two sample applications in each language, having known nothing of either. Nothing complicated but touched enough points (HTTP endpoints, database interaction)
A full day later was still trying to get the Clojure app working correctly.
He finished up the Go one in like an hour.
Since then we've brought new devs on with zero Go experience and they are up writing good code in a day. I can't imagine where we would be if we had gone down the Clojure route.
It's like hiring a new farmhand and saying, "here, dig two 3 foot holes, and we'll see what takes you longer, this shovel or an excavator you have no training or experience with," and then concluding the shovel is superior for all digging tasks from that point on.
pmuch.
I migrated a team off of an aging enterprise application to the product that was rapidly gaining popularity in industry. I had some expertise and believed in it, I won't name products (and it wouldn't mean anything to HN anyway) but this was a painfully obvious change. We were the pilot project at the company, and went though 6 months of most users struggling. It was about 18 months after adoption that my boss told me he felt like the new product was both better and that the slow down had been worth it.
Life isn't long enough for too many of those experiments. Not everything takes that long. And the experiment could have failed. But the experience really put lots of decisions into perspective.
There's a saying that nobody uses technologies that their boss didn't learn in college. Factually inaccurate, quite astute in message.
Kotlin, for example, is a decent bit more complex than java is. It has a lot of new concepts to learn.
Yet, most Java devs can be productive with kotlin in a day or two. Even with the added concepts, it's not that different of a language.
The same is true of C and C++. A C dev could jump into C++ pretty quickly (even if they are just writing C with classes to start).
Your analogy is more like "Dig a hole, here's a shovel and here's a post hole digger". The familiar tool will likely go faster than the unfamiliar tool. And, as it happens, most devs are highly familiar with imperative programming styles, not so much functional programming paradigms.
Go probably has a leg up on Clojure for reputation in production projects, considering Docker, K8s, Terraform, InfluxDB, and Geth are all written in Go. The biggest ones I can find written in Clojure are Puppet and CircleCI.
It accelerates junior devs to production ready at the expense of everyone else.
It really feels like a language designed by people with utter contempt for those who actually write code.
Python would beat anything by this measure, but static typing is amazing for stopping bugs.
Also he learned enough Clojure to mess around in, again with 0 knowledge about it. Again impressive. Or is this industry standard competency in some fields?
It would be like deciding to dig the channel tunnel with a spade because TBMs are quite complicated to set up.
As you churn employees, anyone new will inevitably be "junior"[1] when it comes to your code base - Go is (mostly)[2] ridiculously easy to read because you can't (easily) do things[3] that make reading - and more importantly, maintaining - it hard.
[1] Sometimes literally a junior too.
[2] There's a few things I think might trip up someone brand new to Go.
[3] Looking at you, Perl and Ruby.
There's a good middle ground that can and has been achieved by other languages.
The "test" itself I agree is a bit shortsighted. I think Go might be a fine choice over time anyway, but the experiment itself doesn't necessarily highlight the things I'd want to highlight for medium- to long-term viability.
