5 ms·

Option A: -Write your application in Go Option B: -Write application in Ruby -Profile Ruby application to identify code to be rewritten in C -Learn C

by frehpt 13y ago

Option A: -Write your application in Go Option B: -Write application in Ruby -Profile Ruby application to identify code to be rewritten in C -Learn C if you don't already know it -Rewrite various parts of your application in C -Run Valgrind to search for memleaks -Ensure that your target systems all have required libs installed Option A seems much simpler...

threeseed 13y ago
Go does't have 1/100000 the amount of libraries and support that Ruby or C does. Option A only seems simpler because you ignore the time/complexity in coding the task at hand.
- jthol 13y ago
  ... and the Java programmer laughs in the corner (Let's not talk about generics though).
  - vidarh 13y ago
    ... of the asylum he's been committed to after having to deal with one too many AbstractFactoryFactory classes.
    - mitchi 13y ago
      That's Design Patterns code. I'm sure that if I start programming seriously in Java, I can bring all the readability of C with me!
- kgabis 13y ago
  Why not 1/10e100? Or even less? Go's library support is quite nice already and it's growing really fast.
  - threeseed 13y ago
    Because I am being realistic. Ruby, C, Java etc have had decades to build a comprehensive set of developer libraries. Go hasn't. It's a "cute" platform that I am sure will beat Ruby in a few benchmarks. But I don't see any reason why anyone would seriously consider it for a real world app.
    - JulianMorrison 13y ago
      Ruby has a sprawling ecosystem of libraries largely drawn into being by Rails (itself a sprawl) and by design decisions in Ruby's core and stdlib that complicate things and need further code to work around. Threads and fibers and events, oh my. Each workaround has its own ecosystem. You could even consider things like rack and unicorn workarounds for the weak implementations in stdlib. I don't think Ruby's libraries honestly provide a whole lot better coverage than Go. The stdlib is very well considered. It's fast, it scales, it's thread safe in the appropriate places. It's not a toy implementation. What it doesn't provide, it provides hooks for. Third party libs cover all the major bases. And unlike Ruby, writing interfacing code in Go is a snip. I don't see libraries as a downside. (With one exception. Why oh why did they not include a bigdecimal? Argh, a ratio type is not an adequate replacement. Try rounding a ratio some time. Blarg.)
    - yasth 13y ago
      Well for one Go beats Ruby in every benchmark that I am aware of, and generally by quite some distance. Also realistically 60-70% of all libraries created for other languages are bitrotted to junk or pointlessness by this point. If you can't see why an app that fits within the worked problemspace of Go (and even with the current libraries plenty of things are wholly doable in Go) and will require much less server resources might be a good fit, then you shouldn't be making those decisions, because that is the thought pattern of a zealot. Look Ruby is well supported, established, and proven, but it is also slow. For a lot of things that is fine, but if you are dealing with something that requires a lot of serverside work on low margins it will kill you dead. Horses for courses.
      - vidarh 13y ago
- frehpt 13y ago
  > Go does't have 1/100000 the amount of libraries and support that Ruby or C does. That's what they used to say about Java...
  - threeseed 13y ago
    Yes. Nearly 20 years ago. But don't worry the JVM can save you. http://code.google.com/p/jgo/ http://code.google.com/p/jgo/
awj 13y ago
Sure it does, right up until you also need libraries that Ruby has but Go doesn't. Also you're trading away a few language features to get Go, so between the two you're tossing a lot of programmer time out the door to avoid writing in C. Maybe that's still a worthwhile trade, but it's not really a simple one.
- papsosouid 13y ago
  >Sure it does, right up until you also need libraries that Ruby has but Go doesn't. Now replace go with ruby and ruby with perl. Go has libraries for 99% of what people are doing with ruby. If you are in that 1%, then you need to evaluate whether or not it is worth writing the library you need or if you should use another language.
  - awj 13y ago
    A quick check led to me not finding a package manager for Go similar to RubyGems. Does it have one? Manually installing dependencies is a colossal waste of time.
    - papsosouid 13y ago
      It is just go. Do a "go build foo" or "go install foo" and it will handle any dependencies for foo on its own. Do a "go get bar" and it will download and install bar and anything it depends on.
      - awj 13y ago
        Where are these packages published? Can I install things from this page[1] in that way? At least from 1000 feet away, it seems like Ruby has this problem solved better than Go does. Maybe it's just that the nature of the solution is more apparent. [1] https://code.google.com/p/go-wiki/wiki/Projects https://code.google.com/p/go-wiki/wiki/Projects
        papsosouid 13y ago
nfm 13y ago
That's a ridiculous set of alternatives.
- reactor 13y ago
  It's not.
- espadrine 13y ago
  The bottom line is: the time necessary to optimize Ruby to run below 8 minutes was bigger than he could afford, and apparently Go, once written (which apparently gave the OP some issues) needn't be optimized. That said, Go wasn't necessarily the better choice, because of the subtlety that made the Go program overflow silently. Writing the solution in Scala or even in JS would have probably given him less of an issue.

by frehpt 13y ago

threeseed 13y ago

Go does't have 1/100000 the amount of libraries and support that Ruby or C does. Option A only seems simpler because you ignore the time/complexity in coding the task at hand.

jthol 13y ago
... and the Java programmer laughs in the corner (Let's not talk about generics though).
- vidarh 13y ago
  ... of the asylum he's been committed to after having to deal with one too many AbstractFactoryFactory classes.
  - mitchi 13y ago
    That's Design Patterns code. I'm sure that if I start programming seriously in Java, I can bring all the readability of C with me!
kgabis 13y ago
Why not 1/10e100? Or even less? Go's library support is quite nice already and it's growing really fast.
- threeseed 13y ago
  Because I am being realistic. Ruby, C, Java etc have had decades to build a comprehensive set of developer libraries. Go hasn't. It's a "cute" platform that I am sure will beat Ruby in a few benchmarks. But I don't see any reason why anyone would seriously consider it for a real world app.
  - JulianMorrison 13y ago
    Ruby has a sprawling ecosystem of libraries largely drawn into being by Rails (itself a sprawl) and by design decisions in Ruby's core and stdlib that complicate things and need further code to work around. Threads and fibers and events, oh my. Each workaround has its own ecosystem. You could even consider things like rack and unicorn workarounds for the weak implementations in stdlib. I don't think Ruby's libraries honestly provide a whole lot better coverage than Go. The stdlib is very well considered. It's fast, it scales, it's thread safe in the appropriate places. It's not a toy implementation. What it doesn't provide, it provides hooks for. Third party libs cover all the major bases. And unlike Ruby, writing interfacing code in Go is a snip. I don't see libraries as a downside. (With one exception. Why oh why did they not include a bigdecimal? Argh, a ratio type is not an adequate replacement. Try rounding a ratio some time. Blarg.)
  - yasth 13y ago
    Well for one Go beats Ruby in every benchmark that I am aware of, and generally by quite some distance. Also realistically 60-70% of all libraries created for other languages are bitrotted to junk or pointlessness by this point. If you can't see why an app that fits within the worked problemspace of Go (and even with the current libraries plenty of things are wholly doable in Go) and will require much less server resources might be a good fit, then you shouldn't be making those decisions, because that is the thought pattern of a zealot. Look Ruby is well supported, established, and proven, but it is also slow. For a lot of things that is fine, but if you are dealing with something that requires a lot of serverside work on low margins it will kill you dead. Horses for courses.
    - vidarh 13y ago
frehpt 13y ago
> Go does't have 1/100000 the amount of libraries and support that Ruby or C does. That's what they used to say about Java...
- threeseed 13y ago
  Yes. Nearly 20 years ago. But don't worry the JVM can save you. http://code.google.com/p/jgo/ http://code.google.com/p/jgo/

awj 13y ago

Sure it does, right up until you also need libraries that Ruby has but Go doesn't. Also you're trading away a few language features to get Go, so between the two you're tossing a lot of programmer time out the door to avoid writing in C. Maybe that's still a worthwhile trade, but it's not really a simple one.

papsosouid 13y ago
>Sure it does, right up until you also need libraries that Ruby has but Go doesn't. Now replace go with ruby and ruby with perl. Go has libraries for 99% of what people are doing with ruby. If you are in that 1%, then you need to evaluate whether or not it is worth writing the library you need or if you should use another language.
- awj 13y ago
  A quick check led to me not finding a package manager for Go similar to RubyGems. Does it have one? Manually installing dependencies is a colossal waste of time.
  - papsosouid 13y ago
    It is just go. Do a "go build foo" or "go install foo" and it will handle any dependencies for foo on its own. Do a "go get bar" and it will download and install bar and anything it depends on.
    - awj 13y ago
      Where are these packages published? Can I install things from this page[1] in that way? At least from 1000 feet away, it seems like Ruby has this problem solved better than Go does. Maybe it's just that the nature of the solution is more apparent. [1] https://code.google.com/p/go-wiki/wiki/Projects https://code.google.com/p/go-wiki/wiki/Projects
      - papsosouid 13y ago

nfm 13y ago

That's a ridiculous set of alternatives.

reactor 13y ago
It's not.
espadrine 13y ago
The bottom line is: the time necessary to optimize Ruby to run below 8 minutes was bigger than he could afford, and apparently Go, once written (which apparently gave the OP some issues) needn't be optimized. That said, Go wasn't necessarily the better choice, because of the subtlety that made the Go program overflow silently. Writing the solution in Scala or even in JS would have probably given him less of an issue.