4 ms·

> But we have technology needs that aren’t going to always be well served by Ruby What are some examples? I'll start with heavy number crunching (Go/C) and br

by eik3_de 12y ago

> But we have technology needs that aren’t going to always be well served by Ruby What are some examples? I'll start with heavy number crunching (Go/C) and browser-based apps (JS)

gphil 12y ago
Concurrency (Clojure, Erlang)
- MoOmer 12y ago
  Not MRI, but JRuby + http://akka.io/ http://akka.io/ There are also some great gems like Celluloid to help. That said, it's not the same as built-in concurrency.
scottefein12 12y ago
If you need a lightening fast API, anecdotal evidence suggests you just can't get it down to the speeds you see with Go. Rack/Ruby just isn't going to cut it.
- programminggeek 12y ago
  You can get close if you don't use Rails. Seriously, Cuba + JRuby + Torquebox 4 is fast, nearly as fast as Go. http://madebymarket.com/blog/dev/ruby-web-benchmark-report.html http://madebymarket.com/blog/dev/ruby-web-benchmark-report.h...
  - jshen 12y ago
    I'm sorry, a hello world benchmark is meaningless.
    - MrBra 12y ago
      For concurrency-testing-alone it might be not. If it works good at it, then it's a good indication that the concurrency model implemented in the language is not flawed and if there is a problem, then it might be somewhere else in the language. So that benchmark it's still valuable information in the sense that tells you that that particular language running on that particular runtime its not intrinsically bad at concurrency. In this particular case (JRuby) moreover, the language gets its concurrency layer thanks to Java, so I'd go really easy with that, unless you really want to say that Java is bad at concurrency or that this is not known and thus a "Hello World" example would not show it. Which are both wrongly proven statements. Nonetheless I must admit though that some of those combinations of runtime/server/frameworks are admittedly unstable to replicate or to work with in a real scenario.
chimeracoder 12y ago
> I'll start with heavy number crunching (Go/C) and browser-based apps (JS) Be careful to distinguish between the language and a particular implementation or runtime environment. Go, for example, runs perfectly well in the browser[0] except for channels (which are very difficult to implement reliably given the Javascript concurrency model). If Google decided to allow Go as a language for manipulating the DOM in Chrome, there's no reason that it couldn't serve this role equally well. (This is what Google has done with Dart, so they're unlikely to do it with Go, but this is simply illustrative). [0] https://github.com/gopherjs/gopherjs https://github.com/gopherjs/gopherjs
mahmoudimus 12y ago
I understand the Go hype, but what kind of "heavy number crunching" have you traditionally done with Go?

by eik3_de 12y ago

> But we have technology needs that aren’t going to always be well served by Ruby What are some examples? I'll start with heavy number crunching (Go/C) and browser-based apps (JS)

gphil 12y ago

Concurrency (Clojure, Erlang)

MoOmer 12y ago
Not MRI, but JRuby + http://akka.io/ http://akka.io/ There are also some great gems like Celluloid to help. That said, it's not the same as built-in concurrency.

scottefein12 12y ago

If you need a lightening fast API, anecdotal evidence suggests you just can't get it down to the speeds you see with Go. Rack/Ruby just isn't going to cut it.

programminggeek 12y ago
You can get close if you don't use Rails. Seriously, Cuba + JRuby + Torquebox 4 is fast, nearly as fast as Go. http://madebymarket.com/blog/dev/ruby-web-benchmark-report.html http://madebymarket.com/blog/dev/ruby-web-benchmark-report.h...
- jshen 12y ago
  I'm sorry, a hello world benchmark is meaningless.
  - MrBra 12y ago
    For concurrency-testing-alone it might be not. If it works good at it, then it's a good indication that the concurrency model implemented in the language is not flawed and if there is a problem, then it might be somewhere else in the language. So that benchmark it's still valuable information in the sense that tells you that that particular language running on that particular runtime its not intrinsically bad at concurrency. In this particular case (JRuby) moreover, the language gets its concurrency layer thanks to Java, so I'd go really easy with that, unless you really want to say that Java is bad at concurrency or that this is not known and thus a "Hello World" example would not show it. Which are both wrongly proven statements. Nonetheless I must admit though that some of those combinations of runtime/server/frameworks are admittedly unstable to replicate or to work with in a real scenario.

chimeracoder 12y ago

> I'll start with heavy number crunching (Go/C) and browser-based apps (JS) Be careful to distinguish between the language and a particular implementation or runtime environment. Go, for example, runs perfectly well in the browser[0] except for channels (which are very difficult to implement reliably given the Javascript concurrency model). If Google decided to allow Go as a language for manipulating the DOM in Chrome, there's no reason that it couldn't serve this role equally well. (This is what Google has done with Dart, so they're unlikely to do it with Go, but this is simply illustrative). [0] https://github.com/gopherjs/gopherjs https://github.com/gopherjs/gopherjs

mahmoudimus 12y ago

I understand the Go hype, but what kind of "heavy number crunching" have you traditionally done with Go?