5 ms·

I don't like Rails, and I don't like Ruby, but this wasn't a particularly enlightening piece. He doesn't explain why using something like Django in place of Rai

by jfb 13y ago

I don't like Rails, and I don't like Ruby, but this wasn't a particularly enlightening piece. He doesn't explain why using something like Django in place of Rails makes sense; he handwaves a bit over Node. There's some statically typed language dogma, and that's it. I'd love to read a good hit piece on Rails, written by someone who spends the time to lay out a strong technical justification for their opinion. This was disappointingly Twitterish.

ThunderChief 13y ago
I completely agree. This piece highlights the inherent drawback of all dynamic languages: performance. We've been through the performance argument too many times to count with both Rails and PHP. I don't know what kind of taste I would have if I were to follow this piece as advice. Am I expected to do CGI in straight C? Ridiculous.
amalag 13y ago
With this article python==ruby because they are dynamic
- jfb 13y ago
  He sort of feints towards talking about why Django might be faster, but then doesn't. It's fundamentally an entirely vapid piece.
ape4 13y ago
For a midsized to big project static typing is really nice. eg A few years ago I had a perl project that only let you know a function was missing at run time (ie when the user asked for that code).
- jfb 13y ago
  That sounds ... less than great. I'm a fan of static typing, no question. I'm just not impressed with this article's handwaving.
- Mithaldu 13y ago
  That's why you write a test suite and check that your test suite covers all code, using Devel::Cover.
  - ape4 13y ago
    Thanks I didn't know about that. Of course I used a test suite. But checking that all functions actually exist (in my case some had been renamed) is something you should not have to manually write.
    - Mithaldu 13y ago
      Well, the idea is that your test suite should cover ALL code you have, so you don't have to check all your functions. Devel::Cover helps you by clearly marking code your tests don't run in red, so you know where you need to add tests and don't need to go through manually.
slackz 13y ago
Couldn't agree more with this sentiment (though I do like ruby as a language quite a bit). I have used other frameworks: sinatra in ruby, ring/compojure in clojure, flask in python, and there are a myriad of reasons to choose one of these over something like rails, but the author discusses none of this. I think much of the problem with rails is that it's so monolithic and has become rather bloated in certain respects. I would very much appreciate a more thorough, thoughtful discussion of the pros and cons of various design decisions in rails. It does a lot of things right which is why you see people modeling various tools after rails (database migrations for example... I recently wrote a clojure plugin that closely emulates the simplicity of making schema changes ( https://github.com/ckuttruff/clj-sql-up https://github.com/ckuttruff/clj-sql-up )). I work with rails every day and lots frustrates me about it, but it's also quite effective for a lot of things (which may be why "everyone and their dog" seems to use it). If you really want to have any influence over this fact, it would help tremendously to create a more compelling argument; I'm sure this would inspire much more interesting dialogue
jasonwatkinspdx 13y ago
I've worked with rails a lot over the years, including high traffic sites, and the general comment I'd make is that Rails scales more or less like PHP, but consumes far more ram per process doing so. Beyond that, whether it's good for your project probably depends a lot more on culture and the people involved than any technical distinction. Deploying rails was historically rather clunky, but that's been resolved over the last couple years thanks to folks like Heroku.

by jfb 13y ago

ThunderChief 13y ago

I completely agree. This piece highlights the inherent drawback of all dynamic languages: performance. We've been through the performance argument too many times to count with both Rails and PHP. I don't know what kind of taste I would have if I were to follow this piece as advice. Am I expected to do CGI in straight C? Ridiculous.

amalag 13y ago

With this article python==ruby because they are dynamic

jfb 13y ago
He sort of feints towards talking about why Django might be faster, but then doesn't. It's fundamentally an entirely vapid piece.

ape4 13y ago

For a midsized to big project static typing is really nice. eg A few years ago I had a perl project that only let you know a function was missing at run time (ie when the user asked for that code).

jfb 13y ago
That sounds ... less than great. I'm a fan of static typing, no question. I'm just not impressed with this article's handwaving.
Mithaldu 13y ago
That's why you write a test suite and check that your test suite covers all code, using Devel::Cover.
- ape4 13y ago
  Thanks I didn't know about that. Of course I used a test suite. But checking that all functions actually exist (in my case some had been renamed) is something you should not have to manually write.
  - Mithaldu 13y ago
    Well, the idea is that your test suite should cover ALL code you have, so you don't have to check all your functions. Devel::Cover helps you by clearly marking code your tests don't run in red, so you know where you need to add tests and don't need to go through manually.

slackz 13y ago

Couldn't agree more with this sentiment (though I do like ruby as a language quite a bit). I have used other frameworks: sinatra in ruby, ring/compojure in clojure, flask in python, and there are a myriad of reasons to choose one of these over something like rails, but the author discusses none of this. I think much of the problem with rails is that it's so monolithic and has become rather bloated in certain respects. I would very much appreciate a more thorough, thoughtful discussion of the pros and cons of various design decisions in rails. It does a lot of things right which is why you see people modeling various tools after rails (database migrations for example... I recently wrote a clojure plugin that closely emulates the simplicity of making schema changes ( https://github.com/ckuttruff/clj-sql-up https://github.com/ckuttruff/clj-sql-up )). I work with rails every day and lots frustrates me about it, but it's also quite effective for a lot of things (which may be why "everyone and their dog" seems to use it). If you really want to have any influence over this fact, it would help tremendously to create a more compelling argument; I'm sure this would inspire much more interesting dialogue

jasonwatkinspdx 13y ago

I've worked with rails a lot over the years, including high traffic sites, and the general comment I'd make is that Rails scales more or less like PHP, but consumes far more ram per process doing so. Beyond that, whether it's good for your project probably depends a lot more on culture and the people involved than any technical distinction. Deploying rails was historically rather clunky, but that's been resolved over the last couple years thanks to folks like Heroku.