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

Re: Why Go Is Not Good (2014)

#321

Post by wwweston » Wed, Dec 09, 2015, 7:27 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…

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

I applaud your advocacy. Using other languages is pretty much my personal plan.

The problem, though, is that like everybody else in the industry, I don't work in a vacuum. Other people may be making platform decisions for projects I work on.

Complaining about Go's limits seems like a good additional strategy to minimize the chance that I'll have to work around them again in the future.

Re: Why Go Is Not Good (2014)

#322

Post by gendoikari » Wed, Dec 09, 2015, 7:27 PM UTC

innocentoldguy wrote: post #248

gendoikari wrote: post #3

We'll see in the next few years... We'll see...

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.

I didn't mean that. I meant that in the next years we'll see if some design decisions were bad or wise.

Re: Why Go Is Not Good (2014)

#323

Post by duderific » Wed, Dec 09, 2015, 7:27 PM UTC

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 too am in my 40's, I work with many of the "next-gen" folks in their 20's, and by and large, they just want to keep their heads down and hack too.

Of course there are the superstars that you hear about, who are super active, writing new languages and libraries and whatnot, but I would say that is the extreme end of the bell curve.

Re: Why Go Is Not Good (2014)

#324

Post by exDM69 » Wed, Dec 09, 2015, 7:29 PM UTC

iofj wrote: post #249

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…

No ? Qt, Gtk, ... all do it.

Huh? Care to elaborate on this? As far as I know, GTK (and Qt IIRC) use a single threaded event loop. That's not at all the same thing (albeit can be used for similar things).

Re: Why Go Is Not Good (2014)

#325

Post by exDM69 » Wed, Dec 09, 2015, 7:32 PM UTC

adrusi wrote: post #231

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…

Any language that has continuations, or at least thread-safe coroutines, can implement goroutines and channels. This includes scheme and lua. Also any language where the stack can be directly manipulated can implement those thread-safe coroutines, so that opens up C/C++ and perl and possibly some others.

Yes, all the languages you mention have the necessary language and runtime support required, probably a handful of others too (but by no means every language out there).

C and C++ are a bit different because you need to resort to assembly and know details about the target arch to do stack switching but that's acceptable.

Re: Why Go Is Not Good (2014)

#326

Post by mempko » Wed, Dec 09, 2015, 7:33 PM UTC

drauh wrote: post #239

gozo wrote: post #148

Earlier quoted context omitted.

I don't really see how Go is, or should be, that limited as a factor of design (in contrast with something like Erlang). It's just that everyone in the ecosystem is focused on on the same things and when people with other use cases, that could benefit from the properties of the language, try to make themselves known it's all "works for me". Edit: Thanks for proving my point everyone. Edit2: To be slightly less snarky…

By this measure, isn't C worse?

Even with C, you can do some type safeish data structures using macros.

Re: Why Go Is Not Good (2014)

#327

Post by vardump » Wed, Dec 09, 2015, 7:34 PM UTC

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…

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.

Re: Why Go Is Not Good (2014)

#328

Post by eveningcoffee » Wed, Dec 09, 2015, 7:34 PM UTC

kilink wrote: post #305

eveningcoffee wrote: post #242

Earlier quoted context omitted.

However I comletelly agree with this, it is very confusing API. You should even be able to do this in Java with "import static" Yep, you should define a static methods add, sub, pow etc with BigDecimal parameters and then use import static. Something along class BigDecimalMath { public static BigDecimal add(BigDecimal x1, BigDecimal x2) { return x1.add(x2); } } Also JVM JIT would very likely inline such code, so you…

Too bad you can't just call functional interfaces in Java 8, or you could just do something like this: BiFunction add = BigDecimal::add; add(x, y); Unfortunately you have to do: add.apply(x, y); Which is kind of cumbersome.

Yes, it pretty much defeats the point. It would work if they had implemented a default method for an interface.

Unfortunately they brought something completely different in the name of Default Methods, and that was in my opinion not needed.

Re: Why Go Is Not Good (2014)

#329

Post by gendoikari » Wed, Dec 09, 2015, 7:34 PM UTC

mercurial wrote: post #81

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…

How is code with generics more complex than without it?

For example the C++ templates rules are themselves a turing-complete language. If by generics you meant some really basic features, I think you can do pretty well with interfaces. They're already in the language. If by generics you meant the full-package, i think you could end up with something pretty complex all the time.

Re: Why Go Is Not Good (2014)

#330

Post by spion » Wed, Dec 09, 2015, 7:35 PM UTC

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.

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 Futures / Tasks without generics.

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. The fact that JavaScript has loops that can be used instead, yet this is still the most popular JavaScript library cannot be reconciled otherwise than by acknowledging that generics are generally useful.

Its a damn shame that the language has such flaws: the standard library and tooling are superb. And just generics can single-handedly get rid of 80% of the problems of Go (errors can be modelled with a generic Result which forces you to check for error and allows chaining, generics would enable immutable data structures which are much safer for concurrent programming...)