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

41–50 of 127 posts

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

#41

Post by bascule »

jashkenas wrote: post #28

To pour a little cool water on this bombastic post -- I have much love and respect for Rails. We (NYT Interactive News) continue to use it for nearly everything we build that requires a server-side component. All I was trying to say (in a direct reply to Jeff) was that I think that putting Rails on hold for 2-3 years while merging in Merb (or the Merb team, depending on how you want to look at it) wasn't, in retrospe…

> But that's old news, and doesn't need to be re-hashed now

Well gee Jeremy, thanks for rehashing it then! ;)

I work on a legacy Rails 2.x app at my day job. Wading through the alias_method_chain soup is not fun. I for one am glad the time was spent to eliminate the technical debt that came from too much feature push in earlier versions of Rails and an underemphasis on code quality. They now have a great foundation on which to add future features (which is more or less what you're saying at the end)

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

#42

Post by JonnieCache »

f4stjack wrote: post #35

Biggest gripe I had with rails is its learning curve. I have started to read Michael Hartl's impressive tutorial book but gave up when I started to deal with errors related to gemfile dependencies (if the versions do not match with the tutorial the expected outcome does not happen at best or you deal with errors at worst). I have bought Agile Web Development with Rails and thinking to start again because it is really…

Run `git blame` on the code pathway that's throwing the exception (in the gem.) Look at the changes that have occurred on it and either move back to a version of the gem that works, or change my code to suit the new version.

Alternatively, look at the changelog or just manually decrement the version number until my tests pass, obviously taking care not to move back past any critical security updates.

Also, the precise version numbers used in railstutorial are available in the code listings here: https://github.com/railstutorial/sample_app_2nd_ed/blob/mast...

The (fast paced|aglie|slapdash) nature of the rails ecosystem does necessitate a certain degree of attention to detail when it comes to versioning. However this applies equally to sinatra. It's worse with node.

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

#43

Post by f4stjack »

JonnieCache wrote: post #42
f4stjack wrote: post #35

Biggest gripe I had with rails is its learning curve. I have started to read Michael Hartl's impressive tutorial book but gave up when I started to deal with errors related to gemfile dependencies (if the versions do not match with the tutorial the expected outcome does not happen at best or you deal with errors at worst). I have bought Agile Web Development with Rails and thinking to start again because it is really…

Run `git blame` on the code pathway that's throwing the exception (in the gem.) Look at the changes that have occurred on it and either move back to a version of the gem that works, or change my code to suit the new version. Alternatively, look at the changelog or just manually decrement the version number until my tests pass, obviously taking care not to move back past any critical security updates. Also, the precis…

Thank you. Far as I understood there is no easy way to handle those errors. I'll take your comment into consideration when I start to learn it.

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

#44

Post by JonnieCache »

f4stjack wrote: post #43
JonnieCache wrote: post #42

Earlier quoted context omitted.

Run `git blame` on the code pathway that's throwing the exception (in the gem.) Look at the changes that have occurred on it and either move back to a version of the gem that works, or change my code to suit the new version. Alternatively, look at the changelog or just manually decrement the version number until my tests pass, obviously taking care not to move back past any critical security updates. Also, the precis…

Thank you. Far as I understood there is no easy way to handle those errors. I'll take your comment into consideration when I start to learn it.

Use the source, luke!

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

#45

Post by dscrd »

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 scheme, and somebody on c2 wrote that python appeals to people like me more.

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

#46

Post by joedoe55555 »

nahname wrote: post #37
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…

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…

My experience is similar. Sinatra is great for one-man-shows or really simple REST apis. For the rest, forget about it...

However, Rails is just too fng complex. It's true what they're saying, Rails-only programmers aren't necessarily Ruby programmers. For a good reason, even the simplest tasks are performed with Rails metaprogramming magic behind the scenes. Idiomatic Rails programming actually means not doing imperative programming which sucks. Programmers want to actually know and control what they are doing.

I once dealt with a legacy Rails app that had really complex Models. ("Fat models, thin controllers") Of course the original designers hadn't thought about every corner case, and of course not thought about what AR is actually able to deal with seriously. The app was just slow and not maintainable.

But to say something good about Rails: creating standard web pages with it is a peace of cake. All standard tasks are automatized.

Great when building but it sucks when debugging and maintaining.

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

#47

Post by samd »

"Modern HTML5/JS apps depend on beautiful, consistent RESTful JSON APIs."

"Rails is great for JSON APIs."

"Many of these companies have client-heavy HTML5/JS applications which consume a JSON API coming out of Rails. Many of them have APIs that are routinely cited as archetypical RESTful JSON APIs."

Rails is great for JSON RPC over HTTP. It's not great for beautiful, consistent RESTful APIs. It still lacks basic support for hypermedia. Without hypermedia you aren't being RESTful and you aren't reaping the benefits of being RESTful. All you have is a weak convention for doing RPC with HTTP methods.

None of those companies are examples of REST either, they're all doing JSON RPC, and propping them up as RESTful does a disservice to REST and a disservice to Rails. How can Rails make progress towards hypermedia APIs if people won't even acknowledge that it's lacking?

I know people like Steve Klabnik are valiantly trying to get Rails to adopt hypermedia, but it isn't there yet, and there are significant technical and political barriers to overcome.

Node.js frameworks, being in their relative infancy, aren't burdened with the same barriers as Rails and have the opportunity to move faster than Rails could. No framework has dominated the Node.js community like Rails dominates the Ruby community; there's still the opportunity for a Node.js framework for building hypermedia APIs to take center stage.

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

#48

Post by joedoe55555 »

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…

You cannot really compare Sinatra with Rails. Rails has scaffolding, DB migrations and all this ultra-highlevel stuff rendering debugging to pure guess-work. Reminds me of doing template-metaprogramming with C++. If it works it's great and the performance rocks, if not you are left alone with cryptic errors and nobody can help you.

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

#50

Post by joedoe55555 »

codenerdz wrote: post #23
nateberkopec wrote: post #10

Earlier quoted context omitted.

Why not use a format-specific DSL, like DHH does with jbuilder? That's not messy at all, it's basically just another TemplateHandler.

Or RABL if you want both XML and JSON output

Or XSLT if you want both Oracle and IIS at the same time
Post reply on HN