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

31–40 of 127 posts

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

#31

Post by regularfry »

timsally wrote: post #7

> Edit: Contrary to what I said here, José Valim is not stepping down from Rails core, he is merely on sabbatical. My bad. And then later in the article... > Jose Valim, (now former) Rails core member, When you have to issue a retraction, you should update the article. The way the Times does it is to make the edit and then put a small note at the end of the article recording the original error. Like so: http://well.b…

Either way is valid. This way, you don't change the text you originally wrote, which some might view as more honest, and in addition the reader is warned in advance that there's an inaccuracy. As long as they can't come away with the wrong impression, the update's good.

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

#32

Post by bryanlarsen »

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.

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.

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

#33

Post by ascendant »

I was doing servlets and JSP in the mid 2000's when Rails came on the scene. I remember how Rails was the new hotness and Java was said to be slow, stupid and for idiots. I'll burn some karma to say I'm slightly vindicated watching those same Rails people get beat up by kids drinking the node.js koolaid these days ;)

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

#34

Post by cageface »

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…

I said exactly the same thing at the time. The Merb merge felt like it had a lot more to do with politics and ego than engineering. Unfortunately two years is a long time in this world.

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

#35

Post by f4stjack »

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 new and I don't believe I'll encounter any problems. What do you do when you encounter such errors by the way?

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

#36

Post by dcu »

bryanlarsen wrote: post #32
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.

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.

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

#37

Post by nahname »

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 arguing over the location of mundane things. Each team member had a different understanding of REST, so without the rails routing we argued about what we thought an ideal API would look like. We argued about which view engine we should introduce. We argued about how to handle our JS/CS. We argued some more about routes and how to make them more discoverable. On and on. Not intentional, but something new would come up and we would need to figure out where to put it.

This, more than anything, hammered home for me the strength of rails. Rails is great at getting you up and running, but it's greatest strength is that it's idioms are well documented. That gives developers a strong impression of how things are going to be and where things go. This saves you so much time by not having to argue and reach consensus on every little thing.

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

#38

Post by mrinterweb »

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.

You don't need to restart the rails app when running specs if you use spork. Also ruby 1.9.3 vastly improved rails application boot times over 1.9.2, just in case your slow experience was with 1.9.1.x - 1.9.2.x.

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

#39

Post by randomdata »

mtkd wrote: post #5

"Rails is great for JSON APIs" Rails is good for simple APIs (especially adding an API to an existing HTML site). However, if you want to do more than that, elegantly - it isn't great yet. You quickly end up with some fairly messy serialization hacks and confusion between what should sit in the controller and the model. The active_model_serializers gem is a really good start, but there is a way to go to get to the le…

I do agree that the way to provide APIs has been poorly conveyed by the core members. All of the samples end up amounting to:

  render :xml => @objects
Which, naturally, falls apart quickly beyond the most basic serialization. However, as long as you treat the API like any other view (even HTML is just another API format), then Rails does a pretty decent job.

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

#40

Post by programminggeek »

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're absolutely right, you don't need Sinatra to write a JSON API either. The more ruby devs that realize this the better. Really, just people getting out of the mindset that Rails is the be all end all of ruby is all I'm going for.
Post reply on HN