13 ms·

I think there is more to learn here about engineering mistakes than about Go: - Why pick Go for this project in the first place? Those days the biggest product

by stiff 13y ago

I think there is more to learn here about engineering mistakes than about Go: - Why pick Go for this project in the first place? Those days the biggest productivity difference that arises from language choice comes from the availability of libraries, and it does not take much research to see that Go wasn't particularly targeted at numeric computing and that library support for those kinds of things is very poor. There is a number of mature platforms for this class of problems, SciPy, MatLab/Octave, C/C++ with various BLAS-derived libraries etc. - The bit on poor performance is unconvincing because the source of the difference has not been identified. The speculations about Go and Java that follow are so poorly backed by any evidence and so wild they should have been cut out from the article. It's clear that the author has no clue what really happens in either case, and he proceeds to draw conclusions anyway. This kind of "magical" thinking about black boxes one doesn't understand is unfortunately all too common across software engineering. - One place where I agree with the author is that Go's zoo of builtin data structures is really, really poor compared to Java. I mean compare: http://golang.org/pkg/container/ http://golang.org/pkg/container/ http://docs.oracle.com/javase/tutorial/collections/interfaces/index.html http://docs.oracle.com/javase/tutorial/collections/interface... http://docs.oracle.com/javase/tutorial/collections/implementations/index.html http://docs.oracle.com/javase/tutorial/collections/implement...

pron 13y ago
... and those don't even include Java's long list of concurrent collections.
- jwn 13y ago
  Or the other Collection implementations offered by https://code.google.com/p/guava-libraries/ https://code.google.com/p/guava-libraries/.
  - jbooth 13y ago
    Or the ability to write collections in the first place, as enabled by generics. You can't even write a collection in Go unless you're dealing with interface{} or unsafe.Pointer and casting a lot. I really like the language, enough to use it and work around the lack of generics, but that's a glaring weakness. They need some way to enable container classes.
- pjmlp 13y ago
  ... and the concurrent libraries of futures, fork-join, tasks
  - sixthloginorso 13y ago
    Java's concurrency primitives and libraries are really overlooked in these discussions. Is the syntax too off-putting, or is it merely that Java is unfashionable?
    - RyanZAG 13y ago
      Very much unfashionable for the HN crowd. Most of the new research in concurrency is happening in Java and funded by the high performance trading industry - an industry which is very far from the HN crowd. The new Java8 stampedlock is a good example. It's possible to implement it in C++ as well, but because of the guarantees required by the lock it is a very difficult lock to integrate into C++ code. On the other hand, the JRE guarantees the correct constraints for Java code making a stampedlock very easy to use [1]. The performance of a stampedlock also seems to be the best case for any multi-reader environment. [2] [1] http://concurrencyfreaks.blogspot.com/2013/11/stampedlocktryoptimisticread-and.html http://concurrencyfreaks.blogspot.com/2013/11/stampedlocktry... [2] http://mechanical-sympathy.blogspot.ca/2013/08/lock-based-vs-lock-free-concurrent.html http://mechanical-sympathy.blogspot.ca/2013/08/lock-based-vs...
      - scott_s 13y ago
        I find your claim that most new research in concurrency happens in Java strange. Perhaps you are unfamiliar with academic research in concurrency and parallelism? A way to get a small taste is to look at recent papers from the conference Practice and Principles of Parallel Programming (PPoPP).
      - Iftheshoefits 13y ago
        If Java is involved, it's more likely they're interested in cutting developer costs than doing any "new research." That isn't to say they aren't doing any "new research," or that the research quality is poor, or anything negative at all, really. It's just a restatement of the observation that the labor market for Java developers is quite different from C developers or C++ developers (there are a lot more of the former than of the latter--a lot more).
