5 ms·

the "too slow argument" is normally based on old internet opinions and benchmarks.. ruby today is pretty fast. In the company that I work, we do a lot of system

the "too slow argument" is normally based on old internet opinions and benchmarks.. ruby today is pretty fast. In the company that I work, we do a lot of system programming using ruby, web development, etc.. It came to substitute perl around 2005, and we still using it successfully today. When we need something really, really fast, specially including parallel processing and etc, we just use jruby.

dragonwriter 4y ago
> ruby today is pretty fast Ruby today is slow as hell, but not as much as slower than other slow as hell languages as Ruby used to be.
- pelasaco 4y ago
  did you benchmark Jruby or TruffleRuby? Did you compile c-ruby with jemalloc? Normally the "ruby is slow" argument, is based on not being involved with ruby and solving real problems with it. Some people will just LOL this argument even harder if you add development time and code maintenance costs on that equation.
  - vidarh 4y ago
    Also premature optimisation. I did image manipulation and statistical analysis of images using predominantly Ruby for my MSc thesis work 15 years ago, and it took rewriting a couple of dozen lines of code with RubyInline (to use C) to remove the bottlenecks. Using pure Ruby to prototype and rewriting just the maths heavy code to C when I knew it worked and knew where the bottlenecks were saved me massive amounts of time. I've done map rendering in Ruby for similar reasons - outside of specific niches, it's rare for the speed of Ruby to be an issue.
    - pelasaco 4y ago
      One funny anecdote (and unfair one) is that what Twitter wasn't able to do (rails scale), Mastodon did.
      - vidarh 4y ago
        I recall several discussions of it at the time, and I don't think it's so much that they weren't able to, as that they'd made lots of disastrous architecture decisions (building it around a monolithic database etc.) that required a rewrite, and whomever doing it used it as an opportunity to blame it on Rails as an excuse to switch to their preferred stack. After all, sharding message distribution via federation (even if you hide the federation behind a veneer of a global userid -> shard mapping) was a well understood long before Twitter even launched (e-mail... reflectors...), so it was a rather embarrassing architectural decision to not even try to account for it. Heck, I co-founded a webmail provider in '99, and one of the first things we did was implement ways to map user ids to a distributed set of backends and support for migrating accounts between backends, because we knew it'd be necessary to be able to shard smtp servers, frontends, and storage separately. That wasn't in Ruby, but the architectural pattern is so obvious. The language change may or may not have made sense for them at the time (after all Ruby was much slower then, and they by then had the size where a rewrite of core parts to cut hosting costs might have been worth it), but that they blamed their architectural failures on Rails was a cheap shot.
        pelasaco 4y ago
        Normally such decisions come from "Senior developers", which are experts in other domains than ruby on rails. How often you see them wanting to write raw sql in rails, "because its faster" and/or "much easier".. this summarizes a lot that problem https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th...
  - deleted 4y ago
    [deleted]
  - dragonwriter 4y ago
    > did you benchmark Jruby or TruffleRuby? Did you compile c-ruby with jemalloc? Jruby a little faster than CRuby (it used to be more significantly faster, but CRuby has seen more recent performance increase); TruffleRuby is, OTOH, not slow like other implementations. > Normally the "ruby is slow" argument, is based on not being involved with ruby and solving real problems with it. Ruby is abstractly my preferred language, and I’ve done a fair amount in it, though I don't get to use it as much in anger because of issues other than its speed (ending up using another slow language as my main day to day.) > Some people will just LOL this argument even harder if you add development time and code maintenance costs on that equation. That’s just equivocation; time and cost to market is an orthogonal concern to execution speed, not a component of it; yes, Ruby has a decent code-writing experience, especially for small systems.
    - pelasaco 4y ago
      > That’s just equivocation; time and cost to market is an orthogonal concern to execution speed, not a component of it; yes, Ruby has a decent code-writing experience, especially for small systems. Probably you meant rails here. I don't see why ruby should be a problem for something not small, moreover, you should first define what a small system is, specially if you count the LOC of all the gems that you use..
mtrower 4y ago
To think I'd live to see the day the JVM is regarded as "really, really fast". Ruby is not "pretty fast". The hardware you run it on is insanely, mind bogglingly, out of this world fast and so people don't notice the way that they used to. ...which is fine, you don't always need to be fast. Just be wary of misattribution.
- pelasaco 4y ago
  The java based ruby, removes the GIL, which provides us real multithreading. Truffleruby is "A high performance implementation of the Ruby programming language, built on GraalVM." If you prefer there is even a rust based ruby https://github.com/artichoke/artichoke https://github.com/artichoke/artichoke again, IMO, the microbenchmark, doesn't matter. What matters is the problem domain, whole stack and the whole "speed", including development, deployment and etc, and for some domains, ruby is the best and fast choice.
  - Alifatisk 4y ago
    Well, Ruby 3 has Ractors which is still in experimental stage but offers true multicore processing. It's quiet fun to play around with actually, to see all your cores being utilized.

