5 ms·

> Ruby is hilarious slow, for example. [citation needed]. Also, relevant Stack Overflow debate is available. [1] TL;DR: yes, of course Ruby is slower than, say

• skywhopper 13y ago
  Depends on the task. Most of my programming is on the sysadmin side. So automation and log processing are two of the biggest things I deal with. I love Ruby to death. I'd program in it all the time if I could. And it works really well for automation. But for processing massive amounts of data? Not so much. I even did some tests a year or so ago when I was writing a script to merge together data from multiple log files and a couple of databases, including data transformations, merging/collation and sorting of, oh 100GB or so of raw log data a day. My first tests with Ruby were running pretty slow, so I decided to write the script out as I'd planned in both Ruby and Perl and compare the results on subsets of the data. I used none of Ruby's OO features, I just did straight simple data structures, hashes and arrays, etc. Ruby has far better infrastructure for dealing with these things built in, and so I wrote the Ruby script in a couple of hours. The Perl script took me a couple of days--admittedly my Perl is rusty, but I wasn't doing anything complicated. But the language just doesn't have as much stuff built in. Anyway, at the end I had two scripts with exactly the same logic, and I'd even had to implement some things (like Ruby's Array#uniq, which I assume (but don't know) is written in C) from scratch in Perl. So yeah I wasted 16 hours on the Perl script, but you could follow them line by line and they were identical. Run them one after the other to compare, and the Perl script is literally 100 times faster and uses a tenth of the RAM. I told my Python-loving friends about this and they guffawed at the silly Ruby guy, but it was depressing. So yeah, Ruby is slow at runtime compared to other languages. Usually that doesn't matter, but sometimes it matters a lot.
  • eCa 13y ago
    As an aside, Perl's uniq is in List::MoreUtils [1]. [1] https://metacpan.org/pod/List::MoreUtils https://metacpan.org/pod/List::MoreUtils
• interstitial 13y ago
  Developer Productivity in Rails means having a self-righteous excuse for hard-coding vital, tunable elements of your app and pretending you didn't just do that. A rails app is constantly under "development" because so much of it is just plain hard-coded in place under the guise of MVC and its single model of persistence: Active Record. Down-vote all you want. We've reached the turning point where you hear far more about big companies moving from rails, than switching to it.
  • h2s 13y ago
    I don't think there's enough attention on the fact that the strict MVC approach of big old school web frameworks like Rails is an increasingly glaring architectural dead-end. The "model" part of an MVC application is invariably far too complex to crowbar inside a couple of dozen Active Record subclasses. And you can't prescribe a one-size-fits-all architecture for the model from a framework level. That part has to emerge from the business and technical constraints of the specific application in order to be correct.
    • tomphoolery 13y ago
      What you're overlooking here is the "model" part of an MVC application is not limited to being an Active Record object. Indeed, many experienced Rails developers are also major proponents of the use of service objects and "domain models" which can exist outside of the database. The misunderstanding of when an MVC architecture is appropriate, and when to (and not to) use the framework, is the mark of someone who has not yet really understood how to use Rails effectively.
  • anko 13y ago
    > We've reached the turning point where you hear far more about big companies moving from rails, than switching to it. A lot of this is because 1) they jumped on the rails bandwagon without understanding it or if it suited their needs 2) after using rails to prototype their site, they now understand what their architecture should look like and want to start fresh 3) because they've joined the next circle jerk such ask nodejs All the rest of your post is overly vague, or simply untrue. People pick rails because it has sane defaults eg. ActiveRecord but there are plenty of other gems for other database persistence layers.
• VeejayRampay 13y ago
  Been a Ruby programmer for 5 years now and I find that this is dodging the issue. Sure the productivity is higher but what happens when you're finished developing and your code is now running in production? What happens when it's slow at serving requests, slow at any form of computations, slow when a rake task is starting? Talking about productivity is a good thing because raw "power" doesn't mean anything, but I really wish we could admit publicly that Ruby is really not a race horse. It does other things awfully well and I wouldn't trade language for the world, but man, I wish it could get a free speed jump like Javascript got a few years ago.
  • tomphoolery 13y ago
    There have been some steps in that direction, it seems. At my company, we made a graphics rendering engine in Ruby (haven't released it yet). In testing, it ran steadily, but consumed a lot of resources. But in each new version of Ruby, we saw that resource usage go down. Given that same level of innovation, we will see this graphics engine reach similar speeds as our current, more performant C and Lua implementation eventually. Ruby 2.0 and 2.1 made incredible improvements to the garbage collector, a major source of our problem. We determined that it was the speed at which we were creating and destroying objects that was causing the GC to work on overdrive, which drove up CPU usage. So with the new GC improvements, we saw that usage go further and further down.
  • nthj 13y ago
    > I really wish we could admit publicly that Ruby is really not a race horse. Ruby isn't a race horse. It just turns out that when you're just plowing fields, harnessing up your prize stallion is a waste of resources.
• epsylon 13y ago
  > but today's bottleneck isn't hardware, it's developer productivity. That's until you try to scale things.