RubyFlow The Ruby and Rails community linklog

Your opinions on the Rails / Merb merger are needed!

Someone I know is writing a feature on the Rails / Merb merger for the 2nd issue of The Rubyist (Ruby magazine). He/she will be interviewing several people but also wants to get a general community feel for the opinions surrounding the merge. So, say anything you want here on RubyFlow, get it all off your chest (extreme, intelligent, thoughtful, or otherwise) and you could be quoted and get your name in a shiny magazine article! (If you don’t want to be quoted, make sure you make that clear in your comment..)

Comments

Just to kick it off. I’m ideologically against and pragmatically for. I’m somewhat on the fence. I like the idea of the technical outcome but socially / community-wise I’m not digging it yet. On the plus side, this gives us a chance to get Sinatra into the #2 position ;-)

Great news for Rails, not so sure about how well merb will fare. I also don’t see how they’re going to bring the simplicity of the merb codebase to the tangled alias_method_chain-fest that is the Rails source.

I’m all for anything that pushes Rails further, and ultimately that’s what this is all about. What’s important is that we get the best framework, that is agnostic in it’s library choices.

What it comes down to is duplication of effort and ideologies that aren’t completely opposed to one another. There’s no reason that you can’t have both the full-stack convention-a-thon that is rails and the as-big-as-you-want-stack of merb in the same project. While it was initially necessary to be separate for merb to prove its philosophy to be effectual, keeping them separate now is just duplication of effort. Merb has won. Rails has won. Why be angry?

The information about the merger as stated makes me a bit wary, but I have a lot of respect for and trust in the Merb team with Yehuda and Ezra in particular. In speaking with them in #merb, they seemed very excited about this, so I cannot help but be optimistic.

That said, the wording of things currently is unsettling. This happened because Merb is considered technically better, more sophisticated, and Rails has the backing and the momentum. They merge so that both have both. I have some qualms with the fact that Merb seems to be taking a back-seat in titles like ‘Merb is being merged into Rails.’

I worry that Merb will feel like Rails when it really should be the opposite. This has been mentioned in #merb and, again, Yehuda assures us we will be happy. I believe that, even though it’s all a bit hard to digest.

I am also on the fence. While I do think Merb’s modularity will technically improve Rails, I kinda liked the fact that there were two major choices, along with a few minor ones.

Also, code bloat was pointed out as a major issue of Rails by the Merb guys, yet now they’re adding Merb? I know that’s a bit of an oversimplification, but unless they make modularity the default and full stack the option, most developers will get a heavier Rails gem rather than a lightweight one.

I guess this will push me to explore Sinatra, Camping and Ramaze.

I’m in favor of anything that makes Rails faster, but I also liked the fact that there are several Ruby alternatives that are small and fast. My biggest concern is that as Rails gets more agnostic about it’s libraries (AR vs DataMapper, etc…) that the plugin world will become a huge mess of plugins that only support one or the other or one more-so than the other. I don’t think that will be a good thing in the long run.

If you believe the purpose of merb was to get a few more people on the rails core team, then by all means, merb has won.

If you thought the purpose of merb was to provide an alternative framework with alternative opinions, philosophies, and strengths, then both sides loose.

Abandoning a burgeoning project and community for refactoring rights was a shit choice by wycats.

Honestly, I don’t like it. I was happy with merb’s own developer circle and community and all the points it differentiated itself in from Rails. Those will not all translate over to Rails 3.0, simply because merb will be merged into Rails and not vice versa, and because both projects will have to cut back in order to merge successfully.

I also think it’s a bit of a slap in the face to everyone who wanted to use/used merb to differentiate themselves, be that by contributing to merb isntead of Rails, by preparing courses and tutorials or by doing merb consulting. Merging with Rails will eventually make those people compete with a bigger group or colleagues, who not always produce decent work. There’s a lot of people who got into Rails without learning and understanding Ruby properly (I should know, I’m one of them). Contrasted to that the nature of merb itself - although frustrating with the constant changing - required people who understood the whole stack better, often delivering better work as a result.

