Live data from Hacker News

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

unlimitednovelty.com

51–60 of 127 posts

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

#51

Earlier quoted context omitted.

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!

but I shouldn't get cocky, eh? :)

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

#53
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…

Also, the Django docs is awesome. Nothing gets into master without proper documentation.

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

#54

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…

I just want to chime in and say that you guys at NYT Interactive always inspire/blow-my-mind. Thank you for doing dataviz right.

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

#55
post #29

Earlier quoted context omitted.

Sinatra has a lot less boilerplate than the typical Rack app.

Because it has a lot more "ceremony and structure". Sinatra is a Rack app. It hides the raw boilerplate from you just like Rails hides a lot of the boilerplate you end up putting into a Sinatra app of any significant size. There's a continuum of "more manual work" "more framework", and there's no one right answer, even for something like a JSON API.

Rails is a Rack app too. While I agree there are diminishing returns the lower in the stack you go, your original reduction is misleading.

The choice between Sinatra and Rails can reasonably be debated, but there's little reason to write a JSON API in Rack unless you need control of protocol details that neither abstraction provides. Sinatra/Rails are frameworks, Rack is middleware.

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

#56
post #37

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…

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.

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

#57

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…

https://github.com/spastorino/rails-api

Problem solved.

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

#58

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…

The Rails Tutorial is at least as up-to-date as Agile Web Development with Rails. For example, two weeks ago I bumped the version of RSpec used in the tutorial, fixing a few minor bugs in the process. Just be sure to use the online version at http://railstutorial.org/book or the most recent ebook from http://railstutorial.org/ so that you get the freshest copy.

If you use the Gemfile at http://railstutorial.org/gemfile in a clean Ruby environment and run bundle install, the issue of dependencies shouldn't even come up. If you continue to have trouble, drop me a line at admin@railstutorial.org.

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

#59
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…

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 f ng 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 impe…

The more abstraction you shove down the programmer's throat, the less he will understand what's really going on behind the scenes. Eventually the abstractions become more of an impediment than a panacea, e.g. when you try to do simple things. And we also end up with the creation of "leaky abstractions", since programmers who create them have developed a love for abstraction (what might contribute to that?) but little understanding of the lower levels.

There was a recent post on HN regarding /usr/local that seemed to suggest some programmers do not understand what a partition is nor should they need to become acquainted with such unimportant details. I hope I'm wrong in that interpretation. Because if true, that is just sad.

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

#60
post #37

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…

Padrino (www.padrinorb.com) is a sinatra-based 'rails without the bloat' framework.

It provides generators, basic helpers (link_to etc.) and, most importantly, it gives project a sane structure. Oh, and it does not tie you to any fixed set of components. Using Padrino and Sequel is a bliss!

But your app remains a sinatra app, small and elegant. Also, the documentation is excellent.

Post reply on HN