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

351–360 of 466 posts

Re: Why Go Is Not Good (2014)

#351

Post by Merovius »

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…

> 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.

Then you weren't really listening, tbh. Everyone on the go team has acknowledged the usefulness of generics now. It's just that so far no good solution for the associated tradeoffs has presented itself.

Re: Why Go Is Not Good (2014)

#352

Post by gendoikari »

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…

I think the language that wanted "to rule them all" was C++, and we all know how it ended. C++ can be procedural, oop, functional, you have metaprogramming, generics, everything. Everything. C++ is everything. Every pattern, every design philosophy can be implemented in C++. How much time does it take to compile? How many developers do know every C++ feature and pattern?

Re: Why Go Is Not Good (2014)

#353

Post by Merovius »

parenthephobia wrote: post #348
pkulak wrote: post #161

Earlier quoted context omitted.

I think everyone who uses Go for anything is pretty clear about why they like it, and one of the major reasons is simplicity. So why are people then surprised when criticisms over lack of features fall on deaf ears? And to be honest, this whole argument about pitchforks seems like a straw man. If anything, it's currently fashionable to dump on Go at every opportunity. Hell, it's fashionable to dump on everything arou…

> I think everyone who uses Go for anything is pretty clear about why they like it, and one of the major reasons is simplicity. Nope. I like Go because: * Interfaces * A sane, fast, build system * Concise syntax, mostly * Garbage collection * Excellent concurrency support * A (for the most part) well-designed standard library * Optional semicolons * Compile-time type-checking * Static binaries I like Go because of th…

> If you don't notice that criticism of Go is immediately and vigorously argued against... Well, you can't be following the comments very closely.

Huh? Have you ever argued against anything on the internet and not been countered immediately? Do you think if I'd publish criticism like this about, say, emacs, haskell, firefox, twitter or puppies, I wouldn't get comments immediately telling me that I am wrong and fundamentally misunderstanding what an editor, programming language, browser, social networking platform or adorable animal photo is all about?

Re: Why Go Is Not Good (2014)

#354

Post by thegeekpirate »

x1024 wrote: post #215
tjholowaychuk wrote: post #211

I think this post neglects the fact that one of Go's biggest strengths has almost nothing to do with the language. A huge portion of every-day logic is implemented very well, and very consistently in the stdlib. Personally I don't want to go pick through half-baked third-party packages, mix and match concurrency models or GC. I have experienced enough of that in Node and it's not pretty. Having it all consistently im…

But... Python already exists? Sorry to go all old-school on you, but the quality of Python's stdlib has literally been a part of pop culture for more than half a decade: https://xkcd.com/353/

> But... Python already exists?

He never said Go was the only language which had a wonderful standard library, only that it's

> one of Go's biggest strengths

Re: Why Go Is Not Good (2014)

#355

Post by acjohnson55 »

vardump wrote: post #327
nevir wrote: post #270

Earlier quoted context omitted.

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…

Well, as a mainly C++ programmer, I'd trade exceptions for that any day. Much easier to understand what is going on, no need to find out if something in the call graph of the method I call throws or not. Also error handling code is where the error occurs, not some completely different place. Properly handled exceptions aren't any less code anyways. Unless you can just drop everything on the floor.

As a Scala coder, I'd say you can have it both ways by encoding the result as type that can have success or failure cases. No fancy control flow needed, just pattern matching.

Re: Why Go Is Not Good (2014)

#356

Post by AnimalMuppet »

spion wrote: post #330
jshen wrote: post #277

Earlier quoted context omitted.

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.

As far as I can tell, conclusions are based on facts about the language as well as other languages. Maps, slices and channels are generics. I'd like to see code in Go written without maps, slices or generics. Go will never implement immutable data structures. Its impossible to write an immutable data structure library without generics. Go will never implement Futures / Tasks / Observables. Its impossible to write Fut…

You're coming from the same bias as the author of the article: Haskell and Rust are what a language should look like; Go doesn't look like that, therefore Go is bad.

Take one of your points:

> Go will never implement immutable data structures. Its impossible to write an immutable data structure library without generics.

Fine; I won't argue whether your statement is correct. But so what? That only turns into something anyone should care about if you also assume that "immutable data structures are The Right Way".

> Here are some statistics: In Go its impossible to write 90% of the functions listed here: https://lodash.com/docs - because they take higher order functions, which use generics.

This proves that Go is not built to use higher order functions. It does not prove that Go is flawed (unless you also assume that FP is The Right Way).

TL;DR: Go isn't trying to be a functional programming language. Some people think FP is the only way to go, and therefore think Go is bad. Those people need to realize that FP is not the only way to program, and to stop trying to force Go into their FP world.

Re: Why Go Is Not Good (2014)

#357

Post by thegeekpirate »

crimsonalucard wrote: post #290

Imagine a flawless gemstone with a permanent stain on one of the edges. This is go, and this is why people complain endlessly. The creators of go only look at the gemstone from a single angle. So they never see the stain and they really don't care. When people complain to them, they just tell the complainers that they're looking at the gemstone from the wrong angle.

> The creators of go only look at the gemstone from a single angle. So they never see the stain and they really don't care. When people complain to them, they just tell the complainers that they're looking at the gemstone from the wrong angle.

This isn't true at all, and is incredibly naive. Here's the reasoning behind not having generics, for example:

https://news.ycombinator.com/item?id=9622417

https://golang.org/doc/faq#generics

Re: Why Go Is Not Good (2014)

#358

Post by innocentoldguy »

thegeekpirate wrote: post #309
innocentoldguy wrote: post #299

Earlier quoted context omitted.

In relation to the blog we're discussing, Javascript is an excellent example, since one of the blog's points is that we shouldn't allow Go to become yet another Javascript.

Your post (and in turn, my reply) had absolutely nothing to do with the article. > I don't think a language's popularity has anything to do with it being a good, well-thought-out language. Just look at Javascript. My point is that it's popular because we've been forced into using it, and the web is now much larger than it used to be. I'm explaining why it became popular, despite it's downfalls. No other recent (past…

My first post was directly related to the comment I replied to. It also relates to the article. I agree that you're reply was irrelevant, as is your second.

Re: Why Go Is Not Good (2014)

#359

Post by jwatte »

Go is a perfectly fine incremental refinement on the Perl model.

What the Go cheerleaders lack is actual experience of most of the alternatives over significant time.

I have code in production based on Go, and C++, and Haskell, and PHP, and Erlang, and Python, and JavaScript, and probably others. Go doesn't really stand out, at all. If I had to pick one, I'd pick C++. If I had to add another, it would be Haskell, unless I needed front end which forces JavaScript.

Go is probably ahead of PHP, though, so that's something.

Re: Why Go Is Not Good (2014)

#360

Post by krisdol »

hatsunearu wrote: post #225
carols10cents wrote: post #51

Earlier quoted context omitted.

Yeah, I suspected it was old when the Rust version used was 0.11...

The most often encountered thing that I find Rust frustrating is how much the language changed over time--lots of random answers and posts that are outdated floating around somewhere that I have to throw out because the language changed.

It's just incredibly young at this point, and still in a phase where making breaking changes for the sake of the language vision is acceptable. Swift has been in the same boat. I'm sure that will change in the near future. Luckily both languages have great compilers that catch backwards-incompatible issues.
Post reply on HN