- ansible 13y ago
  With Go, the programmer will typically not be using data structures that are concurrently accessed from multiple goroutines. It is considered more idiomatic to have one goroutine controlling a given data structure, and have the others communicate with it via channels.
  - pron 13y ago
    That approach has vastly different performance characteristics.
  - jamra 13y ago
    That is only one way of doing things. Even though channels facilitate that method, it is not unidiomatic to not use them. Channels are a way of queueing work, which is great for many use cases. You can use mutexes and shared memory if your situation calls for it. For example, if I am doing a graph traversal concurrently, I can use channels to send the work to many listening threads as I traverse that graph synchronously. If for some reason, I need to update that graph's representation asynchronously, I may need to use mutexes to lock the graph since the graph is now shared memory.
redbad 13y ago
> Go's zoo of builtin data structures is really, really > poor compared to Java. This is a poor comparison because idiomatic Go typically doesn't use the `container` package.
jamra 13y ago
This reminds me of that one guy on the go-nuts irc channel who asked for help with his Ruby port over to Go. He was scraping a set of web pages in Ruby and migrated that over to Go for its easy parallelization. His claim was that Go was 3x slower in speed. He pasted some code that seemed fine, but left out the context of what he was doing. At the end of the day, it as just an attempt to claim that Ruby is faster than Go. If he doesn't provide the entire context with benchmarks included, I'm just taking his word for it. On another note, I built an algorithm using a bitset. At first, I used one of the libraries the author linked, but then I saw that it was easier to just do the bit-bashing myself for my particular use case. It's not that difficult if you are familiar with C and C++ programming. If, however, you are coming over from a language like Python, Ruby, and even Java to criticize Go is an easy thing to do. Those are very high level languages that protect you from needing to understand types. The object oriented parts of Java languages give you the ability to use polymorphism, which is not as straight forward in Go. You don't have a common base class. You only have interfaces. Trying to recreate generic structures and then blame the language for not having them is foolish. If you can't program without generics, stick with Java from the beginning. Or better yet, don't do a project in Go until you understand how to approach problems the Go way. I happen to like Go for the very reason that you don't deal with generics. Seeing the types make it easier for me to follow as opposed to following a chain of inheritance. Getting rid of all the factory code trims my code down. This makes things easier to read when you are not the author. Comparing Java's compiler to any other compiler is going to have predictable results. Java may have the best compiler out there.
- GhotiFish 13y ago
  It's hard to imagine someone seriously arguing ruby is, in general, more performant than go. I think that person was just frustrated.
- pcwalton 13y ago
  Generics, inheritance, and the factory pattern are completely orthogonal features. Adding generics would not entail adding inheritance, mandating the factory pattern, or any other slippery slope feature.
cosn 13y ago
I wrote most of those already, if anyone needs them, help yourself. Haven't had the need for a bit set, but I guess I can add it to the TODO list :) https://github.com/cosn/collections/ https://github.com/cosn/collections/ That being said, I completely agree that the author chose the wrong language for the problem at hand.
coldtea 13y ago
>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. Random rant unrelated to TFA.

by stiff 13y ago

pron 13y ago

... and those don't even include Java's long list of concurrent collections.

jwn 13y ago
Or the other Collection implementations offered by https://code.google.com/p/guava-libraries/ https://code.google.com/p/guava-libraries/.
- jbooth 13y ago
  Or the ability to write collections in the first place, as enabled by generics. You can't even write a collection in Go unless you're dealing with interface{} or unsafe.Pointer and casting a lot. I really like the language, enough to use it and work around the lack of generics, but that's a glaring weakness. They need some way to enable container classes.
