Why Go Is Not Good • Hacker News Board

Re: Why Go Is Not Good

#291

Post by riwsky » Mon, Jun 30, 2014, 2:19 PM UTC

wyager wrote: post #117

mustpax wrote: post #113

Earlier quoted context omitted.

Exactly! Go makes the cost of generic code explicitly visible. Generics encourage over-generalizing behavior that runs counter to writing highly performant code. If you care about speed, you don't spend time making your code generic. You optimize closely to your use case.

>Go makes the cost of generic code explicitly visible. Generics encourage over-generalizing behavior that runs counter to writing highly performant code. I think you may be missing some info regarding generics in Rust and Haskell. As I mentioned in the article, there is zero runtime overhead for generic programming in Rust and Haskell. Zip. Zilch. Nada. That's why their constraint-based static generics system is awes…

Haskell's generic programming constructs do not have zero runtime overhead (at least on GHC, the dominant compiler). Typeclass-overloaded functions take an extra argument at runtime, in which the class "methods" are looked up. In particular, the typeclass-based definition of add3 turns into this Core code, which has an extra "$dNum_az0" arg to carry Num methods:

  ghci>let add3 a b c = a + b + c
  
  ==================== Simplified expression ====================
  GHC.Base.returnIO
    (GHC.Types.:
       ((\ (@ a_ayZ)
           ($dNum_az0 :: GHC.Num.Num a_ayZ)
           (a_ayG :: a_ayZ)
           (b_ayH :: a_ayZ)
           (c_ayI :: a_ayZ) ->
           GHC.Num.+ $dNum_az0 (GHC.Num.+ $dNum_az0 a_ayG b_ayH) c_ayI)
        `cast` ...)
       (GHC.Types.[]))

Compare this to the Int-specialized add3, which does not have to be passed the extra $dNum_az0 argument:

  ghci>let add3 a b c = a + b + c; add3 :: Int -> Int -> Int -> Int
  
  ==================== Simplified expression ====================
  GHC.Base.returnIO
    (GHC.Types.:
       ((\ (a_azj :: GHC.Types.Int)
           (b_azk :: GHC.Types.Int)
           (c_azl :: GHC.Types.Int) ->
           GHC.Num.+
             GHC.Num.$fNumInt (GHC.Num.+ GHC.Num.$fNumInt a_azj b_azk) c_azl)
        `cast` ...)
       (GHC.Types.[]))

Now, am I saying the the typeclass method isn't fast, or that GHC can't then optimize that Num dictionary away via specialization or inlining? No, I am not saying that. But it certainly doesn't always do that, resulting in a performance hit at runtime. More info @ http://www.haskell.org/haskellwiki/Performance/Overloading

Re: Why Go Is Not Good

#292

Post by gnuvince » Mon, Jun 30, 2014, 2:34 PM UTC

mustpax wrote: post #126

wyager wrote: post #117

Earlier quoted context omitted.

>Go makes the cost of generic code explicitly visible. Generics encourage over-generalizing behavior that runs counter to writing highly performant code. I think you may be missing some info regarding generics in Rust and Haskell. As I mentioned in the article, there is zero runtime overhead for generic programming in Rust and Haskell. Zip. Zilch. Nada. That's why their constraint-based static generics system is awes…

Lack of generics is part of the reason why Go is easier to learn and the Go compiler is faster than, say, Rust. Sure, generics don't have runtime overhead in Rust and Haskell but they have other costs. You always pay for abstractions some way.

The dmd compiler for D compiles faster than gc and yet supports compile-time templates.

Re: Why Go Is Not Good

#293

Post by igouy » Mon, Jun 30, 2014, 2:35 PM UTC

oscargrouch wrote: post #208

codygman wrote: post #204

Earlier quoted context omitted.

