Hacker News Reader

Comment by drsintoma | Hacker News Reader

The real difference IMHO is the very low cognitive load that Go requires. It's a very minimal language very easy to reason about. This translates into 2 things:

1. Most programers (above and below average) can just pick-up Go and be productive without much hand-holding.

2. Most programers can, without much experience, pick anyone's Go code and understand what it's doing.

Working in a company where we introduced Go for backend services without anyone knowing much about it, I know first hand those 2 are true for Go. But I'm not so sure about how OCaml, F#, Haskell or Scala would do with some of my colleagues in that sense.

View on HN

That's an awesome thing about Go, there's nearly no ramp-up time. On Juju, we hire like 65% devs who've never used Go, spend nearly zero time teaching it to them, and they're still instantly productive.

A language to be loved by managers it seems, specially when high attrition and off-shoring are the rules of the game.

So, you enjoy spending months ramping up new developers in your language of choice? That's not a task that falls to managers, it falls to the other developers on the team. There's still ramp up on the codebase, but at least I don't have to ramp people up on the basics of the language itself. That's a huge win.

If you think team productivity only matters to managers, that's kind of sad.

No, because in our projects only developers skilled in the required technologies get hired.

Then you're narrowing your hiring pool. Hiring is hard. Hiring really good people is really hard. Removing the requirement of "has 10 years of $LANGUAGE" is pretty awesome. It means we can hire someone because they're GOOD, not because their last job chose the same language we're using.

I'm willing to spend time ramping up if it means greater productivity in the long run. I can see that go's a kind of lowest-common-denominator language - you don't spend any time learning its fancy error-handling facilities because it doesn't have any - but I don't see that as a win.

You should use Go for a while. It's very productive. Lean and mean and gets out of the way of the developer.

People call it a lowest common demoninator language as a way to dismiss it, but it's actually incredibly well thought out by a lot of really smart people, several of whom have been writing code for longer than most people on HN have been alive.

The error handling works the way it does, because errors are not special. They're just values, and you can use the whole programming language to handle them just as you would any other value that gets returned.

> The error handling works the way it does, because errors are not special. They're just values, and you can use the whole programming language to handle them just as you would any other value that gets returned.

Sure, I actually like that. But I need a type system that's sophisticated enough to let me handle them nicely; there are times when I need eithers or validations or the like. More than that, there are enough cases where I need one or the other that I need to write code that can handle any kind of context generically.

It's funny because despite the reputation Scala (my language of choice) is actually very simple at the language level. But what you can do with those simple pieces can become very complex, and the range of patterns that are possible takes a while to learn. It's not learning the language that takes ramp-up time, it's the library code.

I predict that if Go is successful it will acquire its own scalaz-equivalent; it pretty much has to, because there are patterns in the way you do things like error handling that it would be stupid to just repeat in every project. I mean, you know what else was a small simple language? Java, which is why it acquired the massive frameworks it's best known for.

(That's not the worst possibility though; that would at least make Go a useful language. But with a type system noticeably worse than Java's, I'm not sure it will be possible to build these things in Go, and a type system isn't something you can bolt-on in a library.)

1) I'm not sure this is true 2) If you have valuable skills, you will not be off-shored 3) If you are then you can pick something else up

If you're just an average programmer you can probably still go program enterprise software somewhere big where personal accountability is lacking.

I have done consulting in lots of projects which had off-shoring components in Fortune 500 companies.

If it wasn't for the NDAs I would have lots of war stories to tell.

I've seen many projects outsourced. Exactly zero were successful. In fact, all of them required a total rewrite after getting the final product back.

Reply on news.ycombinator.com