dragonwriter 4y ago

> ruby today is pretty fast Ruby today is slow as hell, but not as much as slower than other slow as hell languages as Ruby used to be.

pelasaco 4y ago
did you benchmark Jruby or TruffleRuby? Did you compile c-ruby with jemalloc? Normally the "ruby is slow" argument, is based on not being involved with ruby and solving real problems with it. Some people will just LOL this argument even harder if you add development time and code maintenance costs on that equation.
- vidarh 4y ago
  Also premature optimisation. I did image manipulation and statistical analysis of images using predominantly Ruby for my MSc thesis work 15 years ago, and it took rewriting a couple of dozen lines of code with RubyInline (to use C) to remove the bottlenecks. Using pure Ruby to prototype and rewriting just the maths heavy code to C when I knew it worked and knew where the bottlenecks were saved me massive amounts of time. I've done map rendering in Ruby for similar reasons - outside of specific niches, it's rare for the speed of Ruby to be an issue.
  - pelasaco 4y ago
    One funny anecdote (and unfair one) is that what Twitter wasn't able to do (rails scale), Mastodon did.
    - vidarh 4y ago
      I recall several discussions of it at the time, and I don't think it's so much that they weren't able to, as that they'd made lots of disastrous architecture decisions (building it around a monolithic database etc.) that required a rewrite, and whomever doing it used it as an opportunity to blame it on Rails as an excuse to switch to their preferred stack. After all, sharding message distribution via federation (even if you hide the federation behind a veneer of a global userid -> shard mapping) was a well understood long before Twitter even launched (e-mail... reflectors...), so it was a rather embarrassing architectural decision to not even try to account for it. Heck, I co-founded a webmail provider in '99, and one of the first things we did was implement ways to map user ids to a distributed set of backends and support for migrating accounts between backends, because we knew it'd be necessary to be able to shard smtp servers, frontends, and storage separately. That wasn't in Ruby, but the architectural pattern is so obvious. The language change may or may not have made sense for them at the time (after all Ruby was much slower then, and they by then had the size where a rewrite of core parts to cut hosting costs might have been worth it), but that they blamed their architectural failures on Rails was a cheap shot.
      - pelasaco 4y ago
        Normally such decisions come from "Senior developers", which are experts in other domains than ruby on rails. How often you see them wanting to write raw sql in rails, "because its faster" and/or "much easier".. this summarizes a lot that problem https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://daedtech.com/how-developers-stop-learning-rise-of-th...
- deleted 4y ago
  [deleted]
- dragonwriter 4y ago
  > did you benchmark Jruby or TruffleRuby? Did you compile c-ruby with jemalloc? Jruby a little faster than CRuby (it used to be more significantly faster, but CRuby has seen more recent performance increase); TruffleRuby is, OTOH, not slow like other implementations. > Normally the "ruby is slow" argument, is based on not being involved with ruby and solving real problems with it. Ruby is abstractly my preferred language, and I’ve done a fair amount in it, though I don't get to use it as much in anger because of issues other than its speed (ending up using another slow language as my main day to day.) > Some people will just LOL this argument even harder if you add development time and code maintenance costs on that equation. That’s just equivocation; time and cost to market is an orthogonal concern to execution speed, not a component of it; yes, Ruby has a decent code-writing experience, especially for small systems.
  - pelasaco 4y ago
    > That’s just equivocation; time and cost to market is an orthogonal concern to execution speed, not a component of it; yes, Ruby has a decent code-writing experience, especially for small systems. Probably you meant rails here. I don't see why ruby should be a problem for something not small, moreover, you should first define what a small system is, specially if you count the LOC of all the gems that you use..

mtrower 4y ago

To think I'd live to see the day the JVM is regarded as "really, really fast". Ruby is not "pretty fast". The hardware you run it on is insanely, mind bogglingly, out of this world fast and so people don't notice the way that they used to. ...which is fine, you don't always need to be fast. Just be wary of misattribution.

pelasaco 4y ago
The java based ruby, removes the GIL, which provides us real multithreading. Truffleruby is "A high performance implementation of the Ruby programming language, built on GraalVM." If you prefer there is even a rust based ruby https://github.com/artichoke/artichoke https://github.com/artichoke/artichoke again, IMO, the microbenchmark, doesn't matter. What matters is the problem domain, whole stack and the whole "speed", including development, deployment and etc, and for some domains, ruby is the best and fast choice.
- Alifatisk 4y ago
  Well, Ruby 3 has Ractors which is still in experimental stage but offers true multicore processing. It's quiet fun to play around with actually, to see all your cores being utilized.