Hacker News Reader

Comment by nullwarp | Hacker News Reader

Go really is great. There was a big argument around a new project we were starting whether to do Go or Clojure.

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.

View on HN

As a method for choosing a language, doesn't this just inherently skew to the smaller and more simplistic one, which may not necessarily be the best for all tasks or over a longer run where the techniques of the more involved language could be learned?

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.

I would say it skews towards languages that are easy to be immediately productive in, which is certainly one of Go's biggest strengths.

Potentially. Devs might get up and running with Scratch even faster than Go. But I'm assuming the OP already determined that Go or Clojure would work well for the task.

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.

> As a method for choosing a language, doesn't this just inherently skew to the smaller and more simplistic one, which may not necessarily be the best for all tasks or over a longer run where the techniques of the more involved language could be learned?

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.

It skews towards languages that the developer is familiar with.

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 is basically C with training wheels, THAT CAN NEVER BE REMOVED.

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.

If those people who 'actually write code' wouldn't have sprinkled their code with race conditions and buffer overflows maybe C would still be used widely for business apps, but reality is C code, while highly efficient, carries more risks than languages with training wheels. It's not contempt, it's coping with a reality where you can't afford to disqualify half of the programmer population because they're 'too junior' while there is an extreme shortage of workers. There's even a shortage of programmers for languages _with_ training wheels here...

It's a language for white-collar sweatshops ... more so than Java ever was.

Ultimately this is a disservice to those with any talent as it leads to a work environment where they are relegated forever to the lower ranks (unless they give up coding and move into management).

I don't believe it's got anything to do with talent. The wiser programmers I know don't get emotional about 'training wheels' but try to prevent errors by systematically and automatically fixing weak spots. It's not about contempt but about making sure after you make a mistake nobody ever makes that same mistake again... Footguns are a waste of time regardless of how good you are at avoiding them.

It feels to me more like giving them the choice of two excavators one with many more options that are unnecessary and one with simple easy to grok basic controls

This seems good, except that it would always push for the languages that produce now and leave bugs for production.

Python would beat anything by this measure, but static typing is amazing for stopping bugs.

Your "entry level" dev finished a non-trivial Go app in about an hour without knowing anything about Go? Literally how?

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?

A data dip via a single http endpoint is very easy to implement in go. Like 6-8 lines of code easy, with tons of examples available online

That's such a interesting experiment, but I can't help but think that whichever language's project was tackled first was playing at a serious disadvantage, even if the projects were somewhat different...

I definitely agree that learning curve is important and Go is decent IMO but that still seems like a crazy way to choose a language. You don't hire a dev for one day and then fire them.

It would be like deciding to dig the channel tunnel with a spade because TBMs are quite complicated to set up.

I mean if you have ever written a for loop before you know enough go to get started. I like go fine but this seems like a very short sighted thing to optimize for.

golang and Clojure are not in the same space, so it doesn't make sense to compare them. And I question this litmus test of using a junior dev anyway.

> And I question this litmus test of using a junior dev anyway.

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.

Junior as in non-expert in the field. Using simplistic languages means optimizing for quickly pumping out code (at the expense of maintainability in the case of golang, as I've personally experienced at an employer that has one of the largest golang setups on the planet). Not to mention that golang comes with its own set of gotcha's and idiosyncrasies that need to be understood, especially in more involved programs.

There's a good middle ground that can and has been achieved by other languages.

What does this actually mean? They are both programming languages made for solving general problems, what makes the comparison inappropriate? I've used both and pretty much all of their cousins, so I'm confused why you would think they aren't comparable.

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.

Reply on news.ycombinator.com