4 ms·

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 migr

by 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.
- stcredzero 13y ago
  Most of Go's feature decisions seem to have something to do with compilation speed or how it fits in with the concurrency features and GC. Inheritance is overrated, and the factory pattern is often overused. Both of those happen with generics.
  - pcwalton 13y ago
    > Inheritance is overrated, and the factory pattern is often overused. Both of those happen with generics. Generics have nothing to do with inheritance and the factory pattern. There are lots of languages that have generics but neither inheritance neither factories: SML, OCaml, Haskell, etc. Inheritance makes generics harder, in fact, because type inference becomes undecidable in the general case. Factories are basically a workaround for functions not being able to be freestanding (unattached to a class) in Java (the "kingdom of nouns"), a problem that Go doesn't have.
    - stcredzero 13y ago
      Generics have nothing to do with inheritance and the factory pattern. Where do I say such a thing? I'm saying that generics are both overrated and overused. Factories are basically a workaround for functions not being able to be freestanding (unattached to a class) in Java (the "kingdom of nouns"), a problem that Go doesn't have. Being the "Kingdom of Nouns" is kinda the point of Smalltalk/Objective-C style OO. (Though Alan Kay once famously said that when he thought of OO, he was not thinking of Java.) That said, while it is nice to have someplace to put functions, there are times when it's also nice not to be forced to attach them to a class. Not so sure it's a problem as much as it's just a particular approach with its advantages and drawbacks. Where do you get that Factories are "a workaround for functions not being able to be freestanding?"
      - cstrahan 13y ago
        >> Generics have nothing to do with inheritance and the factory pattern. > Where do I say such a thing? I'm saying that generics are both overrated and overused. It looks like that's what you're suggesting here: > Inheritance is overrated, and the factory pattern is often overused. Both of those happen with generics. --- > Where do you get that Factories are "a workaround for functions not being able to be freestanding?" A factory is, conceptually, a function of some set of inputs that returns a new instance - which is, of course, exactly what a constructor is. Now, it's not always appropriate for a class to know every single way in which it might be assembled, so such responsibility is usually lifted out - the question is where to put it. We already have constructors, and those are functions, so it would seem reasonable that we could just write method similar to a constructor, place it in some other namespace (perhaps in a completely different package/module), and then pass that along to the component that needs to create these new instances. For languages like Java, the problem is that functions are not first class - you can't directly pass along a method/function like (Conf -> SomeService), so instead, it's common to create some special type, like SomeServiceFactory. If, for comparison, you take a look at Scala/Haskell/C#/etc, you'll wont often spot /.*Factory/ anywhere, because a function (with the ability to close over free variables) is much more concise, and doesn't require defining new types (e.g. SomeServiceFactory, versus Function<Conf,SomeService>). I think that, seen in this light, the practice of defining dedicated factory classes is a rather clumsy approach necessitated by the design of the underlying language.
falcolas 13y ago
If you generate a lot of goroutines, the overhead for maintaining and scheduling them is fairly significant, particularly when compared to constructs like Python generators. I've demonstrated this myself by comparing the goroutines example prime number generator to a similar version written using Python generators. The python generator code was faster, but there was a hard limit to how many primes could be calculated this way; I hit the stack limit. [Edit] Code & times: http://pastebin.com/CqkMcxdK http://pastebin.com/CqkMcxdK
asdasf 13y ago
This notion that having a huge gaping defect is just a different way of doing things is absurd. Lacking parametric polymorphism is completely unacceptable. This is a solved problem as of 1973. There is no excuse. Inheritance has nothing to do with it, and "all the factory code" has even less to do with it. You are saying "I like go because it isn't java", which is fine, but you are implying that being java is necessary to have parametric polymorphism, which is not at all accurate.
- jamra 13y ago
  I like go because it's not object oriented. This forces me to read the implementation of the algorithm, not follow an abstraction hierarchy. I like Java as well. It can be difficult to read the implementation when you are surrounded with classes. That was the point I was trying to make. If you are thinking in generic containers and are programming in Go, you either chose the wrong language or need to change how you are thinking.
  - asdasf 13y ago
    >I like go because it's not object oriented Lots of languages are not object oriented and still have parametic polymorphism. Like SML. In 1973. >If you are thinking in generic containers and are programming in Go, you either chose the wrong language or need to change how you are thinking. If you are repeating the same baseless assertion routed in ignorance, then you either chose the wrong forum, or need to change how you are thinking.
coldtea 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. Yes, with the exception of that being a story about some random idiot with an axe to grind, and this being a totally competent guy, that goes into detail about what he did and how, what trouble spots he found etc. I guess, it being a hired project, he can't share the actual code. But he provided tons of pain points, well articulated.
- jamra 13y ago
  The problem is that he makes a bold statement about Go's performance without proof or at least stating what the problem in Go was.

