9 ms·

With this release, the .NET world is getting pretty close to the Ruby on Rails development experience: * dynamic keyword * NuGet <=> gems * MVC scaffold <=>

by aymeric 16y ago

With this release, the .NET world is getting pretty close to the Ruby on Rails development experience: * dynamic keyword * NuGet <=> gems * MVC scaffold <=> rails g scaffold The only reason why I keep developing my personal projects in RoR is because of Heroku. Azure is still too expensive.

latch 16y ago
The mvc team is a breath of fresh air, no question. But I'm surprised to hear someone who knows RoR say that they are "pretty close". There's more to dynamic programming than the dynamic keyword. I don't want to get into which is better, but to say that C# is even in the same league as Ruby for dynamic programming, because of the dynamic keyword, is wrong - if for no other reason that properties from anonymous types (which dynamics are built on top of) are internal. Read meta programming Ruby, or try doing extensive [tb]dd with both, and you'll see how different they are (hint, you don't need DI frameworks in Ruby). Ruby gems has a rich history, a strong community, and a proven track record. Every ruby developer has, and uses gems. Most packages are in known repositories. Gems has been extended to solve other problems (bundler). NuGet is a good and necessary start, but, again where you say "pretty close", I'd say "pretty far".
- contextfree 16y ago
  Are you sure C# dynamics are built on top of anonymous types? My understanding is that they are actually more like an untyped IQueryable, with syntactic sugar that turns dyn.Blah into the (rough) equivalent of dyn.Select(Blah).
  - latch 16y ago
    Sorry, you are right. What I was referring to was a dynamic referencing an anonymous type (which is the same as anything else referencing an anonymous type)...Which I still wouldn't write off, because its a fairly common scenario, and even more so when used with dynamics.
- lucisferre 16y ago
  Yeah you could go on for quite a bit with the list of things the Rails experience has over .NET MVC. 1. Ease of deployment, Heroku compared to IIS 2. Scaffolding generation, not as easy to use, fast, or smart. Extremely hard (read impossible) to customize by comparison as well 3. Routing setup, not as clean and nice, harder to customize (though there are some routing projects out there that help) 4. No database migration story I could probably go on if I spent much time thinking about it and I'm a Rail noob compared to my .NET MVC experience.
- luffy 16y ago
  RoR is definitely more of a full web stack than ASP.NET MVC, which to me feels like a micro framework layered over top of whatever in the the world ASP.NET is. Personally, I like ASP.NET MVC's micro fx feel though. You hinted at Ruby not needing DI - for me, that's the biggest advantage when choosing a dynamic language (in my case Python) over C#. IMO, there's something about using DI that just feels wrong (don't mean to start a flame war over that). Anyway, that's why I use F# in .NET land: the type inference provides the best of all worlds. No need for DI, light syntax, and great runtime speed. F# sucks w/ ASP.NET MVC though.

by aymeric 16y ago

latch 16y ago

The mvc team is a breath of fresh air, no question. But I'm surprised to hear someone who knows RoR say that they are "pretty close". There's more to dynamic programming than the dynamic keyword. I don't want to get into which is better, but to say that C# is even in the same league as Ruby for dynamic programming, because of the dynamic keyword, is wrong - if for no other reason that properties from anonymous types (which dynamics are built on top of) are internal. Read meta programming Ruby, or try doing extensive [tb]dd with both, and you'll see how different they are (hint, you don't need DI frameworks in Ruby). Ruby gems has a rich history, a strong community, and a proven track record. Every ruby developer has, and uses gems. Most packages are in known repositories. Gems has been extended to solve other problems (bundler). NuGet is a good and necessary start, but, again where you say "pretty close", I'd say "pretty far".

contextfree 16y ago
Are you sure C# dynamics are built on top of anonymous types? My understanding is that they are actually more like an untyped IQueryable, with syntactic sugar that turns dyn.Blah into the (rough) equivalent of dyn.Select(Blah).
- latch 16y ago
  Sorry, you are right. What I was referring to was a dynamic referencing an anonymous type (which is the same as anything else referencing an anonymous type)...Which I still wouldn't write off, because its a fairly common scenario, and even more so when used with dynamics.
lucisferre 16y ago
Yeah you could go on for quite a bit with the list of things the Rails experience has over .NET MVC. 1. Ease of deployment, Heroku compared to IIS 2. Scaffolding generation, not as easy to use, fast, or smart. Extremely hard (read impossible) to customize by comparison as well 3. Routing setup, not as clean and nice, harder to customize (though there are some routing projects out there that help) 4. No database migration story I could probably go on if I spent much time thinking about it and I'm a Rail noob compared to my .NET MVC experience.
luffy 16y ago
RoR is definitely more of a full web stack than ASP.NET MVC, which to me feels like a micro framework layered over top of whatever in the the world ASP.NET is. Personally, I like ASP.NET MVC's micro fx feel though. You hinted at Ruby not needing DI - for me, that's the biggest advantage when choosing a dynamic language (in my case Python) over C#. IMO, there's something about using DI that just feels wrong (don't mean to start a flame war over that). Anyway, that's why I use F# in .NET land: the type inference provides the best of all worlds. No need for DI, light syntax, and great runtime speed. F# sucks w/ ASP.NET MVC though.