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

101–110 of 127 posts

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

#101

Post by rbanffy »

nwienert wrote: post #16
endlessvoid94 wrote: post #2

No other programming community on the planet cares so much about how they're perceived. I suspect there's a silent majority...

Any new and active programming community should be vocal, and node is no different. In fact, both node and rails have very loud supporters and detractors (IE, you).

I don't think loud people contribute to the health of a community. In fact, I consider it a "community-smell" - when there is too much incentive to be a "rockstar", too many people will focus on being rockstars and not enough will be focus on actually getting the job done.

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

#102

Post by bithive123 »

jes5199 wrote: post #61

(I'm a full time Ruby/Rails programmer, and I have been for five years.) There's a major flaw in the R/R culture: they have no interest in maintaining stable APIs. If you want to upgrade your Rails app to the latest version of some library, you might as well do a rewrite of your entire app. So many of the APIs change from release to release that most of your gems will stop working unless you upgrade. When you upgrade…

This is sadly too true. We have over a dozen Rails apps that need indefinite maintenance and we end up specifying explicit gem versions and/or burning lots of time just staying current. Still, it's better than everyone doing their projects in ad-hoc PHP.

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

#103

Post by adamkittelson »

tomjakubowski wrote: post #30
adamkittelson wrote: post #14

As far as using websockets with Rails goes, I just wanted to mention that I've been having a really good experience using the websocket-rails gem ( https://github.com/DanKnox/websocket-rails ) in a text game (MUD) I'm working on as a Rails 3 app.

That sounds amazing! When you've got this MUD on Rails going, please do submit it here. Similarly, I'm working on a MCaaS (MUD Client as a Service ;]) half tongue-in-cheek to learn more about Node. There's no feeling like using new & exciting tech to solve the problems of our neckbearded forefathers.

That sounds cool too, have a demo up anywhere? I'm kinda doing a deploy as I code thing, I've added the url to my profile.

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

#104

Post by cheald »

ajsharp wrote: post #96
cheald wrote: post #20

Earlier quoted context omitted.

"Rails" is a collection of libraries and conventions, just as "Sinatra + ActiveRecord" is. There's nothing inherent in it that makes it "worse" than Sinatra (which I love, by the way) for JSON APIs. Use Rack, pick your favorite gems, and go to town. Why mess with all the other Sinatra junk when you can have a simple config.ru for your app and just write a simple call method and you're good to go? You don't need all t…

Whole-heartedly disagree. You can't even parse a json-encoded POST body with plain-vanilla Rack without a middleware from rack-contrib HEAD (the "stable" version is about a year behind the last time I checked). Rack is a standard and abstraction for build ruby app servers and frameworks. To say it's sufficient for building production quality API's is just absurd. One of the main benefits of using frameworks like Sina…

Unless I vastly misunderstand your statement, it's nowhere nearly that hairy.

https://gist.github.com/3719513

Did I miss something?

Rack is "env variable goes in, array of [code, headers, body] comes out, here are some handy utils for handling grunt work". That's it. That's Rack. You can do whatever you please with it in the middle. That's all that a middleware is, and Rails itself is basically just a collection of Rack middlewares (procs) with some support libraries stapled on. That's a gross simplification, but at the end of the day, that's basically the heart and soul of the framework.

My point is that there are multiple levels of abstraction. Of course you don't have to re-write and re-implement boilerplate when you use Sinatra over Rack, just like you don't have to re-write and re-implement when you use Rails over Sinatra. "Rails bad, Sinatra good" is just silly, because it all boils down to what kind of tradeoff you're willing to make between what's done in framework versus what's done in your application.

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

#105

Post by krichman »

cheald wrote: post #20
programminggeek wrote: post #4

I love Ruby, but I have no love for Rails. Want to write a nice JSON API using something light and nice? Use Sinatra, pick your favorite ORM (even ActiveRecord) and go to town. Why mess with all the other Rails junk when you can have a simple app.rb for your sinatra app and just write simple little controller actions and you're good to go? You don't need all the ceremony and structure of Rails and MVC to write a JSON…

"Rails" is a collection of libraries and conventions, just as "Sinatra + ActiveRecord" is. There's nothing inherent in it that makes it "worse" than Sinatra (which I love, by the way) for JSON APIs. Use Rack, pick your favorite gems, and go to town. Why mess with all the other Sinatra junk when you can have a simple config.ru for your app and just write a simple call method and you're good to go? You don't need all t…

I get what you are saying, but I feel reducto ad absurdum is unfair here. I understood the parent's point as this; using Sinatra to give yourself the convenience of the {get,post,...} methods for working with HTTP vs. Rails, which forces upon you its more opinionated structure for websites.

