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

181–190 of 466 posts

Re: Why Go Is Not Good (2014)

#181

Post by mike_hearn »

gendoikari wrote: post #11
cmrdporcupine wrote: post #5

Earlier quoted context omitted.

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.

"Readability reviews" at Google are somewhat notorious for imposing fairly arbitrary style choices extremely rigidly, for instance 80 characters per line (woe betide you if even one line in a 5000 line patch is 81 characters...). It doesn't sound so surprising to me that the people behind such a process might have decided that one of Go's primary selling points is 'confusing', given that the Go authors appear to believe their colleagues can't handle a brilliant language!

Re: Why Go Is Not Good (2014)

#182

Post by wyager »

the-tomster wrote: post #60

The author says that "all the problems listed here have already been solved" by Rust and Haskell. Great, so let's stop complaining about Go and use those languages instead. Go has specifically rejected the complexity that these features introduce, both in the implementation of the language and the writing of programs in it. If you want those features, just use a language that has them. Some other people might not car…

> Great, so let's stop complaining about Go and use those languages instead.

That's not a very good attitude. Some people have to use Go (for work), so it doesn't make sense to just ignore them. If every language had the attitude "It's fine as it is, stop complaining", then languages would never improve!

Re: Why Go Is Not Good (2014)

#183

Post by 15155 »

bndr wrote: post #56
hbex5 wrote: post #8

Earlier quoted context omitted.

Any critique of Go seems to be met with angry pitchforks in this place. As you say, the Go developers seem to have developed a kind of bunker mentality where they interpret legitimate criticisms of the language design as personal attacks, and respond by wearing Go's shortcomings as a badge of honour. It's not, I think, entirely healthy.

> Any critique of Go seems to be met with angry pitchforks in this place. You can say that about any language. The people that like the language will always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one talks about their shortcomings, the people get defensive.

Talk about the (legitimate) Haskell shortcomings and you'll be met with open, honest acceptance, mitigation strategies, and academic discussion.

IRC, /r/haskell, whatever.

Re: Why Go Is Not Good (2014)

#184

Post by Filligree »

cmrdporcupine wrote: post #158
digi_owl wrote: post #93

Earlier quoted context omitted.

> 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. Thats not limited to the Go community. It seems to be an attitude that is sweeping the second(?) generation of FOSS developers. Seems like just working on code is not enough any more, it has to have some kind of social/fixing-the-world an…

There is a whole new generation of FOSS/hacker folks younger than me (I'm in my 40s) that I can't relate to. It's so much an ego and self-marketing thing ; everything you do is blogged, you do the speaker circuit, you're judged in interviews by how many stackoverflow questions you've answered, what you have in your github repo, etc. It makes me feel very old. I just want to keep my head down and hack.

There are many, many people who do just that.

I keep my head down, and hack. I don't care about those circuits. And as a result, I'm not as visible.

Re: Why Go Is Not Good (2014)

#185

Post by kungfooguru »

gendoikari wrote: post #11
cmrdporcupine wrote: post #5

Earlier quoted context omitted.

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.

He said at Google not the community. I wouldn't doubt there is a difference.

Re: Why Go Is Not Good (2014)

#186

Post by kyledj »

moultano wrote: post #152
gendoikari wrote: post #24

Earlier quoted context omitted.

About generics, this is highly debatable. This is a design choice, it's not a decision made by accident. You'll surely gonna have boilerplate code in some cases, but all the language will be a lot more readable, and simple. Simplicity it's the most wanted feature of Go, from the designers perspective, I think. In the long term it's preferable to have explicit and simple code, instead of complex magic. This is a corre…

Without generics, you can never write a type safe datastructure. I can't imagine the hubris that thinks the language already contains all of the datastructures it needs.

This isn't true. You can write a type safe data structure. It is simply for one type; you can't share it. That inability to share is the part that generics fixes, but saying you can't write type safe structures is inaccurate.

Re: Why Go Is Not Good (2014)

#187

Post by amyjess »

m0th87 wrote: post #90
bndr wrote: post #56

Earlier quoted context omitted.

> Any critique of Go seems to be met with angry pitchforks in this place. You can say that about any language. The people that like the language will always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one talks about their shortcomings, the people get defensive.

I think the point they're making is that the Go community is unusually pitchfork-ey. Having used Go since pre-1.0 days, I certainly agree; there's a very strong sense of, "if you want , you're doing it wrong" - despite legitimate concerns, like the ones outlined in this article.

I've heard this same criticism levelled at the Clojure community, as well.

Honestly, I can't think of any language community that's developed such a reputation for pitchforkiness towards suggestions as the Go and Clojure communities.

Re: Why Go Is Not Good (2014)

#188

Post by frik »

Go is pretty good for various use cases. Before that, one coded web services and server tools in C, C++, Java, etc. - nowadays Go is ideal for the task. It has the advantages of Java (JIT, strings, higher level concepts, inbuilt concurrency, etc), is fast and shares the simplicity of the C syntax.

Re: Why Go Is Not Good (2014)

#189

Post by jmquigs »

There are some things I like about Go:

1) really fast compilation speed

2) goroutines

3) gofmt

But I learned F# after learning Go, and it felt like I was walking out of Plato's cave. Its hard to use a Go-like language after using the ML-style features described in this post.

Most modern static languages shift the debugging from run-time to compile-time, which is a huge win in my opinion, but Go does not do this. You don't even need to go "pure functional" to get the benefits (as in Haskell), Rust/F#/OCaml are fine.

Re: Why Go Is Not Good (2014)

#190

Post by kungfooguru »

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.

Yea, not having OTP to create proper structure, instead having goroutines and channels created and destroyed all over the place, really hurts readability.

But OTP isn't really possible either because Go lacks links and monitors.

Plus not being asynchronous and no distribution (wouldn't want to go over the network with sync channels anyway)...

Post reply on HN