Hacker News Reader

Comment by nobleach | Hacker News Reader

While this philosophy has a lot of value, it just isn't for me. I did a few apps in Go, and fought my way to a decent level of proficiency. I got to a point where I could solve some problems without constantly consulting the docs. But in the end, I wasn't enjoying the experience. The speed was great, the compilation was great. All the selling points were true. But it was missing so many things that I enjoyed using from other languages. (Mostly methods for dealing with collections of data - everything in Go is a for loop). I did another project in Kotlin shortly after and wow, that language has everything AND the kitchen sink! But, I truly enjoyed myself more while working with it. So, this is not me saying Go is "bad". It's actually quite good. It's just not something I enjoy.

View on HN

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.

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?

> 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.

Of course it's a matter of preference and being the right tool for the right job! Personally after using Go to build a simple ray-tracer and having to do numerical computations with it, I would really think twice before doing it again.

Want to reverse an array? You can't just list.reverse() or list[::-1] like you'd do in Python. Want a simple lookup if a value exists? You can't ['a', 'b', 'c'].include? 'a' like you'd do in Ruby. Want to reach for low-level primitives? You'd have to delve into CGO territory, which is not always "elegant". Want different concurrent paradigms (eg. an actor model), well, maybe you're better off without it.

But it's up to you whether that kind of 'simplicity' is desirable or not.

One of the things that Go tries to do is keep you from accidentally calling expensive operations.

Testing for membership in an array is O(n) in almost any language - and there's a lot of new coders who will happily call it inside a loop. My second internship, I reworked an O(n^4) method to O(n^2) for some code written in R by a senior statistician. This raised the feasible N from 4 to about 13 (in terms of what results you could get in two or three days of compute).

Google doesn't want anyone making that mistake in production, where throwing more servers at the problem costs a whole lot of money. And they hire a lot of junior devs.

I'm sure as somebody who's writing their own raytracer, you know the performance cost of this lookup intimately, and you've made the performance trade-off when picking your data structures. (E.g: maybe the include function is called rarely, or it really is just 3 items, etc). But Go is made for teams of varying skill levels, and so it takes the position that doing uncommon things should take some extra work.

I absolutely get, and appreciate that. I'd never tell anyone NOT to use it. I'm simply sharing my own experience as I've been asked several times if I've ever considered Go for new services. I certainly have. I've produced. I just would choose not to do it again.

Less is more... until you need more.

Reply on news.ycombinator.com