Hacker News Reader

Comment by hardwaresofton | Hacker News Reader

There seem to be a bunch of blog posts popping up recently criticizing golang channels (speed/ease-of-use advantages of mutexes, stdlib prefering mutexes, channels forcing awkward code, all the points in this post), and the lack of generics.

I'm starting to think I might have drank the kool aid too early (grateful, however, to read something that caused me to reassess), as I have recommended Go at least once to coworkers.

Is it fair to say that these are some of the last remaining warts of the language? I still like a bunch of other things about go (super ez cross compilation, package management system, fantastic stdlib & testing support)

View on HN

I've been using golang for the past 3 years almost exclusively for very high traffic applications. I still maintain applications I wrote in the past in different languages, but any new application uses go on the backend if I get the final say on it.

People have been complaining about generics ever since I've began following golang, and people say that it'll never stick around and never find it's following in enterprise, but every month I see another large company launching a product written in go, or rewriting an existing product using go which saved them time and hardware resources or get job offers from recruiters specifically looking for golang devs.

Don't be afraid that you've drank the kool aid too early, I've been banking my career on it and the longevity of it and have had no regrets.

If you've only been doing something for 3 years you haven't been banking any longevity or career on it.

I don't have any opinion on the long term viability of go vs other languages, but "amount of jobs available" is certainly one of the weaknesses of go vs something like java. Which easily scales to the same levels of go.

If I work on projects for clients, golang is used as the backend of the project after I explain the benefits of the language and process I use as I'm able to get the job done quicker, that's all I mean by that.

I love go, we couldn't have built out our current software without it.

Channels are .. not great. They are too slow for many use cases.

That said, I'm building out a tool right now that uses channels in a nice way; it takes input from a bunch of spots, and the channels magically force it into an orderly queue which is operated on. That's quite a lot of code I don't have to write.

If the channel messages went up past a certain amount, mutex contention and throughput worries would push me onto a different angle of attack though.

Anyway, push go all you want. It compiles fast to a wide variety of statically linked binaries and is performant and easy to deal with. Most of the complainers about go are coming at it from what I would call a craftsman approach: go is a modern Java, not a Haskell with C friendly syntax. It doesn't want to be Haskell or Lisp, those languages can be very hard to use and maintain for junior developers in large teams.

It's not a modern Java, it's an antiquated Java. It might aim to be modern, but Go is far from being a modern programming language, even if it was implemented in modern times.

I disagree; it's modern in its sensibilities about which features to restrict in order to fulfill its design goals, and it is informed by experience distilled from millions of developer hours at large companies since Java was designed.

Go will never have functions (well, this is a class in Java) like RequestProcessorFactoryFactory.RequestSpecificProcessorFactoryFactory, an actual apache xmlrpc server class name.

There is some irony to your use of the term modern here, as the original modernists coined the phrase less is more which nicely sums up the Go authors' approach.

Go is a modern language, in every sense of the word. You may not like it, other languages might work better for you or for certain situations (which is great, it really is), but don't pretend it is antiquated or created in ignorance.

> It doesn't want to be Haskell or Lisp, those languages can be very hard to use and maintain for junior developers in large teams.

Can you expand a bit on the difficulties that these junior developers had with Haskell?

> It compiles fast

It compiled fast

I have compiled two codebases this week; the first is an ios app that loads a screen and some sprites, and lets the user touch the sprites, then plays a sound.

The second loads over 100GB of data and uses 60+ go libraries.

The ios app takes over 5 minutes to compile from scratch, the go program takes 16 seconds.

Actually, I've also compiled haskell from scratch (oh wow, that's like https://xkcd.com/303/ slow). At least 30 minutes.

And, I compiled the go compiler from scratch today to try out something on go tip. Compiling a separate compiler for something like 20 different cross compilation targets was under 5 minutes, total.

It's snarky to complain; while the compiler is slower than it was, it adds significant features and performance. It's emphatically not 'slow' in my opinion.

I really really doubt Go will ever get generics better than Java's, if ever. Generics bring in inherent intellectual baggage that the Go team very much tries to avoid (unsuccessfully fwiw: Many people eventually hit the question of "Why can't I pass []Type to []Interface if T fulfills Interface?" or in other words "why aren't Go slices covariant?")

I disagree. Useful, proven abstractions like Futures, Map, Filter, Functors are actually simpler to use and reason about -- not more complex.

Simpler enough to use and reason about that tools in such languages have been mathematically verified a lot by relatively small teams. The imperative, popular alternatives are usually PhD projects for people attempting such things. Speaks volumes about the intrinsic complexity of reasoning about such things.

oh I agree, but the Go Way does not

You like the dependency management & testing stories of go? I'd say those are pretty common universal complaints from the people I know programming go.

Are you referring to vendoring? That's where I usually see the most complaints -- I mean the fact that something like "go get" was baked in from the get-go (to be fair, just about every modern language no considers this important). Not all languages came with any pre-baked (and decently considered)

As far as testing goes, I find the stdlib to be adequate, especially for relatively simple programs. Are the complaints your familiar with over the lack of more powerful testing tools like quickcheck?

> Are the complaints your familiar with over the lack of more powerful testing tools like quickcheck?

Yes but not just that, the stdlib test library is missing basic functions you will find in other testing libraries (things like equality asserts etc).

It is of course adequate. But its certainly not great.

Yeah you're right -- fantastic is definitely an exaggeration

Also I wanted to add, if you are having problems with testing in golang, I've found great success with Gomega, Ginkgo and Agouti. They are fantastic libraries

And then some guy somewhere will tell you using third party testing libraries is not "idiomatic" and shame the maintainer publicly in a blog post like it happened before. "You don't need that in Go"™

> dependency management & testing stories of go

I've heard ppl complain about dependency management but what about testing ? Are there specific issues with testing in golang?

The stdlib is very basic and many of the maintainers are opinionated about that being a positive.

Reply on news.ycombinator.com