Picking something without a library will give an advantage to the other language in most cases because Haskell is very library based. I didn't cherry-pick btw, I just went to the first benchmark which included community-written snippets of both Go and Haskell I could think of. Cherry-picking would be me intentionally skipping over examples such as the one you provided and instead posting my example.

I´ve provided the links as a example of cherry-pick from my part.. showing that its easy to come with something that looks good.. FP tend to be more expressive, and make you feel more powerful.. but they also tend to be more complex and more verbose.. thats the price of power.. it's the trade of I think its not enough to show something simple, but with the real complexity hidden in some hidden layers.. Also if line o…

>>I´ve provided the links as a example of cherry-pickAnd they make curious examples of code-size when -- "Each program must implement 4 separate functions / procedures / methods like the C# program."

Re: Why Go Is Not Good

#294

Post by Rapzid » Mon, Jun 30, 2014, 2:44 PM UTC

personZ wrote: post #266

jeremyjh wrote: post #256

Earlier quoted context omitted.

It is fine to say you want a simple language, but then please do not talk up how great it is at concurrency. It lacks basic features common to every other language with a good concurrency story.

Go is absolutely fantastic at pragmatic, practical concurrency. In most real-world cases, that does not include a strong immutability base, for instance. Here's the thing about the "Go sucks because Haskell is the best language ever" retort: Haskell has been around for decades longer than Go. It has made essentially zero impact, and even for the case of many of those who use it as the "my big brother" comparison agai…

A very pragmatic response.

Re: Why Go Is Not Good

#295

Post by gclaramunt » Mon, Jun 30, 2014, 2:49 PM UTC

waps wrote: post #229

coldtea wrote: post #223

Earlier quoted context omitted.

> What I like about Go is the abstraction tools are primitive and allow for consistent & precise expression. Well, not really consistent. For example, try having a range loop for your own structures. Or something like make for them. And not really precise. The need for interface{} and type switches in idiomatic Go code throws preciseness out of the window.

They claim this is a feature, not a bug. It means that range will never block or do weird stuff. Except of course when it does (bastard question for those who think they know : what does range do on a nil channel ?) Despite all these clarity claims, go has significant pitfalls, like the nil channel above (and you will enounter nil channels). There's other things, like "what is a pointer in Go", if your answer involve…

I believe Go is "popular" because of Google, it might solve a particular internal problem for them, but for the rest of the world, they're better languages. To its credit, it makes Java look advanced, and that's no small feat!

Re: Why Go Is Not Good

#296

Post by jeremyjh » Mon, Jun 30, 2014, 2:49 PM UTC

personZ wrote: post #266

jeremyjh wrote: post #256

Earlier quoted context omitted.

It is fine to say you want a simple language, but then please do not talk up how great it is at concurrency. It lacks basic features common to every other language with a good concurrency story.

Go is absolutely fantastic at pragmatic, practical concurrency. In most real-world cases, that does not include a strong immutability base, for instance. Here's the thing about the "Go sucks because Haskell is the best language ever" retort: Haskell has been around for decades longer than Go. It has made essentially zero impact, and even for the case of many of those who use it as the "my big brother" comparison agai…

Haskell is one example; Clojure, Rust, Erlang, Scala are mainly the ones we think about in this category but even in Modern C++ code const is used quite a lot. Go is not yet very widely known or popular outside the HN bubble; I think it is a bit early for "daily driver" argument.

Re: Why Go Is Not Good

#297

Post by lazyjones » Mon, Jun 30, 2014, 2:52 PM UTC

codygman wrote: post #169

oscargrouch wrote: post #6

Go, Rust, Haskell, come from diffent ways of thinking about how to solve problems using programming languages.. Go aims to be more simple and concise, in the end you write less code to do the same thing, as you would in C++, Haskell or Rust.. because those 3 languages decided to "cover everything" and are worried about other things, creating more burden to the programmer, but with something else to gain Go is more of…

