You seem to have neglected, however, what Rails is really good for. It’s really good for people who have never built houses before.

It’s also really good for people who have been stuffed around by other dodgy prefab companies before – have had their houses built in really bad materials.

It was the first framework that let people focus on the important code decisions rather than the logistics of writing the code.

Truth is, Merb would BE without Rails, and I think you, as developers of Merb, need to respect that.

I’m not in any way bagging out Merb. Merb is necessary and very useful, and I love it a lot.

Now, the interesting thing for me, is that Rails is SORT-OF going down the microsoft route in that it has to maintain backwards compatibility and versioning.

I *hate* backwards compatibility and versioning. There should be versions for bug fixes, but I’m not too much of a fan of versions for new feature sets, changes in API, etc.

What I would *love* is if Merb had a set of releases – For instance Merb “BlahBlah”. Marketing departments might not like this much, but opensource software doesn’t have marketing departments. It’s like “okay, we have a set of goals for merb BlahBlah, and the project will be FULLY COMPLETE when these goals are released” in exactly the same way that unix commands are small, nice pieces that fit together well and should never break their own API’s and syntax.

Does that make sense?

If I have a program, and all it has to do is take one number, and multiply it by 5, then the only “versions” that should be released for it are the versions that fix bugs in it. It is simple, and small, and tiny, and works its job, and that is all it does.

It is, essentially, its smallest part. Why would we need to upgrade it? From a marketing point of view, with Micrsoft Word, or Windows, or whatever, they want to keep making money, so they want to push “upgrading”.

My idea is … Merb “BlahBlah” (or “chocolate” or “puma” or “funky” or whatever you call it) should do ONLY what its spec says. Nothing more. So Merb Core BlahBlah will have a spec, an API, and that is that. It is either finished or it’s not, but it will never do more than its spec says. Thus we have a clearly defined API and we ALWAYS know what it does.

I’m fairly sure this is what you’re trying to do with Merb: to get the simplest set of API’s possible across smallest-possible objects. If all the pieces are very very small, and they all do only one job, and one job well, and they all fit together very well, then fixing it will be easy, changing it will be easy, etc.

In short, I love you guys. :)

Seriously, Rails is plenty flexible for the same target space as Merb. The plugin architecture and ecosystem is a great strength too.

Because Merb is threadsafe, I don’t see any reason why it wouldn’t be able to handle a ton of simultaneous requests in one JRuby process. Ping me on IRC (wycats on freenode) and we can discuss that a bit more.

the more I use merb the more I like. only thing I’m going to miss (a lot) is RPM.

I plan to try out merb once it’s at 1.0 and has good documentation. I think the goal you laid out is a good one. There are a few other things that would lead me to switch to merb overnight (for my personal projects). If I can add another merb application to my site, like a blog app under /blog, AND not have to run 3 more separate mongrel processes for it as I do with rails. Also, if I can run it under jruby and not have to run separate processes to handle simultaneous requests. I can go on, but it’s just the standard rails issues that everyone is aware of.

The first is big for me because I do a bit of consulting and most small/medium sized businesses want a custom site, a blog, and a message board or some such. Having to run 9 processes at minimum is prohibitive to say the least.

I have no idea if merb addresses these issue or plans to, but I’ll switch if it does.

Merb exposes very explicit modular extension points, and we’ve given a lot of thought to exactly how things should fit together. It’s much harder, but the benefit is that we don’t use Ruby’s metaprogramming facilities in lieu of a known developer API, and we can refactor internals much more easily.

In addition, it’s a lot *less* likely that plugin authors will stomp on top of each other (although I agree that you can’t eliminate that possibility entirely). In effect, we’re taking convention over configuration to the next level and handing it to the PLUGIN authors.

“As a result, you lose the compatibility not only in terms of software (i.e. plugins and the like), but also in your ability to hire people who know Rails (well, that or you need more to time to train them).”

more time to train them compared to what? Teaching someone your customizations while leveraging their previous knowledge for everything else (i.e. rails knowledge) is less time than if they had to learn your whole setup.

“Rails lets you paint yourself into a corner, or worse yet, lets plugin authors you rely on paint you into a corner (the company i work with has had that happen). Then you get to spend your time undoing other people’s bad decision making in order to continue moving forward.”

I’ve had this happen as well, but this isn’t rails fault. It’s the fault of the plugin authors and whomever made the decision to use that plugin. I learned very fast that most plugins are crap and I had to review them before allowing them into my apps. Again, this is not a rails problem and you’ll find it anywhere you try to use third party code. Code reuse is hard, period.

“Wycats’s point, as i take it, is that merb is modularized to a degree where if a chunk of your app is causing you trouble, you can just pull it out and replace i”

Again this goes against your argument about training time. Someone coming into a project where you did this will require more training than someone coming into a rails project with some customization.