4 ms·

A slow dynamic bytecode-interpreted globally VM-locked language running a massive completely-overkill framework is only 10x slower than a statically compiled na

by Freaky 13y ago

A slow dynamic bytecode-interpreted globally VM-locked language running a massive completely-overkill framework is only 10x slower than a statically compiled natively concurrent language running a tiny microframework? I'd say that's a massive positive for Ruby and Rails to be honest.

kailuowang 13y ago
It can be deemed as a "massive positive" for RoR only when "slow dynamic bytecode-interpreted globally VM-locked language running a massive completely-overkill framework" is a good thing.
- danielharan 13y ago
  You mean when I can write that could 3X faster?
  - bhauer 13y ago
    What? I'm sorry, I'm going to have to ask for some evidence. If you said 30% faster, I'd just shrug and disagree. But you said 300% faster. Developer efficiency is notoriously difficult to measure and prone to all sorts of biases. Perhaps the key word in your sentence is "I"?
    - danielharan 13y ago
      I meant: one I can write 3X faster. And yes, "I". Not sure how this generalizes - but it's generally a bad idea to pick a new language so the code will run fast if the time to delivery is important. I've done my fair share of both Java and Ruby web development, and without a doubt, I was much faster writing Ruby. For non-trivial Java apps, startup time was > 20 seconds. That kind of REPL while developing kills productivity and developer satisfaction. The last Java app I wrote had more lines of configuration than my first Rails app had lines of code, at equivalent complexity. The first Java job I had required a full-time script writer, a DBA, and someone to keep the web server up. In Rails, that entire team would have been shrunk by 75% (mind you it didn't exist back then). I do work in other languages. For machine learning, Ruby's speed is a killer except for toy data sets, so I have used Octave and Python. When it comes to the web though, Rails really did do many things right, from a sane MVC, default ORM, helpers and migrations. There are times execution speed trumps development speed. For fast dev on web apps, Rails really was cutting edge and for those with an investment it can still be a better trade-off than doing something in Go.
      - Uchikoma 13y ago
        Not do advocate Java, but your knowledge is dated, I'd say at least 5yrs off. Play has on the fly code compilation, Jetty does fast reloads, JRebel hot class reloading etc.
        danielharan 13y ago
        Upvoted because yes, it is outdated. I started doing Java professionally in 2001, and stopped years later. It still seems as though these frameworks are all playing catch-up, with e.g. things like migrations.
  - Flying_Dwarf 13y ago
    And have 10x more upkeep than a statically typed language. Go is more durable, and APIs kind of need that.
  - Uchikoma 13y ago
    I pay you $1000 (or EUR) if you show me how you can be 3x faster from idea to live with RoR against something else, say Java/Play. If 50% of your time is HTML/CSS fixing,thinking,finding edge cases,testing,debugging,communication with customers etc. you need to be 6x faster. And not in the first 5 days but you need to maintain this speed even as your code size grows and more and more time is spent on understanding existing code. The only way to reach 6x is with 3rd party libs you have in RoR but you have no equivalent on say the JVM. Massive code reuse is the only major productivity gain today. [edit] Sorry my mistake. If 50% of your time is taken by other tasks when writing say Java code, the most you can achieve is doubling your productivity by reducing development time to zero. If you tripple your productivity during development, your overall gain is 33% I think (not that good with on the fly calculation obviously). [edit2] Just realized, this is Amdahl's law for developer productivity with your other tasks being the sequential fraction.
    - danielharan 13y ago
      Amdahl's law: yeah, this is pretty much it. Of course I was only discussing dev time. Of note, many of the best Ruby / Rails folks I know moved on to much better roles, whether CTO at growing companies or started working on cash-generating projects. Once they optimized dev time, they got more time to work on things like design or copywriting, and optimized the hell out of that too.
      - Uchikoma 13y ago
        Love it when people think being CTO is better than coding :-)
        danielharan 13y ago
        In most cases, it was awesome for those people.
- jurre 13y ago
  Overkill for an API endpoint that authenticates a user..