pjmlp 13y ago
... and the concurrent libraries of futures, fork-join, tasks
- sixthloginorso 13y ago
  Java's concurrency primitives and libraries are really overlooked in these discussions. Is the syntax too off-putting, or is it merely that Java is unfashionable?
  - RyanZAG 13y ago
    Very much unfashionable for the HN crowd. Most of the new research in concurrency is happening in Java and funded by the high performance trading industry - an industry which is very far from the HN crowd. The new Java8 stampedlock is a good example. It's possible to implement it in C++ as well, but because of the guarantees required by the lock it is a very difficult lock to integrate into C++ code. On the other hand, the JRE guarantees the correct constraints for Java code making a stampedlock very easy to use [1]. The performance of a stampedlock also seems to be the best case for any multi-reader environment. [2] [1] http://concurrencyfreaks.blogspot.com/2013/11/stampedlocktryoptimisticread-and.html http://concurrencyfreaks.blogspot.com/2013/11/stampedlocktry... [2] http://mechanical-sympathy.blogspot.ca/2013/08/lock-based-vs-lock-free-concurrent.html http://mechanical-sympathy.blogspot.ca/2013/08/lock-based-vs...
    - scott_s 13y ago
      I find your claim that most new research in concurrency happens in Java strange. Perhaps you are unfamiliar with academic research in concurrency and parallelism? A way to get a small taste is to look at recent papers from the conference Practice and Principles of Parallel Programming (PPoPP).
    - Iftheshoefits 13y ago
      If Java is involved, it's more likely they're interested in cutting developer costs than doing any "new research." That isn't to say they aren't doing any "new research," or that the research quality is poor, or anything negative at all, really. It's just a restatement of the observation that the labor market for Java developers is quite different from C developers or C++ developers (there are a lot more of the former than of the latter--a lot more).
ansible 13y ago
With Go, the programmer will typically not be using data structures that are concurrently accessed from multiple goroutines. It is considered more idiomatic to have one goroutine controlling a given data structure, and have the others communicate with it via channels.
- pron 13y ago
  That approach has vastly different performance characteristics.
- jamra 13y ago
  That is only one way of doing things. Even though channels facilitate that method, it is not unidiomatic to not use them. Channels are a way of queueing work, which is great for many use cases. You can use mutexes and shared memory if your situation calls for it. For example, if I am doing a graph traversal concurrently, I can use channels to send the work to many listening threads as I traverse that graph synchronously. If for some reason, I need to update that graph's representation asynchronously, I may need to use mutexes to lock the graph since the graph is now shared memory.

redbad 13y ago

> Go's zoo of builtin data structures is really, really > poor compared to Java. This is a poor comparison because idiomatic Go typically doesn't use the `container` package.

jamra 13y ago

This reminds me of that one guy on the go-nuts irc channel who asked for help with his Ruby port over to Go. He was scraping a set of web pages in Ruby and migrated that over to Go for its easy parallelization. His claim was that Go was 3x slower in speed. He pasted some code that seemed fine, but left out the context of what he was doing. At the end of the day, it as just an attempt to claim that Ruby is faster than Go. If he doesn't provide the entire context with benchmarks included, I'm just taking his word for it. On another note, I built an algorithm using a bitset. At first, I used one of the libraries the author linked, but then I saw that it was easier to just do the bit-bashing myself for my particular use case. It's not that difficult if you are familiar with C and C++ programming. If, however, you are coming over from a language like Python, Ruby, and even Java to criticize Go is an easy thing to do. Those are very high level languages that protect you from needing to understand types. The object oriented parts of Java languages give you the ability to use polymorphism, which is not as straight forward in Go. You don't have a common base class. You only have interfaces. Trying to recreate generic structures and then blame the language for not having them is foolish. If you can't program without generics, stick with Java from the beginning. Or better yet, don't do a project in Go until you understand how to approach problems the Go way. I happen to like Go for the very reason that you don't deal with generics. Seeing the types make it easier for me to follow as opposed to following a chain of inheritance. Getting rid of all the factory code trims my code down. This makes things easier to read when you are not the author. Comparing Java's compiler to any other compiler is going to have predictable results. Java may have the best compiler out there.

GhotiFish 13y ago
It's hard to imagine someone seriously arguing ruby is, in general, more performant than go. I think that person was just frustrated.
pcwalton 13y ago
Generics, inheritance, and the factory pattern are completely orthogonal features. Adding generics would not entail adding inheritance, mandating the factory pattern, or any other slippery slope feature.

cosn 13y ago

I wrote most of those already, if anyone needs them, help yourself. Haven't had the need for a bit set, but I guess I can add it to the TODO list :) https://github.com/cosn/collections/ https://github.com/cosn/collections/ That being said, I completely agree that the author chose the wrong language for the problem at hand.

coldtea 13y ago

>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. Random rant unrelated to TFA.