You made the claim that "in the end you write less code to do the same thing, as you would in C++, Haskell or Rust". Can you provide any examples where the Haskell equivalent isn't more concise than the Go equivalent? As a data point, here are links to the Haskell and Go implementations of the TechEmpower benchmarks: Haskell (78 sloc) https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... Go (164 sloc) https…

> As a data point, here are links to the Haskell and Go implementations of the TechEmpower benchmarks:

You can see from the messages in the code that these 2 programs do completely different things.

Re: Why Go Is Not Good

#298

Post by axaxs » Mon, Jun 30, 2014, 3:06 PM UTC

steveklabnik wrote: post #279

axaxs wrote: post #219

Earlier quoted context omitted.

I don't think it's bad, but to me(and only to me), disappointing. I'm a long time mozilla fan...heck a Netscape fan really. Go was a pleasure to learn, there were no 'gotchas' initially...just a small, easy to reason about language. Rust...with its arrows, angle brackets, pattern matching, etc. seemed just so complex to fit in my brain. I'd love to be proven wrong and try again, but the docs aren't the best. And I kn…

> the docs aren't the best. This week is week two of my being contracted by Mozilla to write docs full time. First up, a new tutorial. You can see my work from last week http://doc.rust-lang.org/guide.html , and my first task after I finish breakfast is to clean up https://github.com/rust-lang/rust/pull/15229 , which got some review over the weekend. So, you're right (at least about the docs) but I'm on it.

Steve - thanks for your reply and work on the docs. Is there currently a place - or will there be one, that describes precisely build/deployment options? This really in the end is the most important thing to me. I've searched unsuccessfully for this wrt Rust. It seems that as it sits, items built on a newer machine won't run on an older machine due to libc library mismatches. Will this always be a potential issue? Or will I be able to generate a single binary a la go?

Re: Why Go Is Not Good

#299

Post by wtetzner » Mon, Jun 30, 2014, 3:13 PM UTC

dbaupp wrote: post #261

wtetzner wrote: post #257

Earlier quoted context omitted.

> They are a tool to remove the need to call `free()` at the right time, with the downside that you don't get to control what the GC thinks is a right time instead. That's not actually true. They also allow you to do things that you otherwise couldn't. Try implementing persistent [1] maps or sets without a GC. [1] http://en.wikipedia.org/wiki/Persistent_data_structure

That's still just a problem of deciding when to call free.

Sort of. But you can't statically decide it. In fact, really the only way to do it is with a GC (or ref. counting, etc.). You can't know until runtime when a node will need to be freed.

And my point still stands. The GC allows you to do things you otherwise couldn't.

Re: Why Go Is Not Good

#300

Post by gnuvince » Mon, Jun 30, 2014, 3:15 PM UTC

personZ wrote: post #268

Daishiman wrote: post #173

Earlier quoted context omitted.

But the fact that Go proponents don't actually have solutions to those problems is an issue. How do you make a custom, generic data structure without syntax overhead? I have not seen any counter proposal to this aside from "maps should be enough for everybody". How do you avoid the noise from not having operator overloading or a similar alternative? This, again, goes unadressed. What are the succint alternatives to f…

How do you make a custom, generic data structure without syntax overhead? In real-world code, the need for generic data structures is shockingly uncommon. It really is. This requirement exaggeration comes about by people acting as language tourists, building amorphous code of uncertain purpose, where things like "I'm going to sum up a bunch of unknown objects" seems like a serious need. For most people who find Go to…

Notice how you're not giving an answer to Daishiman's question, merely downplaying the importance of having general data structures, though I'm sure you're quite happy that slices, maps and channels can be parametrized by the type of data they contain. Saying that general data structures are uncommon in the "real world" sounds like an example of Sapir-Whorf. I use Java at work and OCaml for a personal project and in both of them, having data structures that can be parametrized is very helpful. For instance, writing an AST with a type parameter allows to go from a AST (generated by the parser) where ids are strings to a AST where a node's id is now a symbol (generated during semantic analysis).