Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why critics of Rails have it all wrong (and Ruby's bright multicore future)

unlimitednovelty.com

Post reply on HN
Print view View original

81–90 of 127 posts

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#81

Post by jes5199 »

tlack wrote: post #73
jes5199 wrote: post #62

Earlier quoted context omitted.

and by the way, I can't recommend Node either. As far as I can tell, they're eagerly making these same mistakes.

Node is no panacea, but that's not quite true about stable APIs. npm is great about maintaining separately versioned libraries and reducing conflicts. In your package.json can specify what version of a library to use and npm mostly figures it out for you. For instance, I'm still intentionally using an older version of Express (2.5.9 instead of 3.0.x) and npm hasn't had a problem figuring out deps. Part of the reason…

sure, but, if you chose to upgrade to Express 3.0.0, would your application still work? or are all the method signatures in Express 3 different from Express 2.5 ?

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#82

Post by wycats »

knowtheory wrote: post #69
dasil003 wrote: post #65

Earlier quoted context omitted.

I don't understand why you think Rails was on hold for all that time and that the modularity is not worth it. Yes it was a tremendous refactoring effort that took a lot of cycles, but Rails 3 has come out with great features. I mean arel, unobtrusive js, bundler, routing API, and actionmailer overhaul just in 3.0. The asset pipeline, full engine support, modularity benefits such as pluggable ORMs and log subscribers.…

It is worth pointing out that you're talking to the dude who wrote Jammit. The asset pipeline was not an innovation in or by Rails3.

The idea of asset packaging, of course, is not innovative. Jeremy's original claim was that Rails was put on hold. Integrating an asset pipeline solution into Rails took time and commits, and providing an ecosystem-wide solution for something like this has a strong impact on the overall productivity of the ecosystem.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#83

Post by jeltz »

dcu wrote: post #36
bryanlarsen wrote: post #32

Earlier quoted context omitted.

Seriously? How often do you need to reboot Rails? In dev mode it reloads code as it's changed, so pretty much the only time you need to reboot Rails is when you change the configuration or update your gems. Maybe once a week, say. The startup time is a couple of seconds, so you switched frameworks to save a couple seconds a week. Hardcore.

heh. running specs requires to boot rails, starting the console, switching branchs, reviewing code, etc... rails boots fast if you have few files but when the project is big it is a pain, it takes a lot of time to boot and it's not fun. That's why the article says rails is "a day job". I just hope the rails team don't think like you.

The boot times is one of the main reasons rails feels like a day job for me. It is there for every rake task, every time I need to generate a migration, every time I need to use the console. All this waiting makes me lose my flow and forget what I was doing.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#84

Post by mfkp »

dcu wrote: post #27

For me, the biggest problem with rails is that it boots really slow on development so it's really boring. I switched to padrino a while ago due to this issue. Also I prefer padrino's router since it's more explicit.

You should check out Zeus (https://github.com/burke/zeus). "Boot any rails app in under a second". It'll use more memory, unless you want to GC-patch your ruby (instructions in the repo).

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#85

Post by bonzoesc »

heretohelp wrote: post #56
nahname wrote: post #37

Earlier quoted context omitted.

I really liked using Sinatra until I used it with a team. The lack of ceremony and structure (as you put it) killed us. The app started out as just a simple service, so why not use Sinatra right? Then things changed and we were more focused on the web side, but stuck with Sinatra because everyone had heard the FUD about rails. Each person has a preference on where they thought something should be. Days were spent arg…

I agree that the total lack of structure in Sinatra can be harmful at times, but don't blame a technology for your team problems. That's just the bad workman blaming his tools for the faults of the toolbags he works with.

Blaming the tools is completely reasonable if your problems can be solved by better or more appropriate tools. If I need to drill a hole precisely and accurately and the team or management has standardized on hand drills, it's entirely appropriate to bemoan the use of hand drills versus a proper drill press with an appropriate jig.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#86

Post by dcu »

mfkp wrote: post #84
dcu wrote: post #27

For me, the biggest problem with rails is that it boots really slow on development so it's really boring. I switched to padrino a while ago due to this issue. Also I prefer padrino's router since it's more explicit.

You should check out Zeus ( https://github.com/burke/zeus ). "Boot any rails app in under a second". It'll use more memory, unless you want to GC-patch your ruby (instructions in the repo).

yeah already saw it, but why are these hacks needed in first place? I am pretty sure there's a good way to fix rails to load faster in a reasonable amount of time (again, I am talking about big projects).

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#87

Post by dcu »

jeltz wrote: post #24
planetmcd wrote: post #17

Earlier quoted context omitted.

I really enjoy Sinatra and am indeed using it for REST style API hosting, but the counter argument might be all the security stuff that is built into the Rails routes/controllers. this might be a great case for a stripped down rails app as opposed to a Sinatra app.

I thought most of the security in Rails is provided by the rack-security middleware? Or am I forgetting something which Rails provides here?

Escaping everything by default to avoid XSS attacks. that's a nice feature to have.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#88

Post by aneth4 »

I use Rails for most projects. It has its warts and there are many things I dislike about it. I also like node, but after experiencing the sad state of nearly ever node module I tried, I came to the conclusion that the ecosystem is just not there yet. If you want to start from scratch, node may be the way to go. If you like leveraging existing code, node can be hell.

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#89

Post by hekker »

bascule wrote: post #79
dscrd wrote: post #45

Having developed software on both Rails and Django, I prefer the latter. Reasoning: python's community seems more professional. They have well-defined language change and enhancement processes (the PEP), good docs online, almost every question imaginable has been answered already somewhere, and the performance ain't too bad. Plus the code smell overall is just... lesser. Then again, I came from a background of C and…

Last I checked out Django they had just added a bunch of features from Rails 1.2. (Edit: sorry, Rails 2.1) Python suffers from their web framework community being too fragmented, so none of the projects are as mature as Rails.

I use Django for my projects and I don't share this opinion on the maturity aspect. Can you explain your statement a bit more? What aspects of Django are immature?

Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)

#90

Post by squidsoup »

dscrd wrote: post #45

Having developed software on both Rails and Django, I prefer the latter. Reasoning: python's community seems more professional. They have well-defined language change and enhancement processes (the PEP), good docs online, almost every question imaginable has been answered already somewhere, and the performance ain't too bad. Plus the code smell overall is just... lesser. Then again, I came from a background of C and…

Having moved from rails to django development the thing I am missing the most is the wide range of mature testing tools in the ruby ecosystem. Django's testing tools feel very primitive comparatively and there's no clear separation of unit, functional and integration tests. I'd agree that in general the python community feels more professional and that the quality of documentation is typically better.
Post reply on HN