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

331–340 of 466 posts

Re: Why Go Is Not Good (2014)

#331

Post by gendoikari »

kungfooguru wrote: post #185
gendoikari wrote: post #11

Earlier quoted context omitted.

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.

I'm pretty sure at Google they know why they created Go, why they're using Go, and so on... The assumption that Google reviewers had something against goroutine puzzles me a bit. Maybe the problem was not about goroutines, but about how they were used... I don't know, I'm guessing...

Re: Why Go Is Not Good (2014)

#332

Post by vardump »

blub wrote: post #131
cmrdporcupine wrote: post #15

Earlier quoted context omitted.

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.

No chance to replace Java, when Java is all about ecosystem, tooling, maturity and talent pool. And it has generics. I mean I am no Java expert, but e.g Android Studio is miles ahead anything the go team will be able to ship in the next few years. And I don't think they're even focusing on building such tools since they seem to be stuck on building a debugger right now.

Java doesn't actually have runtime generics. Just type erasure syntactic sugar. ArrayList is the same type at runtime as ArrayList.

Re: Why Go Is Not Good (2014)

#333

Post by steveklabnik »

15155 wrote: post #230
andrew_wc_brown wrote: post #76

Go is good enough when you're switching from Ruby to Go and all you do is build web-applications. * Its forced syntax stops syntax wars. * Compiling down to one binary makes deployment easy. * Its has concurrency out of the box. * Its insanely fast. * A strong community to hire developers easily enough. Does Haskel/Rust have the same criteria? Shurgs

