Re:Another go at Go failed
by coldtea on Wednesday January 08, 2014 @06:35PM
(#7027659)
>I think there is more to learn here about engineering mistakes than about Go: Why pick Go for this project in the first place?
I hate this type of non-productive comment.
"Why he picked Go" is beside the point. That was his personal choice, and it's of no concern to us if it was a good or bad choice when he made it.
What IS of interest to us, is his findings, ie. about how (non) fitting was Go for the kind of work he describes, and for what reasons. Because that can helps us access the language ourselves for such uses.
>Those days the biggest productivity difference that arises from language choice comes from the availability of libraries
Again, not true for his needs. For what he needed, core library built-ins have sufficed in Java (Set etc). As for Go, he did find 2 libraries implementing them, but he still wished for a good core implementation.
>The bit on poor performance is unconvincing because the source of the difference has not been identified.
No, but it's well known that Go lags behind the JVM, something even the Go team aknowledges and attributes to maturity of the compiler/GC.
Plus, from the writeup, he sounds like a thoroughly decent programer to not be able to code his way out of Go performance bottlenecks. Doesn't sound like the guy who can't use a profiler (and in fact, he points in his article that he DID use one).
>This kind of "magical" thinking about black boxes one doesn't understand is unfortunately all too common across software engineering.
I hate this type of non-productive comment.
"Why he picked Go" is beside the point. That was his personal choice, and it's of no concern to us if it was a good or bad choice when he made it.
What IS of interest to us, is his findings, ie. about how (non) fitting was Go for the kind of work he describes, and for what reasons. Because that can helps us access the language ourselves for such uses.
>Those days the biggest productivity difference that arises from language choice comes from the availability of libraries
Again, not true for his needs. For what he needed, core library built-ins have sufficed in Java (Set etc). As for Go, he did find 2 libraries implementing them, but he still wished for a good core implementation.
>The bit on poor performance is unconvincing because the source of the difference has not been identified.
No, but it's well known that Go lags behind the JVM, something even the Go team aknowledges and attributes to maturity of the compiler/GC.
Plus, from the writeup, he sounds like a thoroughly decent programer to not be able to code his way out of Go performance bottlenecks. Doesn't sound like the guy who can't use a profiler (and in fact, he points in his article that he DID use one).
>This kind of "magical" thinking about black boxes one doesn't understand is unfortunately all too common across software engineering.
Random rant unrelated to TFA.