I trust the merb core team has good intentions (even if I question the real motives behind the move), but I will remaing sceptical until Rails 3.0 is released. If it’s more merb 2.0 than Rails 2.5, I might stick with it. Else I’ll look for something else, yet again.

Good for Rails, bad for Merb.

I’m really psyched about the merger; I believe the combined Rails/Merb effort will produce an awesome framework. It’s a huge benefit for Rails users, and I for one am very grateful for the contributions of Yehuda and the Merb team. I am concerned about the impact on the Rails plugin ecosystem, however. Right now, Rails plugin authors can jump right in and create something useful because there is only one stack to consider. With more choices, we’ll start to encounter one of two scenarios: 1) an exciting plugin will come out, but it won’t work for “your” configuration of Rails; 2) plugins that would otherwise have been written won’t get written due to the additional complexity (perceived or actual) of accommodating multiple permutations of the stack.

From my perspective, what is there not to like?

The pooling of resources from two wonderful products into a single code-base seems, at the moment, like nothing short of wonderful from here. Each group, from my perspective, brings something unique and worthwhile to the proverbial “plate” and will work not only for the betterment of the Rails/Merb communities, but for the greater Ruby community as well.

Overall, I’m very excited for the Rails 3 release and subsequent releases from this combined team. I think that this is a huge step towards the future for Ruby and Rails as well. Why all the negativity?

Regarding competition/alternatives:

Merb exists because in Rails 1.x/2.x, if you didn’t like (for instance) Rails’ helpers, you were forced to write an entire framework to accommodate your choices.

In other words, there was competition on the macro-level, by necessity. Once Rails has become more modular (and there is progress being made every day; check out my blog), competition will flourish component-by-component.

Don’t like ActiveRecord? Use DataMapper or Sequel, but don’t lose helper integration. Don’t like Rails’ i18n implementation? Write your own and offer it as a drop-in-replacement. And on and on.

The existing state of affairs, where the only effective competition could take place on the macro level, between frameworks, actually obscured important differences that could have allowed for more useful discussions much earlier.

As a result, I expect this to increase, rather than decrease, the competitive spirit, but in a much more productive fashion.

Yehuda, you can be more explicit.

Rails3, as i understand it, will be a standard for a web framework components, PLUS a reference implementation.

This is exactly the same way that Ruby works. Ruby is a programming language standard (which i guess we can represent w/ the specs) AND MRI, the definitive reference implementation.

Competition still exists for the best Ruby (Hi there, JRuby!).

Once the standard is published we can even tell DHH to go fuck himself (Hi DHH! :D ), and keep our own components which can interoperate w/ pieces of the Rails stack, even to the point of having an entire replacement for Rails internals, so long as they adhere to the Public API.

@Andre Lewis

This is a very valid concern and one that we will be very carefully considering. If you have a specific example I can try and lead you through the likely outcomes that would make it less problematic.

I’d also keep in mind that people are using things like Haml, jQuery, and even DataMapper today, but have to roll their own everywhere to get simple features that Rails already provides with the built-ins. Simply ignoring these rather popular options might provide a (slightly) better plugin developer experience for the default Rails stack, but it leaves a fairly large number of Rails developers out in the cold.

I’m of two minds. On the one hand, adding some of the merb folks to rails is a definite benefit. If merb didn’t have a great development team, the merge would never have happened, much less even be discussed.

On the other hand, I do enjoy alternatives. Merb wouldn’t exist if rails was a be all end all solution. While I use rails the majority of the time, I like the option of going a bit more “lightweight” and using merb.

I suppose in the end, the goal of both rails and merb is to provide the best web application development for ruby, and I believe merging the two environments will result in a net gain for both communities.

I guess I’m still on the fence. I liked the little, kind, helpful, almost-rebellious-feeling Merb community. It was a breath of fresh air.

On the other hand, I use Rails professionally, and I’m happy to see it getting a lot of useful features ported over from Merb. I hope the merging of the communities results in a more mature, kind, and intelligent Rails community.

Compromise means both sides are unhappy. It often means each side accepts something they consider less than ideal. That is what worries me.