andrewvc 13y ago
Completely agreed. These kinds of comparisons are always a joke. Rails has always been about programmer efficiency, not execution efficiency since day one.
- bradly 13y ago
  We shouldn't be so quick to call someone's learnings that they are sharing with the community a joke. I think knowing the performance difference could be very useful. The Rails app I work on has an API that gets over 300K RPM which adds up to quite an EC2 bill each month. Reading someone's experiments and results allows someone like myself to some super simple estimates on what the savings might be when going with Go vs Rails. It opens a conversation. Now if you are building a side project or haven't hit the level of traffic where performance improvements are extremely noticeable on your hosting projects, then maybe this isn't the post for you. But I would just advise that we be a little slower to call something that a fellow member of this community spent time learning and then sharing with others a joke.
Uchikoma 13y ago
Yes, if you're a VC backed startup, 10x the site costs (say 10 M instead of 1M) is not a problem. Otherwise the productivity gains of the developers need to make up the 9M difference.
saosebastiao 13y ago
Of course it is a positive. The question becomes, is the performance difference worth it? If you were comparing RoR to a Servlet framework, I'd say no. But I have yet to see any Go code that doesn't look at least as "productive" as any of the Ruby code I have seen or created.
zyb09 13y ago
10x is a lot though. Definitely not a positive for Ruby. People were making these comparisions between Java and C++ for ages, and called Java slow when something took 1.4x as long as native C++. Rails doesn't even try to compete.
- snogglethorpe 13y ago
  Yeah, but Ruby is famous for being really, really, slow. Almost everything is faster than Ruby, and many things—including other typeless dynamic bytecode-interpreted languages—are crazy faster. Being described as "much faster than that really super slow thing" is... well... I suppose it's not exactly a negative, but I wouldn't put it on my resume...
kc5tja 13y ago
That's a positive for Ruby only when you're not running on a cloud server, or when you are cost-conscious about the amount of electricity you're sucking in a data center somewhere. That being said, that Ruby is 10x slower than Go isn't that much of a surprise. It's not a string-interpreted language like the BASICs of old. It's interpreting byte-codes, and anyone who's ever written a 6502 or Z-80 emulator (essentially the same thing) can tell you, on average, most byte-codes take 10x as long to run as the corresponding function written in in-line C. Computer science -- it works!

by Freaky 13y ago

kailuowang 13y ago

It can be deemed as a "massive positive" for RoR only when "slow dynamic bytecode-interpreted globally VM-locked language running a massive completely-overkill framework" is a good thing.