> * Its forced syntax stops syntax wars. Okay, but so does any in-company linter. > * Compiling down to one binary makes deployment easy. Rust and Haskell are both compiled to a single binary, typically, and both can be statically linked (with some work.. this is getting better) > * Its has concurrency out of the box. Rust is actually a systems language and does not have a decent semblance of concurrency (beyond OS t…

  > Rust is actually a systems language and does not have a 
  > decent semblance of concurrency
I have bias here, but so strongly disagree. Many concurrency errors are at compile time in Rust. Rust has a really, really strong concurrency story.

Re: Why Go Is Not Good (2014)

#334

Post by omginternets »

mike_hearn wrote: post #192
omginternets wrote: post #139

Earlier quoted context omitted.

>A huge variety of other languages have successfully implemented generics Completely irrelevant; the argument isn't "generics are hard [full stop]". The argument is "generics are hard" AND "we don't know Go's niche well enough to commit to any specific approach".

But how can they not know that, after so many years?

You'd have to ask them, but I suppose it takes years to carve out a niche.

What I can say is that I recently interviewed a Google engineer who was conducting a survey of Go's usage, so it seems they're at least studying the question.

Re: Why Go Is Not Good (2014)

#335

Post by steveklabnik »

masklinn wrote: post #39
pmilot wrote: post #12

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 i…

Rust's target of being a better C++ means it tends to be more verbose than Go, and less convenient in the short run (no built-in — let alone syntactic — support for evented IO and CSP)

  > (no built-in — let alone syntactic — support for evented IO and CSP)
Channels are in the standard library[1], while async io is in an external package, almost everything is in Rust, and it is one of the packages that will end up making that jump to be in the standard library fairly quickly.

[1]: and, isn't as big of a deal in Rust since we make shared memory significantly safer in the first place.

Re: Why Go Is Not Good (2014)

#336

Post by omginternets »

vardump wrote: post #332
blub wrote: post #131

Earlier quoted context omitted.

No chance to replace Java, when Java is all about ecosystem, tooling, maturity and talent pool. And it has generics. I mean I am no Java expert, but e.g Android Studio is miles ahead anything the go team will be able to ship in the next few years. And I don't think they're even focusing on building such tools since they seem to be stuck on building a debugger right now.

Java doesn't actually have runtime generics. Just type erasure syntactic sugar. ArrayList is the same type at runtime as ArrayList .

This strikes me as a distinction without a difference, in the present case. How is this meaningfully different from the programmer's perspective?

Re: Why Go Is Not Good (2014)

#337

Post by steveklabnik »

fixermark wrote: post #97

For me personally, it's not what the language offers syntax-wise but what I can do with it. I was excited about Ruby because of Rails; only after working with it did I pick up a book on Ruby itself and come to appreciate the cleverness of block arguments (Ruby's insight, that functions that accept another function as an argument almost always accept at most one, so special-casing the syntax for that to make it clear,…

Are We Web Yet has pull requests outstanding for 11 months, it has not been accurate in a long time.

Re: Why Go Is Not Good (2014)

#338

Post by gendoikari »

nevir wrote: post #270
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…

Same for me. I tried really hard to enjoy Go, but it became an incredibly frustrating experience. The language itself was frustrating to me in many of the ways outlined in the article. The community was similarly frustrating. One anecdote that really stuck with me was when enquiring about explicit language support for the error handling pattern. E.g.: f, err := os.Open("foo.bar") if err != nil { log.Fatal(err) } It i…

And this is a clever response if you understand their point: messing with the language it's rarely the correct answer. Do you want to remove some code? How about a function? How about hiding boring details behind more elegant objects? How about using a macro in the editor? And so on... The answer is not (from their perspective) "put some shit in the language".

The problem with Go is that is very idiomatic. If you want to work with Go you need to learn its way, and somehow you need to accept the trade-offs behind its design.

If you do not see any advantages in any way, probably it's not the right tool for you, and that's ok. No problem at all.

Re: Why Go Is Not Good (2014)

#339

Post by agentultra »

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 think they just made their line in the sand. Any criticism of the lack of generics has to take into account the arguments already made for its, as far as I know, deliberate omission.

Every so often people start grumbling about C. They call it a terrible language because the specification contains undefined behavior (and less frequently because they removed the linter from the compiler early on). These arguments are well known and have been addressed over several decades. Any complaint about undefined behavior has to account for the fact that said omissions are intentional and have been well-argued for by the ANSI committee and community of C compiler developers. If you can't do that then you're complaints are just going to fall on deaf ears: you haven't contributed anything that we don't already know.

If anyone wants to introduce generics into Go they're going to have one hell of a debate on their hands. I believe the reasons against it are firmly established and it will never happen. I may be wrong but any argument for their inclusion has a lot of work to do.

This doesn't make Go a bad language. It's probably just not the right fit for your purposes if you really need generics. Such abstractions are not a universal property of languages. I get by fine in C without them... but I prefer C (or Common Lisp) because if I did want them there are good libraries to give me those features.

I don't know when it became fashionable to have such opinionated languages but I tend to disagree with most of them so I just avoid them for the most part.

Re: Why Go Is Not Good (2014)

#340

Post by amyjess »

smw wrote: post #311
amyjess wrote: post #187

Earlier quoted context omitted.

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

Steve Yegge has written a lot about this. Much of his writings on the subject are in these mailing-list posts: https://groups.google.com/d/topic/seajure/GLqhj_2915A/discus...

Make sure to expand all of his posts on the thread, because he goes back and forth for a while.

Much of it has to do with the community's attitude towards macros: there's an attitude of "macros are bad and you shouldn't use them", and people who write macros are often jumped on by the community.

Here's one sentence of Steve's that sums it up:

> When people announce: "hey, I made a loop macro!" the response absolutely can NOT be: "why can't you just write it as a series of maps and reductions?"

And another:

> If Clojure people all said "of course you can use macros! Of course you can use CL-style loop facilities! It's your code, do what you like! Feel free to use nonlocal exits all you like!" -- well, then it would be a lot closer to a Yes language.

The problem is the way the community treats people who don't follow the prescriptive norms of the core Clojure people (norms which are often in conflict with the broader Lisp community).

Post reply on HN