I should have read wycats and knowtheory’s first. I think my overall concerns stand, but their comments are comforting. Perhaps those who feel as I do should start reading yehudakatz.com, as some of the info is a bit like Chicken Soup for the Worried Merbist’s soul.

I am pretty thankful for this (one less Web-Framework to learn, there are a lots, Paradox of choice anyone?). This will be a huge improvement for Rails, and afaik Merb pretty much did the same job as Rails (from a birds eye view), so why waste any energy and split the Ruby developer base. It will be more productive in the long run, when all the aces concentrate on one framework and try to improve it.

I think Rails is freakin awesome, I really don’t know what’s people’s beef with it. I guess some guys need to be “underground” and “keep it real”, now that Rails has gone commercial or something. It’s become kind of personal life-style choice to some.

You all can be sure that Rails will always get optimized, and I’m pretty certain that even some of the core will get refactored someday. After all it’s on Github, so why invent a new framework, when you can fork the Best (read: most features), and optimize it to your needs. I think more functionality out of the box (while being easy and DRY to use), is more important than being fast and leightweight (which seem to be the things Merb is famous for, and some people are worrying to lose).

Thanks to all you core developers of Rails and Merb for this great step towards each other. I don’t want to get philosophical here, but this is the kind of mentality humanity needs now: Realizing that we all have similar goals, and should work hand in hand, instead of sticking only to our club. Don’t get me wrong, competition is a good thing and led to cool new stuff in this case, but in a lot of cases it leads to less productivity in the long run, especially, when it’s getting so personal.

So as you can see, I’m really excited for this, can’t wait for all those nifty new features.

Peace and out

I bet Ron Paul would love to see these two power players shake hands and bring home the future!

I’m gonna hold out for Rails 10 “Highlander” Edition

As the lead developer of Radiant, which has its own plugin ecosystem, I’m excited to see that greater modularity will be coming to Rails. While I now understand Rails’ initialization process pretty well, it pained me to learn it. I would rather have had a clean API to work with than to monkey-patch everything to death.

Independent of those issues, I think the merge will be a great leap forward, and that the result will be neither exactly like Rails nor exactly like Merb as they exist today. My hope is that it’ll be better than the sum of its parts!

who really cares about merb?

most of my work is done in Rails because it is one stack. what people don’t realize is that we never got to see the ‘bad’ of merb because not that many used it outside of self contained apps. having different ORMs, etc would have been a nightmare with plugins. the one stack, do 80% of what people want is why Rails gets it right and why its ecosystem flourishes.

if you want lightweight, use Ramaze. it manages to be light with enough infrastructure to get things done.

I am excited about the idea of Merb 2 (Rails 3) and so far the signs show that things will be merb-like in the end. However, I will be sure to raise my voice (and my github pull request) if I am not satisfied with how the merge turns out.

My opinions on the merge:

Open source projects are, for better or worse, fiefdoms. There’s only two ways to end fiefdoms: (a) all the subjects leave or (b) the main guy’s head ends up on a pike outside the gate. Neither of those options are pretty.

Having a single fiefdom is dangerous. I’m not talking about competition on a technical level, because I agree with Yehuda’s component-by-component definition of competition. I’m talking about cultural diversity. Philosophical competition. Cognitive agility.

I’ve also yet to see a satisfacory justification for the merge. Anyone who disapproves of the merge has been dismissed and labelled as having an “unhelpful attitude,” the same sort of sinister curtain-twitching cold-shouldering you’d get from 1950’s housewives for snubbing someone’s bake sale or having moderately liberal social views.

Don’t get me wrong, I’m incredibly hopeful for Rails 3 and will be porting all my existing libraries to it for others to use and enjoy. If what the merb team are saying is true, then this is an enormous architectural shift that will improve Rails to the point of being… well. Being sensible and easy to read, rather than written in moonspeak and guided by some sort of stunt-programming aesthetic, like every function has to be the coding equivalent of riding a sealion on top of a motorbike through a burning ring made of spoiled pork.