I agree with the parent, that I have no use for the complexity of Rails and Sinatra is convenient. Other people are free to choose as they wish, and Rails might be the more appropriate library is some cases regardless of preference (like in the sibling post about teams).

But there's a ton of utility on the spectrum from Rack to Rails and it's perfectly reasonable to choose a midpoint, and perfectly reasonable to choose it because you think Rails is too much but Rack is not enough.

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

#106

Post by marknutter »

dasil003 wrote: post #68
marknutter wrote: post #52

> Meanwhile, Node.js is the new hotness, and many in the Node community have sought to build Node up by bringing Ruby and Rails down This is exactly what the Rails community did to PHP when Rails was the new hotness.

Java is the better analogy. Rails is now a mature enterprise-worthy framework, but it suffers in some basic areas that Node handles well despite a relative lack of maturity.

> Java is the better analogy

Agreed, good catch.

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

#107

Post by cheald »

krichman wrote: post #105
cheald wrote: post #20

Earlier quoted context omitted.

"Rails" is a collection of libraries and conventions, just as "Sinatra + ActiveRecord" is. There's nothing inherent in it that makes it "worse" than Sinatra (which I love, by the way) for JSON APIs. Use Rack, pick your favorite gems, and go to town. Why mess with all the other Sinatra junk when you can have a simple config.ru for your app and just write a simple call method and you're good to go? You don't need all t…

I get what you are saying, but I feel reducto ad absurdum is unfair here. I understood the parent's point as this; using Sinatra to give yourself the convenience of the {get,post,...} methods for working with HTTP vs. Rails, which forces upon you its more opinionated structure for websites. I agree with the parent, that I have no use for the complexity of Rails and Sinatra is convenient. Other people are free to choo…

I absolutely agree with you. What sticks in my craw is the oft-repeated mantra that "Rails is too heavy" or the perception that Sinatra is doing something that Rails isn't.

When you look at Rails as a collection of middlewares (which you can choose!) and support libraries (require 'rails/all' may not be needed!), instead of looking it as a monolithic black box that can't be configured to fit your needs, it's suddenly a lot less "heavy" and a lot more "wow, okay, buffet-style app composition sort of rocks". People seem to have this idea that Rails is on the far end of the "magical and heavy" spectrum, when it can be just about anywhere along the spectrum that you want it to be, based on your selection of middlewares and libraries to use.

I have production apps that range from small one-off Rack apps (my dynamic asset server, for example) to Sinatra to full-blown Rails, and they're all very similar beasts. Rails isn't some mystical black box, and Rack isn't just some RFC somewhere, and I think it does a grave disservice to both to marginalize them.

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

#108

Post by jebblue »

rbanffy wrote: post #101
nwienert wrote: post #16

Earlier quoted context omitted.

Any new and active programming community should be vocal, and node is no different. In fact, both node and rails have very loud supporters and detractors (IE, you).

I don't think loud people contribute to the health of a community. In fact, I consider it a "community-smell" - when there is too much incentive to be a "rockstar", too many people will focus on being rockstars and not enough will be focus on actually getting the job done.

Right, totally agree, in the Enterprise Java world (love Java, can't stand the enterprise connotation) things ran a muck and we ended up with J2EE. Spring isn't better only different. Too loud voices in any camp just mess things up, then they move on and we are left to sort things out.

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

#109

Post by tluyben2 »

jes5199 wrote: post #61

(I'm a full time Ruby/Rails programmer, and I have been for five years.) There's a major flaw in the R/R culture: they have no interest in maintaining stable APIs. If you want to upgrade your Rails app to the latest version of some library, you might as well do a rewrite of your entire app. So many of the APIs change from release to release that most of your gems will stop working unless you upgrade. When you upgrade…

I do understand the need to refactor and clean up code, however, there is a lot to say for at least deprecating things for a very long time as I find the current RoR far too volatile like you say. Unless you are doing prototypes, short lived sites OR have a fulltime team on it all the time (who upgrades to every small increment of every lib and fixes/refactors/tests the entire project), I don't like it so much. I have done and supported RoR projects and it really takes out the initial wins when you sit swearing behind your monitor because even trivial libs (for which, in fact, you already had to resist the urge not to roll your own) stop working after installing the latest and the greatest. Sure, then don't upgrade to the latest; for a lot of things that's not an option (security would be one, needing another feature this new gem has is another) and it should just give you a nudge 'this is deprecated, please fix' warning for the next year+ instead. If you didn't fix it by then, then at least you were warned plenty in advance.

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

#110

Post by sdwrage »

bonzoesc wrote: post #85
heretohelp wrote: post #56

Earlier quoted context omitted.

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.

Oh you guys/gals and your programmer to carpenter analogies :)
Post reply on HN