Why Go Is Not Good (2014) • Hacker News Board

Re: Why Go Is Not Good (2014)

#111

Post by dchesterton » Wed, Dec 09, 2015, 4:37 PM UTC

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…

Precisely. Just because a language lacks certain features available in other languages doesn't mean it's not 'good'.

Things that are 'good' for me: Good concurrency primitives, single binary deployment with no dependencies, a language that can be picked up in a matter of days and a consistent coding style (gofmt).

If another language suits you better than use it, but to call Go "a regression from other modern programming languages" ignores the many reasons developers are using it.

Re: Why Go Is Not Good (2014)

#112

Post by odonnellryan » Wed, Dec 09, 2015, 4:37 PM UTC

microtonal wrote: post #85

Kapura wrote: post #52

I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language. The problem is that most big languages today are hammers, and they can are used to hit all sorts of nails to fasten all sorts of unholy planks together. Go is a screwdriver. Still good for construction, but you need to be using it in the correct way and you ca…

I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language. This is the standard Go defense. 'It's not Go, it's you.' I have written some larger projects in Go, and I am in full agreement with the article - Go is a relatively weak and repetitive language, similar to pre-generics Java. So, why does Go gain so much tract…

It's still a very young language. It is good for a lot of stuff: I've written quite a few daemons in Go that perform really simple tasks very quickly (think: get an HTTP request, do something small, forward it).

I've also worked on Docker, which while the design patterns are interesting, is a larger project that works very well with Go!

Re: Why Go Is Not Good (2014)

#113

Post by quadrangle » Wed, Dec 09, 2015, 4:38 PM UTC

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

Haskell can do fast web servers. See Warp

Re: Why Go Is Not Good (2014)

#114

Post by blub » Wed, Dec 09, 2015, 4:38 PM UTC

coldpie wrote: post #38

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…

This is a well-written objection and I completely agree. Operator overloading is consistently one of the worst ideas I see in programming languages, C++ being the prime offender. Programmers think they're being clever when they write crap like boostfs::path path("/some/path"); path /= "yourfile.txt"; Meanwhile, reading your code without being familiar with boostfs::path, my brain grinds to a halt while I try to under…

Yes, boost has a couple of instances of eyebrow-raising uses of operator overloading. Including stream operators, that still does not prove that operator overloading is an anti-feature.

On the contrary, when all you have is a couple of examples that aren't even that bad and a slippery slope argument, you are on very thin ground, rhetorically speaking.

Re: Why Go Is Not Good (2014)

#115

Post by insulanian » Wed, Dec 09, 2015, 4:38 PM UTC

When one mentions Go, I imagine the crowd. When one mentions Haskel/OCaml/F#, I imagine an artist.

Re: Why Go Is Not Good (2014)

#116

Post by eximius » Wed, Dec 09, 2015, 4:39 PM UTC

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…

That's not entirely fair. It legitimately solves a lot of issues - concurrency namely - even if it is hindered by its type system. I will bet my long term money on Rust, but where Go works, it works well.

Re: Why Go Is Not Good (2014)

#117

Post by im_down_w_otp » Wed, Dec 09, 2015, 4:40 PM UTC

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 thought the problem it was supposed to solve was to provide a relatively simple language, that performs reasonably well, and which produces statically compiled artifacts to make deployment much easier and lighter-weight?

Go seemed to be borne primarily out of an ops-driven ethos. The fact that it's sort of stupidly become the current darling language of Silicon Valley hipsterdom isn't really Go's fault.

Re: Why Go Is Not Good (2014)

#118

Post by poorman » Wed, Dec 09, 2015, 4:40 PM UTC

The blogger has completely missed the entire purpose of Go. I suggest anyone who actually wants info one way or the other to read the Preface in Alan Donovan and Brian Kernighan's "The Go Programming Language". You will then understand why Go is the way it is and why all the negative points (in his mind) this blogger listed, are not in the language.

Re: Why Go Is Not Good (2014)

#119

Post by fixermark » Wed, Dec 09, 2015, 4:40 PM UTC

pcwalton wrote: post #84

fixermark wrote: post #42

Earlier quoted context omitted.

The difference is that "Add" is not a term that many search engines will drop on the floor. When you get out of the range of plain ASCII strings, you're leaving the range of symbols you can assume your tool of choice will be indexing into search for you. This is likely a short-term reality, but it's the current reality.

How many code indexing tools are in use that aren't grep/ack/ag (because you can grep for +) and don't do semantic analysis? I can't think of any. Visual Studio, DXR (what I've used), all documentation tools, etc. can all handle overloaded operators, and have been able to for years. (Hasn't Visual Studio been able to index overloaded operators for, like, at least a decade?)

github.com

Re: Why Go Is Not Good (2014)

#120

Post by iffycan » Wed, Dec 09, 2015, 4:40 PM UTC

As feedback on the article itself, I kept getting confused. The author describes a wish:

> If I write a function to sum a list of numbers, it would be nice if I could use it on lists of floats, lists of ints, and lists of anything else that can be summed.

I agree with the author and continue reading, expecting to see an implementation of that function in each language. I keep reading and re-reading to try to figure out how the first two code samples (Rust and Haskell) are summing a list. I feel like an idiot, because I can't figure out how that code is possibly summing a list. Thankfully, the next paragraph explains it, but a heads up would have made it more clear.

The article continues with pairs of Rust and Haskell -- as a reader, I'm thinking, "Yes, yes, but show me how this compares to Go." Finally, when I get to `Go's Solution: interface{}` I feel like I'll be able to compare the languages... but instead of implementing an already-mentioned problem, a new problem is introduced:

> Let's say you wanted to write a function that printed a hash code for objects that could be hashed.

As a reader, I have too many things in my head now.

I think the author probably has valid points to make, and I will now finish reading the article. Hopefully some of this feedback is helpful (I'm not trying to be a jerk).