Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go Is Not Good (2014)

yager.io

Post reply on HN
Print view View original

11–20 of 466 posts

Re: Why Go Is Not Good (2014)

#11

Post by gendoikari »

cmrdporcupine wrote: post #5
gendoikari wrote: post #4

Earlier quoted context omitted.

What do you think about goroutines and channels?

They're fine concepts, but... On the little project I was tasked with using Go with at Google I got slapped down by the readability reviewers for using them. I think this is an interesting construct, but not sure that community really knows how to use them well? Erlang at least is consistent on this -- it has that hammer well tuned and isn't afraid to pound nails with it.

Mmmm I'm puzzled. I don't think we are consulting the same community... Goroutines are everywhere in all the main go projects. Goroutines and channels are one of the main reasons Go exists.

Re: Why Go Is Not Good (2014)

#12

Post by pmilot »

I like this article and I agree with most of what was said there.

Against that type of point-by-point criticism, fans of a language will usually use the argument: "but that language was not designed for that!". Then the question becomes: What was that language designed for? My impression was that Go was meant to be a slightly higher-level systems language with better constructs for concurrent programming. With that in mind, it seems to me that Rust is just a "better Go".

Re: Why Go Is Not Good (2014)

#13

Post by tvon »

joined wrote: post #7

If anyone is looking for the article publishing date (no indication on the site), archive.org made the first snapshot on June 2014.

Thanks, I found "" in the source as well, but it drives me nuts when web pages have no publishing or last-modified date.

Re: Why Go Is Not Good (2014)

#14

Post by hackcasual »

gendoikari wrote: post #4
cmrdporcupine wrote: post #2

While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have mad…

What do you think about goroutines and channels?

Using go for goroutines and channels is a bit like using Perl for regular expressions. The features have been added in a way that makes them easy to use and serves as a nice idiomatic platform, but fundamentally it's functionality other languages can provide via library support.

Re: Why Go Is Not Good (2014)

#15

Post by cmrdporcupine »

omginternets wrote: post #10
cmrdporcupine wrote: post #2

While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have mad…

I get where your coming from (I think... let me know if I've missed your point), but I think the purpose of Go's type system is to offer some safety while emulating a dynamic language. In some cases, rigid type-safety is necessary, but I have trouble taking this criticism seriously while languages like Python enjoy extreme success. If Python can be insanely useful (and acceptably safe), then why not Go? tl;dr: Go is…

Then it needs to stop calling itself a 'systems programming language.' Or maybe it doesn't, but others need to stop calling it that.

To me, it's a replacement for Java, not C++. I think that's a reasonable target.

Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.

Re: Why Go Is Not Good (2014)

#16

Post by grabcocque »

My essential issue with Go is how much it feels like cargo cult language design. Compared to other emerging languages [Rust, Clojure, Elixir, Julia...], it feels inconsistent, half-baked, uncertain what it's for or where it's going.

Re: Why Go Is Not Good (2014)

#18

Post by pbnjay »

Go's biggest strengths for me around the tools and ecosystem, and code readability. I very rarely find myself wanting generic code, and when I do using empty interfaces make the code difficult to read.

I don't want to start an imperative-vs-functional war or anything, but I've noticed many of the people complaining about Go seem to be functional programming aficionados. Is this because of how much they like embedding and abstractions, or is it because they're trying to put the square Go peg into the round FP hole?

Re: Why Go Is Not Good (2014)

#19

Post by necessity »

fixermark wrote: post #6

"Go does not support operator overloading or keyword extensibility." Very much working as intended, I believe. Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense (such as defining mathematical operations on vectors using the same symbols that are used in vector mathematics), we lose in too many developers thinking they have a…

Agreed. Explicit is better than implicit in this case (and most, if not all, cases).

Re: Why Go Is Not Good (2014)

#20

Post by cloud_monk »

gendoikari wrote: post #4
cmrdporcupine wrote: post #2

While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have mad…

What do you think about goroutines and channels?

I think the way Go addresses concurrency is simple and straight-forward. It's trivial to write concurrent applications. If your target is writing semi-low-level infrastructure software I think Go is a great choice. It's definitely got a lot of fans in the world of people writing software for DevOpsy type applications.

From a personal standpoint, it's missing a lot of the features I like, namely ADTs, list comprehensions, folds, maps, etc. But that's just my personal style, not something wrong with Go. Go programs don't necessarily always look pretty but you can usually understand them after a minimal amount of study because the language is so simple.

Post reply on HN