So, code can be merged. I worry about lots of things apart from code though. I worry about the community, I worry that the ideas of modularity and model/view agnosticism will not be embraced by third parties, I worry that there will be gotchas and buts and maybes in rails-core that also affect the takeup of these ideas. I worry that Rails will continue to primarily appeal to people who want to skip learning, rather than those who want to skip repetitive labour. I worry about popularity being more important than quality, and I worry about the appointment of evangelism teams whose job is to do the listening that other people can’t be bothered with. I worry about lots of things, not all of them to do with the merge. But most of all I worry about fiefdoms, barons and kings. And motorbikes and sealions. And sealions on motorbikes.

I think Rails is freakin awesome, I really don’t know what’s people’s beef with it. I guess some guys need to be “underground” and “keep it real”, now that Rails has gone commercial or something. It’s become kind of personal life-style choice to some.

Wow. This isn’t even a single facepalm moment. Only this will suffice.

Yes, yes clearly this is solely about our need for “street-cred”, and to “stick it to the man”. We certainly don’t care about how our software performs. Or the ease or difficulty of application maintenance.

No this must be about our egos, there simply is no other explanation.

so why invent a new framework, when you can fork the Best

Perhaps you were unaware that Merb has been described as a “clean room rewrite” of Rails. It is for most intents and purposes, a community fork of Rails.

I apologize for having to stoop to derision, but i don’t know what else to do after having my view point (and the pov of others) so blithely dismissed, without so much as even a careless perusal of it’s contents.

I worry that the ideas of modularity and model/view agnosticism will not be embraced by third parties

Dan, even if that is the case, then all that happens is that the developer community stays split 80/20, main stack/alternate stacks. The fact that main stackers will be able to more easily switch to alternate stacks though is a really important capability. And that is a benefit that merbism gains from the merge.

Does it come at the cost of design quality? I don’t think we can tell yet, not enough of Rails3 has actually come together to know whether Rails3 will be a suitable Merb2. Hopefully it will not. The Merb guys are quite good at what they do (the rails guys are no slouches either!), and the merged team seems to be producing interesting work in wycats’s fork of rails!

What’s the beef? Why all the whining and, frankly, hatred?

Why do you like Rails?

Is it the single-stack to get going quickly? DHH says that will stay.
Is it the human-centric method names? DHH says that will stay (see his blog post on Merb’s display/provides).

Why do you like Merb?

Is it the lack of alias_method_chain? Yehuda says it will be gone.
Is it the modularity? Yehuda says anything you can do in Merb today you can do in Rails tomorrow.

So I ask again, why the whining? Do Merbists lose their innate sense of superiority now?

Lastly, show Rails some respect please. Honestly, how many of you would be making a living with Ruby if it wasn’t for Rails? Yet to hear some speak they would be happier writing stuff in VB.Net.

@knowtheory

Maybe I was being a bit provocative there, and not totally serious. But as you said yourself, it’s about performance and a “clean rewrite”. But exactly these issues are being targeted by the merge, too (e.g. look at Yehuda’s posts about this ActionView refactorings).

Again, don’t get me wrong, I really like Merb and the idea to start the codebase from scratch, and put all the ideas from Rails in there (and also add new ones of course). But at this point, it kinda split the community, so IMO it’s the best decision to just improve Rails with everything learned from the Merb experience.

@soleone I’m quite sure that without the explicitness of a merge, and the full-time resources that came with it, the work I’m doing would not have been possible. It’s not about the physical time it’s taking so much as acceptance that fairly sweeping internal changes can happen without them languishing for years.

If you’re following my branch, you know that the rest of the team has given me fairly wide latitude to really go in and clean things up. Again, I don’t think that would have been possible without an explicit arrangement.

Finally, the “clean-room rewrite” of Merb allowed us to prove out a lot of interesting ideas that would otherwise have appeared uninteresting. For instance, ORM agnosticism is no small feat, and I would have understood the Rails team simply dismissing the idea as unproven. Merb gave us the ability to try out a whole slate of ideas without the baggage of the Rails codebase, and we can now bring that experience to the refactor of Rails. In other words, it turned out quite well.

So I ask again, why the whining? Do Merbists lose their innate sense of superiority now?