danielharan 13y ago
You mean when I can write that could 3X faster?
- bhauer 13y ago
  What? I'm sorry, I'm going to have to ask for some evidence. If you said 30% faster, I'd just shrug and disagree. But you said 300% faster. Developer efficiency is notoriously difficult to measure and prone to all sorts of biases. Perhaps the key word in your sentence is "I"?
  - danielharan 13y ago
    I meant: one I can write 3X faster. And yes, "I". Not sure how this generalizes - but it's generally a bad idea to pick a new language so the code will run fast if the time to delivery is important. I've done my fair share of both Java and Ruby web development, and without a doubt, I was much faster writing Ruby. For non-trivial Java apps, startup time was > 20 seconds. That kind of REPL while developing kills productivity and developer satisfaction. The last Java app I wrote had more lines of configuration than my first Rails app had lines of code, at equivalent complexity. The first Java job I had required a full-time script writer, a DBA, and someone to keep the web server up. In Rails, that entire team would have been shrunk by 75% (mind you it didn't exist back then). I do work in other languages. For machine learning, Ruby's speed is a killer except for toy data sets, so I have used Octave and Python. When it comes to the web though, Rails really did do many things right, from a sane MVC, default ORM, helpers and migrations. There are times execution speed trumps development speed. For fast dev on web apps, Rails really was cutting edge and for those with an investment it can still be a better trade-off than doing something in Go.
    - Uchikoma 13y ago
      Not do advocate Java, but your knowledge is dated, I'd say at least 5yrs off. Play has on the fly code compilation, Jetty does fast reloads, JRebel hot class reloading etc.
      - danielharan 13y ago
        Upvoted because yes, it is outdated. I started doing Java professionally in 2001, and stopped years later. It still seems as though these frameworks are all playing catch-up, with e.g. things like migrations.
- Flying_Dwarf 13y ago
  And have 10x more upkeep than a statically typed language. Go is more durable, and APIs kind of need that.
- Uchikoma 13y ago
  I pay you $1000 (or EUR) if you show me how you can be 3x faster from idea to live with RoR against something else, say Java/Play. If 50% of your time is HTML/CSS fixing,thinking,finding edge cases,testing,debugging,communication with customers etc. you need to be 6x faster. And not in the first 5 days but you need to maintain this speed even as your code size grows and more and more time is spent on understanding existing code. The only way to reach 6x is with 3rd party libs you have in RoR but you have no equivalent on say the JVM. Massive code reuse is the only major productivity gain today. [edit] Sorry my mistake. If 50% of your time is taken by other tasks when writing say Java code, the most you can achieve is doubling your productivity by reducing development time to zero. If you tripple your productivity during development, your overall gain is 33% I think (not that good with on the fly calculation obviously). [edit2] Just realized, this is Amdahl's law for developer productivity with your other tasks being the sequential fraction.
  - danielharan 13y ago
    Amdahl's law: yeah, this is pretty much it. Of course I was only discussing dev time. Of note, many of the best Ruby / Rails folks I know moved on to much better roles, whether CTO at growing companies or started working on cash-generating projects. Once they optimized dev time, they got more time to work on things like design or copywriting, and optimized the hell out of that too.
    - Uchikoma 13y ago
      Love it when people think being CTO is better than coding :-)
      - danielharan 13y ago
        In most cases, it was awesome for those people.
jurre 13y ago
Overkill for an API endpoint that authenticates a user..

andrewvc 13y ago

Completely agreed. These kinds of comparisons are always a joke. Rails has always been about programmer efficiency, not execution efficiency since day one.

bradly 13y ago
We shouldn't be so quick to call someone's learnings that they are sharing with the community a joke. I think knowing the performance difference could be very useful. The Rails app I work on has an API that gets over 300K RPM which adds up to quite an EC2 bill each month. Reading someone's experiments and results allows someone like myself to some super simple estimates on what the savings might be when going with Go vs Rails. It opens a conversation. Now if you are building a side project or haven't hit the level of traffic where performance improvements are extremely noticeable on your hosting projects, then maybe this isn't the post for you. But I would just advise that we be a little slower to call something that a fellow member of this community spent time learning and then sharing with others a joke.

Uchikoma 13y ago

Yes, if you're a VC backed startup, 10x the site costs (say 10 M instead of 1M) is not a problem. Otherwise the productivity gains of the developers need to make up the 9M difference.

saosebastiao 13y ago

Of course it is a positive. The question becomes, is the performance difference worth it? If you were comparing RoR to a Servlet framework, I'd say no. But I have yet to see any Go code that doesn't look at least as "productive" as any of the Ruby code I have seen or created.

zyb09 13y ago

10x is a lot though. Definitely not a positive for Ruby. People were making these comparisions between Java and C++ for ages, and called Java slow when something took 1.4x as long as native C++. Rails doesn't even try to compete.

snogglethorpe 13y ago
Yeah, but Ruby is famous for being really, really, slow. Almost everything is faster than Ruby, and many things—including other typeless dynamic bytecode-interpreted languages—are crazy faster. Being described as "much faster than that really super slow thing" is... well... I suppose it's not exactly a negative, but I wouldn't put it on my resume...

kc5tja 13y ago

That's a positive for Ruby only when you're not running on a cloud server, or when you are cost-conscious about the amount of electricity you're sucking in a data center somewhere. That being said, that Ruby is 10x slower than Go isn't that much of a surprise. It's not a string-interpreted language like the BASICs of old. It's interpreting byte-codes, and anyone who's ever written a 6502 or Z-80 emulator (essentially the same thing) can tell you, on average, most byte-codes take 10x as long to run as the corresponding function written in in-line C. Computer science -- it works!