4 ms·

Ruby’s Popularity On The Up; An Ideal Haven For The Recession?

11 points by qhoxie 18y ago

pragmatic 18y ago
Yes just use this: require "no_recession" Ruby is magic and makes a great flavoring for kool-aid. Make sure to have some every day.
- ducktyped 18y ago
  Ruby is great, segments of the Rails community are kool-aid. Don't let Rails culture ruin Ruby for you. :)
- deleted 18y ago
  [deleted]
wheels 18y ago
I love the meme. "How we'll survive the downturn by doing exactly what we were doing." It's just become another reason to evangelize the same technologies people were evangelizing before the downturn.
thomasmallen 18y ago
If any open-source platforms were to take a hit from a recession, I'd expect Rails to be first. "Just throw hardware at the problem" doesn't sound so easy when you're on a tight budget.
- spif 18y ago
  "Just throw hardware at the problem" please watch this presentation and then see if your statement makes any sense: http://events.carsonified.com/fowa/2008/london/highlights/blaine-cook-joe-stump/ http://events.carsonified.com/fowa/2008/london/highlights/bl...
  - thomasmallen 18y ago
    Could you just explain the video? I don't have time to watch a 9-minute video called "Languages don't scale," especially considering that my post didn't mention any programming languages. Or do you equate Rails with the Ruby language?
    - spif 18y ago
      I equate the statement that "throw hardware at the problem" in the case of Rails to be uneducated. The whole myth that Rails doesn't scale is becoming annoying. The video explains that it's not a framework or language that doesn't scale - it's either CPU bound or IO bound. Saying that Rails quates to 'throwing hardware' at a problem is silly because there are waaaaay more variables and once you get to the bottom of the problem you'll see that the framework makes little difference. In our case (soocial.com) we use rails for our webapp and ruby for most syncing bots - the bottle neck has been the database and never really rails. And we don't expect it to be.
- justinweiss 18y ago
  That's true, but you might be missing the productivity gains from using a framework like Ruby/Rails -- you can throw a lot of hardware at a problem for less than a single extra developer's salary.
  - thomasmallen 18y ago
    You're right, but the people making tech decisions won't think that way. Too shortsighted. (won't make my argument about other, less resource-intensive languages being productive...that's just asking for trouble here).
    - ducktyped 18y ago
      Rails coders are more expensive than e.g. php coders. Given the same head count, a Rails shop will burn more cash. Many managers don't see productivity, but cost = headcount x salaries. It's the easiest variables for them to tweak to change their bottom line. Of course, productivity depends far more on the quality of the programmers and coding practices of the team than the language. I'd take a team of kick ass php guys any time over a group of inexperienced/douchy rails guys, and I hate php with a passion. Ceteris paribus I'd go with Ruby. (Come to think of it, it kind of reminds of the martial arts comparison mantra: "It's the quality of the individual practitioner that counts far more than his chosen style")
      - thomasmallen 18y ago
        (good thing I deferred my pro-PHP argument)
jhancock 18y ago
I use ruby. I use merb. I think they are great choices for what I needed to build. I do not see bean counters making the same choices. I see them making decisions purely from a cost perspective. This means more outsourcing to PHP programmers in Ukraine and India. It means more outsourcing to graphics design and html/css work to people with native Western business understanding and shedding the full time staff. I do not see how ruby will be a preferred choice the bean counters will stumble onto easily. Over time, merb may have enough productivity metrics available to sway the bean counters while at the same time showing the production cost/scaling benefits as well (where rails has a hard time). But this understanding by the PHBs will take time...possibly a long time.

11 points by qhoxie 18y ago

Yes just use this: require "no_recession" Ruby is magic and makes a great flavoring for kool-aid. Make sure to have some every day.

ducktyped 18y ago
Ruby is great, segments of the Rails community are kool-aid. Don't let Rails culture ruin Ruby for you. :)
deleted 18y ago
[deleted]

wheels 18y ago

I love the meme. "How we'll survive the downturn by doing exactly what we were doing." It's just become another reason to evangelize the same technologies people were evangelizing before the downturn.

thomasmallen 18y ago

If any open-source platforms were to take a hit from a recession, I'd expect Rails to be first. "Just throw hardware at the problem" doesn't sound so easy when you're on a tight budget.

spif 18y ago
"Just throw hardware at the problem" please watch this presentation and then see if your statement makes any sense: http://events.carsonified.com/fowa/2008/london/highlights/blaine-cook-joe-stump/ http://events.carsonified.com/fowa/2008/london/highlights/bl...
- thomasmallen 18y ago
  Could you just explain the video? I don't have time to watch a 9-minute video called "Languages don't scale," especially considering that my post didn't mention any programming languages. Or do you equate Rails with the Ruby language?
  - spif 18y ago
    I equate the statement that "throw hardware at the problem" in the case of Rails to be uneducated. The whole myth that Rails doesn't scale is becoming annoying. The video explains that it's not a framework or language that doesn't scale - it's either CPU bound or IO bound. Saying that Rails quates to 'throwing hardware' at a problem is silly because there are waaaaay more variables and once you get to the bottom of the problem you'll see that the framework makes little difference. In our case (soocial.com) we use rails for our webapp and ruby for most syncing bots - the bottle neck has been the database and never really rails. And we don't expect it to be.
justinweiss 18y ago
That's true, but you might be missing the productivity gains from using a framework like Ruby/Rails -- you can throw a lot of hardware at a problem for less than a single extra developer's salary.
- thomasmallen 18y ago
  You're right, but the people making tech decisions won't think that way. Too shortsighted. (won't make my argument about other, less resource-intensive languages being productive...that's just asking for trouble here).
  - ducktyped 18y ago
    Rails coders are more expensive than e.g. php coders. Given the same head count, a Rails shop will burn more cash. Many managers don't see productivity, but cost = headcount x salaries. It's the easiest variables for them to tweak to change their bottom line. Of course, productivity depends far more on the quality of the programmers and coding practices of the team than the language. I'd take a team of kick ass php guys any time over a group of inexperienced/douchy rails guys, and I hate php with a passion. Ceteris paribus I'd go with Ruby. (Come to think of it, it kind of reminds of the martial arts comparison mantra: "It's the quality of the individual practitioner that counts far more than his chosen style")
    - thomasmallen 18y ago
      (good thing I deferred my pro-PHP argument)

jhancock 18y ago

I use ruby. I use merb. I think they are great choices for what I needed to build. I do not see bean counters making the same choices. I see them making decisions purely from a cost perspective. This means more outsourcing to PHP programmers in Ukraine and India. It means more outsourcing to graphics design and html/css work to people with native Western business understanding and shedding the full time staff. I do not see how ruby will be a preferred choice the bean counters will stumble onto easily. Over time, merb may have enough productivity metrics available to sway the bean counters while at the same time showing the production cost/scaling benefits as well (where rails has a hard time). But this understanding by the PHBs will take time...possibly a long time.