[chanced]

"Uninspired rails port" is a far cry from accurate. I've worked with both rails and asp.net mvc. I started with rails in the 1.x days but also had clients that used .net. I despised web forms for a variety of reasons so I jumped on the mvc bandwagon as soon as the fist community preview was released.

Hack, Connery, Hanselman, & Guthrie openly acknowledge that rails was a source of inspiration in their book http://www.amazon.com/gp/product/0470384611?ie=UTF8&tag=scob... but so was Spring, among others. Above all, I think the .net mvc framework was trying to capture the fasted-paced, fly-by-the-seat-of-your-pants essence of the rails way more than anything else. In doing so, they unearthed a lot of awesome concepts previously unknown to most .net developers like domain-driven design, tdd/bdd, dependency injection, scaffolding; old hats to Java and ruby guys.

The mvc .net team did an amazing job of breaking stride with the asp.net mentality of letting the framework do as much as possible. Yet .net was still very much confined by it's own structure, forcing the mvc framework to remain rigid. They opted for configuration over convention which, in my opinion, was by far the biggest differentiator in rails to the mvc frameworks that preceded it.

[skrebbel]

They also filled it up to the edge with Ruby-like magic all over the place.

ASP.NET MVC is the only place I've ever seen in mainstream compiled languages where the code can break in untraceable ways if you change the name of a method parameter (f.ex. for controller actions). Or where models suddenly don't get data because you forget to add "{get; set;}" to the code somewhere. Absolutely no way to find out why it went wrong. The data just isn't there.

Sure, you can learn this and then not make the mistake again, but the reason I don't use Ruby or Python much anymore is because I've had with with having to spend a full day going through a framework's source code to find out why my bug is a bug. In an ecosystem and language like C#, you expect things to either work or to get a pretty OK error message, preferably at compile time. The more magic, the more time I waste tracing bugs.

What's the point of using a compiled language if half your code is a dynamic viewbag of string keys and liberal JSON parsers that just ignore fields it doesn't expect or can't fill?

It's just Ruby, but then in Visual Studio.

[dragonwriter]

> Sure, you can learn this and then not make the mistake again, but the reason I don't use Ruby or Python much anymore is because I've had with with having to spend a full day going through a framework's source code to find out why my bug is a bug. In an ecosystem and language like C#, you expect things to either work or to get a pretty OK error message, preferably at compile time.

No, that's what you expect. I expect that the traits of frameworks you describe to be features of particular frameworks and to be largely independent of language, except that in languages that don't provide introspection/metaprogramming facilities that enable them, you probably won't find them (probably, because usually there may be elaborate ways of hacking around language limitations to do magic, and then even examining the source code will make the magic less obvious.)

You can easily have magic-free frameworks in Ruby or Python, and easily heavy-magic frameworks in most (mostly) statically-typed compiled languages like C# and friends as long as they have some introspection/metaprogramming facilities (and optional dynamic typing like C# makes this more viable, too.)

If you want to choose a language so as to avoid any need to examine the traits of particular frameworks so that you don't run into a heavy-magic one, you are going to need a much more limited language than C#.

> What's the point of using a compiled language if half your code is a dynamic viewbag of string keys and liberal JSON parsers that just ignore fields it doesn't expect or can't fill?

The point is the other half of the code. (The part that, in Python or Ruby you might be tempted to drop down to a C or Java [for JRuby] extension to do.)

[bunderbunder]

> They opted for configuration over convention. . .

I believe you meant "convention over configuration", right?

[pmelendez]

convention over configuration is the motto on Rails and ASP.Net MVC is actually the opposite so that's why OP says it was the biggest differentiator between the two frameworks.