Lastly, show Rails some respect please.</em>

What i find strange is that Merbists keep on expressing why they have hesitation or concerns, or what potential pitfalls about the merger may arise, and people keep telling them that they are whining, or accusing them of being indier-than-thou, or whatever.

The thing about mutual respect is that it is mutual. Many if not most merbists have worked with Rails for a living. We understand what Rails is. We understand the ways in which Rails does and doesn’t make life easy (Yes it does make life significantly less painful in many ways). We understand and appreciate that people like Rails. I would go so far as to say that I don’t know any merbists who begrudge Rails users for their use of Rails.

However, there does seem to be a lack of appreciation amongst Rails users as to why Merb users prefer Merb to Rails, or even that such a position could be sensible or a valid opinion REGARDLESS of how much explanation is provided.

Finally, code bases are not capable of appreciating respect. Code bases are a tool. Nor do i credit Rails for how wonderful Ruby is. I do appreciate the Rails community for having introduced me Ruby.

@soleone:

Yeh fair point, i think that the fears over splitting up the community between Merb and Rails have been largely overblown. Also, it’s a claim i mainly hear from Rails users. I attribute the fact that Merbists don’t say that, at least in part, to the fact that people in the Merb community are really interested in improving life for the whole Ruby ecosystem, Rails users included. And one of the nice benefits of the design philosophy behind merb is that piece wise design and decoupling mean that it is less difficult to interoperate w/. Things like Rack support fits in perfectly with the Merb philosophy (yes which Rails has too, but Merb had it first :P ).

So i can appreciate that people don’t want the community to fracture or factionalize. My point is that we’re all members of the RUBY community, regardless of what framework we use. I much prefer that personally.

Oh crap, i just realized one of my previous posts has a serious ambiguity problem.

Does it come at the cost of design quality? I don't think we can tell yet, not enough of Rails3 has actually come together to know whether Rails3 will be a suitable Merb2. Hopefully it will not.

The ambiguity can be alleviated as following:

Does it come at the cost of design quality? Hopefully it will not. I don't think we can tell yet, not enough of Rails3 has actually come together to know whether Rails3 will be a suitable Merb2.

I’m not hatin’ or wishing the merger dead ;)

@knowtheory

you were the one saying DHH can fuck himself (even with a smiley).

I have no problem with Merb but Ive had no use for it so far (apart from Sproutcore).

My concerns about the merge were addressed by DHH and Yehuda. Nothing Ive seen mentioned here hasn’t already been acknowledged by Yehuda. He may fail in which case you can complain (and fork). But to keep bitching about stuff he has said he will deal with is whining (and disrespectful)

1) DHH tells people to go fuck themselves, too. 2) “we can even tell DHH to go fuck himself”, that’s a hypothetical. 3) I would probably tell DHH (jokingly) to fuck himself if i ever met him.

I am genuinely glad that your concerns have been addressed regarding the merge. Yehuda and Matt have definitely done their utmost.

But, just because your concerns have been assuaged, does not mean that everyone is assuaged. Nor do i believe that because you are assuaged, are other people some how obligated to be happy.

I saw an interesting tweet the other day:

Rails was the thesis, Merb the antithesis and Rails 3 is the synthesis

For those not familiar with this Kantian approach, here is a quick run down: * The thesis is an intellectual proposition. * The antithesis is simply the negation of the thesis, a reaction to the proposition. * The synthesis solves the conflict between the thesis and antithesis by reconciling their common truths, and forming a new proposition.

The Rails3 synthesis is based on the very same desire shared by both teams. By uniting our strengths, we will be able to provide better code quality and serve the community better. People seem to be concerned about short term challenges such as refactoring Rails internals. While this is a valid concern, people should probably focus on the long term advantages instead of worrying that we won’t be able to do what we promised.

^^ There you have your quote, Peter ;)

It’s not for me, but my contact will be very happy with this :) Thanks everyone!

Post a comment

You can use basic HTML markup (e.g. <a>) or Markdown.

As you are not logged in, you will be
directed via GitHub to signup or sign in