by jamra 13y ago

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.

stcredzero 13y ago
Most of Go's feature decisions seem to have something to do with compilation speed or how it fits in with the concurrency features and GC. Inheritance is overrated, and the factory pattern is often overused. Both of those happen with generics.
- pcwalton 13y ago
  > Inheritance is overrated, and the factory pattern is often overused. Both of those happen with generics. Generics have nothing to do with inheritance and the factory pattern. There are lots of languages that have generics but neither inheritance neither factories: SML, OCaml, Haskell, etc. Inheritance makes generics harder, in fact, because type inference becomes undecidable in the general case. Factories are basically a workaround for functions not being able to be freestanding (unattached to a class) in Java (the "kingdom of nouns"), a problem that Go doesn't have.
  - stcredzero 13y ago
    Generics have nothing to do with inheritance and the factory pattern. Where do I say such a thing? I'm saying that generics are both overrated and overused. Factories are basically a workaround for functions not being able to be freestanding (unattached to a class) in Java (the "kingdom of nouns"), a problem that Go doesn't have. Being the "Kingdom of Nouns" is kinda the point of Smalltalk/Objective-C style OO. (Though Alan Kay once famously said that when he thought of OO, he was not thinking of Java.) That said, while it is nice to have someplace to put functions, there are times when it's also nice not to be forced to attach them to a class. Not so sure it's a problem as much as it's just a particular approach with its advantages and drawbacks. Where do you get that Factories are "a workaround for functions not being able to be freestanding?"
    - cstrahan 13y ago
      >> Generics have nothing to do with inheritance and the factory pattern. > Where do I say such a thing? I'm saying that generics are both overrated and overused. It looks like that's what you're suggesting here: > Inheritance is overrated, and the factory pattern is often overused. Both of those happen with generics. --- > Where do you get that Factories are "a workaround for functions not being able to be freestanding?" A factory is, conceptually, a function of some set of inputs that returns a new instance - which is, of course, exactly what a constructor is. Now, it's not always appropriate for a class to know every single way in which it might be assembled, so such responsibility is usually lifted out - the question is where to put it. We already have constructors, and those are functions, so it would seem reasonable that we could just write method similar to a constructor, place it in some other namespace (perhaps in a completely different package/module), and then pass that along to the component that needs to create these new instances. For languages like Java, the problem is that functions are not first class - you can't directly pass along a method/function like (Conf -> SomeService), so instead, it's common to create some special type, like SomeServiceFactory. If, for comparison, you take a look at Scala/Haskell/C#/etc, you'll wont often spot /.*Factory/ anywhere, because a function (with the ability to close over free variables) is much more concise, and doesn't require defining new types (e.g. SomeServiceFactory, versus Function<Conf,SomeService>). I think that, seen in this light, the practice of defining dedicated factory classes is a rather clumsy approach necessitated by the design of the underlying language.

falcolas 13y ago

If you generate a lot of goroutines, the overhead for maintaining and scheduling them is fairly significant, particularly when compared to constructs like Python generators. I've demonstrated this myself by comparing the goroutines example prime number generator to a similar version written using Python generators. The python generator code was faster, but there was a hard limit to how many primes could be calculated this way; I hit the stack limit. [Edit] Code & times: http://pastebin.com/CqkMcxdK http://pastebin.com/CqkMcxdK

asdasf 13y ago

This notion that having a huge gaping defect is just a different way of doing things is absurd. Lacking parametric polymorphism is completely unacceptable. This is a solved problem as of 1973. There is no excuse. Inheritance has nothing to do with it, and "all the factory code" has even less to do with it. You are saying "I like go because it isn't java", which is fine, but you are implying that being java is necessary to have parametric polymorphism, which is not at all accurate.

jamra 13y ago
I like go because it's not object oriented. This forces me to read the implementation of the algorithm, not follow an abstraction hierarchy. I like Java as well. It can be difficult to read the implementation when you are surrounded with classes. That was the point I was trying to make. If you are thinking in generic containers and are programming in Go, you either chose the wrong language or need to change how you are thinking.
- asdasf 13y ago
  >I like go because it's not object oriented Lots of languages are not object oriented and still have parametic polymorphism. Like SML. In 1973. >If you are thinking in generic containers and are programming in Go, you either chose the wrong language or need to change how you are thinking. If you are repeating the same baseless assertion routed in ignorance, then you either chose the wrong forum, or need to change how you are thinking.

coldtea 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. Yes, with the exception of that being a story about some random idiot with an axe to grind, and this being a totally competent guy, that goes into detail about what he did and how, what trouble spots he found etc. I guess, it being a hired project, he can't share the actual code. But he provided tons of pain points, well articulated.

jamra 13y ago
The problem is that he makes a bold statement about Go's performance without proof or at least stating what the problem in Go was.