Why Go Is Not Good

Re:Why Go Is Not Good by codygman on Sunday June 29, 2014 @11:19PM (#7963529)

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://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

[ Parent | on HN ]

Re:Why Go Is Not Good by oscargrouch on Monday June 30, 2014 @12:07AM (#7963652)

Anyone can encapsulate or "hide" the inner workings so the resulting code will look small.. how much of that code in the frontend is already implemented in the standard library of each language??

To see the reality of it.. a better example would be something without any support library...

Cherry picking is easy..

From the same benchmarks Game:

spectral-norm - Go

http://benchmarksgame.alioth.debian.org/u64/program.php?test...

spectral-norm - Haskell

http://benchmarksgame.alioth.debian.org/u64/program.php?test...

[ Parent | on HN ]

Re:Why Go Is Not Good by codygman on Monday June 30, 2014 @12:58AM (#7963759)

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.

[ Parent | on HN ]

Re:Why Go Is Not Good by oscargrouch on Monday June 30, 2014 @01:32AM (#7963800)

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 of code is the measure of simplicity the Brainfuck language would win everything.. but it doesnt mean you can read what the code express with less effort..

Nothing against Haskell in particular, only that it doesnt shine when the matter is simplicity..

Expressiveness.. Abstraction power.. shure.... but that was not the original point i was making in the original article

[ Parent | on HN ]

Re:Why Go Is Not Good by igouy on Monday June 30, 2014 @10:35AM (#7965235)

>>I´ve provided the links as a example of cherry-pick<<

And they make curious examples of code-size when -- "Each program must implement 4 separate functions / procedures / methods like the C# program."

[ Parent | on HN ]

Re:Why Go Is Not Good by lazyjones on Monday June 30, 2014 @10:52AM (#7965332)

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

[ Parent | on HN ]