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

311–320 of 466 posts

Re: Why Go Is Not Good (2014)

#311

Post by smw »

amyjess wrote: post #187
m0th87 wrote: post #90

Earlier quoted context omitted.

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.

What a strange argument. The difference is that clojure is about as extensible a language as it's possible to have.

A macro system in a homoiconic language allows you to implement many types of semantic sugar or things that would be full-on 'language features' in other languages as a simple library. See core.async: https://github.com/clojure/core.async

Re: Why Go Is Not Good (2014)

#312

Post by nine_k »

laumars wrote: post #132
Retric wrote: post #121

Earlier quoted context omitted.

In the end there is no one true best language out there. Go is great for a subset of problems and making it better at other things is a balancing act. The most popular languages are generally accidents of history. Unix gave us C, browsers gave us JavaScript, and Databases gave us SQL, etc.

> In the end there is no one true best language out there. Go is great for a subset of problems and making it better at other things is a balancing act. This is the problem though - I think many people expect there to be a "one language to rule them all". Personally I like having lots of different languages that excel at some problems even if that means they fall short at other problems. But I think some people eithe…

It's OK to see a language that has certain strengths but also some weaknesses due to the nature of the strengths.

It's sad to see a language that has certain strengths but also some painful weaknesses for no good reason except that it's v.1. So far the best I've heard is something like "We understand there's a problem for certain users, and we don't rule out adding generic types some time later, but it's hard and our priorities are different". It is indeed not easy to do well (though Java has somehow managed to find a satisfactory solution).

Well, I'll wait a few more years.

Re: Why Go Is Not Good (2014)

#313

Post by klodolph »

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.

I've met a lot of people with your attitude both in open source and in industry, young people and old people alike. You want to keep your head down and hack? That's another way of saying things like, "I just don't want to deal with office politics." Unfortunately, the world is not set up to make you happy. Politics is just the reality of being human, and people who acknowledge that humans are political will end up getting more work done than people in denial.

Politics isn't a dirty word, it's just the reality of having more than one person on the planet.

Re: Why Go Is Not Good (2014)

#314

Post by talles »

> Go has the null pointer (nil). I consider it a shame whenever a new language, tabula rasa, chooses to re-implement this unnecessary bug-inducing feature.

I agree that all points in the article are very debatable. But this one I'm yet to see the counter-argument.

Re: Why Go Is Not Good (2014)

#315

Post by nine_k »

evmar wrote: post #91

This sort of gratuitous takedown is unfortunately crack for HN -- pages and pages of "here's how this popular thing is not like this other thing I like", without any thought given to why things are they way they are. Go is missing a lot of my pet features too but I know its authors are smart so I don't just immediately jump to assuming they don't know what they're doing. Thought experiment: write a proposal that work…

Did you have a chance to look at Kotlin?

It manages to be pretty FP-friendly without being FP-front-and-center and keeping intreoperability with Java as easy as possible, and staying pretty simple.

But yes, you need to rethink the design from the start. I wish it would have been done differently, less C-like, but it hadn't.

Re: Why Go Is Not Good (2014)

#316

Post by klodolph »

jshen wrote: post #277
sanderjd wrote: post #238

Earlier quoted context omitted.

I agree with a lot of this, but where things get muddy with empirical evidence, is that it implies a certain "default". In this case that can either be something like "generics are useful" or something like "not having generics is useful". I don't think either hypothesis is supported by much of the sort of empirical evidence you're looking for. Basically, I share your sense that this is all anecdotal and subjective,…

There is no rigor to this blog post. He didn't have two teams build the same project with and without generics or anything like that. The title is "why go is not good" which is drawing a conclusion based on an anecdote. It's the equivalent of walking outside in December, stating that it's cold, then drawing the conclusion that the globe isn't warming.

Calls for rigor are unproductive, I think. The unfortunate reality is that an experiment with the rigor you want would be prohibitively expensive. The big differences in productivity I suspect are going to be in larger projects over longer periods of time. You also can't figure anything out from small sample sizes, so you would need to take four large teams, split them randomly into two groups of two, and have each time solve the same large problem over a long period of time.

Unfortunately, since we can't afford the rigor, we have to make do with anecdotes and less powerful studies.

Re: Why Go Is Not Good (2014)

#318

Post by riwsky »

dgellow wrote: post #61
hackcasual wrote: post #14

Earlier quoted context omitted.

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.

+1 on this. Clojure's core.async[0] is the perfect example of an implementation of CSP as a library. Even JS can be used to implement such concepts via the use of generators[1]. [0] https://github.com/clojure/core.async [1] https://github.com/ubolonton/js-csp

It's also a perfect example of the limitations of that approach - core.async had to make serious compromises in its interface because it was 'just a library': expressions with https://github.com/clojure/core.async/wiki/Go-Block-Best-Pra...

Re: Why Go Is Not Good (2014)

#319

Post by Denzel »

moonchrome wrote: post #135
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.

But those languages are universally accepted as bad (well aside from Ruby, I don't know much about it because I already know Python and never felt I needed a different syntax for pretty much the same thing (arguably less used)) If someone started developing a language today and came up with C or PHP they would be criticized for many of the pitfalls of the mentioned languages and there would be a lot of improvements t…

It's trying to sell itself as a better solution to Google's existing problems[1]. That's the keyword (no pun intended).

Just so happens that some developers at-large perceive an overlap, correct or incorrect, between their problems and Google's problems. So they use the language, and they're happy with it.

Go is not trying to sell itself as a better general solution. It was built within the context of Google's problems.

[1] https://talks.golang.org/2012/splash.article

Re: Why Go Is Not Good (2014)

#320

Post by exDM69 »

haldean wrote: post #266
exDM69 wrote: post #191

Earlier quoted context omitted.

> but fundamentally it's functionality other languages can provide via library support. Implementing goroutines and channels requires language and runtime support for green threads that are n:m multiplexed on top of native threads. It can not be implemented as a library in most languages, at least not efficiently. Any language with thread support can set up threads and put a concurrent queue between them, but that's…

It's been done in C; check out libmill[0], which even matches the syntax pretty well. [0]: http://libmill.org/

Yeah, you can do this in C if you do stack switching with a little bit of assembly. It's kind of doing a custom runtime environment for C. Not many other languages can do this.
Post reply on HN