Hacker News Reader

Comment by LandR | Hacker News Reader

I feel the same, we are starting to use Go now and I really don't like it.

Things that in other languages I can do in half a dozen lines of code, I find I'm writing 4x time more in go.

And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using.

There's too many missing features I use heavily in other languages that make my life easier that I really miss them in go.

I will say I do like that its opinoinated on the formatting. Just takes away an entire tiresome argument.

View on HN

> And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using.

I tend to conflate higher expressiveness with being "clever" until you're really proficient in the language. I think Go's main value prop is that it performs well with very little ramp up time compared to languages with more powerful features.

If you have a team of people who are really strong with something like OCaml or Scala, they'll be amazingly productive. But if you have a rotating team of engineers with varying backgrounds, it's hard to beat Go when you're talking about time-to-productivity.

The basic set of more expressive operations (like map, filter, and reduce/collect) are not "clever", they exist in lots of "boring" languages, not just languages like OCaml and Scala. It is true that their semantics must be learned, but this is also true of the semantics of for, while, if, switch, function(), object.method(), etc. etc. We don't lament that learning how function calls work is lengthening the ramp-up time of people who already know how to write straight-line code and jumps.

Yeah, I think the charge of "clever" is often thrown out when one uses a different way of thinking. I'm not an FP zealot at all, but I do think learning to think recursively does something to one's programming. (Working through SICP or even The Little Schemer) My own personal take it that I appreciated and enjoyed some of those paradigms far more. What I would NEVER try to do is turn Java or Go into those paradigms though. I would, however, like to have some of those handy niceties available by default. (I want to map over a collection and apply a function to each member). But again, that's a personal preference.

It is idiomatic in Java to use the streams api for mapping, filtering, and reducing. It is a perfectly natural fit in the language. The only bummer is that those operations can't be built directly into the collections api due to compatibility concerns. It doesn't require thinking recursively or anything clever or advanced, they are very simple operations.

The irony is that even modern Basic is a clever language, and Python comprehensions are probably a PhD level feature, yet primary school children seem very at ease with those languages.

So Go was designed for toddlers?

> if you have a rotating team of engineers

That's the problem: burning out engineers.

Google has been developing a language to make it easier to change cogs in the machine.

The quotes from Pike are pretty clear:

http://nomad.uk.net/articles/why-gos-design-is-a-disservice-...

To the "everything in Go is for loops" point of the parent, I really think the value of higher-level abstractions of common loop patterns are often underrated for readability and correctness. The advantage is that it is a lot more obvious when code veers from the pattern, which alerts the reader to spend more time thinking through what it is actually doing. Put another way, it is easier to write a for loop that looks like a 1:1 map from one set of values to another but actually does something a bit different, than it is to write a map operation that does something besides mapping.

I think you're right regarding the verbosity, but I personally find this is outweighed by the fact that my code is 2x more likely to run correctly on the first try, and do what I expect it to.

2x more compared to ... C++, Java, Python/PHP/JS/Ruby, Haskell? Which kind of language is the comparison?

Reply on news.ycombinator.com