This. A thousand times this.

I love C#, I'm quite fond of Visual Studio and Xamarin Studio, but I dread nearly all the auxiliary MS libraries, like WCF, ASP.NET MVC, MSMQ, WCF Data Services, MSTest, and so on. WPF (MS's most recent UI framework) is an odd one out though, cause it kicks butt. Must've been a different team. But yeah, it's terribly platform-specific so not very useful in web tech.

I never understood why so many C# programmers automatically default to these MS technologies without even looking around. This bugs the crap out of me, because the attitude gives C# (and other .NET languages) a bad name undeservedly, and it really limits further development of the ecosystem. Which is a shame, because as this blog post points out, there's a good bunch of really good .NET open source out there.

I very much miss ServiceStack in the list, though. ServiceStack must be the best designed API/backend framework that I've ever used, in any language. The moment you want to handle more than a few URL requests, it beats Nancy hands down. Stuff gets clearer, there's less magic, and somehow you also end up with less code.

> I never understood why so many C# programmers automatically default to these MS technologies without even looking around.

Many C# programmers are C# programmers because they (or, in many cases, their employers) default to MS technologies without even looking around.

Alternatively, many c# programmers use the default stack because they don't treat their client/employer as their personal playing field to try out the latest buzz.

It wasn't that long ago that ASP.NET MVC, EF, and WCF, for example, were new technologies.

How were the early adopters of those unproven technologies not "treating their client/employer as their personal playing field to try out the latest buzz"?

The point is that as an architect you can be very confident that those frameworks will be solid, well maintained and documented and quite importantly well integrated with everything else in the default stack now and in the future. You can also be confident that in the future you will be able to find developers with experience using the default stack. I could bore you with quite a few personal anecdotes that back up my opinions.

Of course there are going to be exceptions to this but as a general rule, taking into account all dimensions of the decision, the default stack is the rational choice.

There are actually many Microsoft shops that still consider the stuff you listed as too new/unproven.

In general, .NET shops are more risk adverse than "open source" shops. Some reasons are cultural, some are business. I think Microsoft is trying to change this as they're clearly growing tired of their own developer base being reluctant to adopt their own technologies.

Case closed (pun intended) :

http://www.twilio.com/blog/2013/07/billing-incident-post-mor...

A project I worked on at a large corporate client got into serious problems after it got audited, and they found we were using several non-Microsoft libraries. They wanted us to remove those and use "supported" libraries such as Unity and EntLib.

We're going to do a longer blog post on this later, but if you don't want to use Massive for your sql mapper, maybe try out:

http://github.com/clotheshorse/destrier

works similarly in that you can map output to POCOs, but will also let you do more complex querying and CrUD operations.

Cool! Impressive that it's even faster than Dapper, too. Personally I'm a huge fan of Dapper but I really like how this is looking. I'll definitely be giving this a shot at some point.

Huge caveat; it's only faster than Dapper after the 1st query when it's built up the cached metadata, and only if you're not using referenced objects or child collections.

The speed comes from dynamically emiting IL for the object population methods.

Ahhh gotcha. Still though, very cool looking project! Having the option to do LINQ-style queries would be nice. I find that Dapper Rainbow rarely satisfies my needs outside of basic CRUD operations.

Looks interesting.

Are you going to build an editor/generator for VS?

Yes, it's in the roadmap (done through T4).

How about PetaPoco?

PetaPoco is awesome and I tested against it for performance (it's a little bit faster).

Some things this has that PetaPoco doesn't are expression visitors for the where clauses and the concept of referenced objects or child collections.

I've become a bit of an evangelist on this recently, but ServiceStack absolutely rocks. Open source and runs on Mono as well.

http://www.servicestack.net/

ServiceStack is stuck on .NET 3.5 unfortunately. No taking advantage internally of dynamic or async; especially async. Kinda sucks.

It doesn't need async. async is one of those things that MS has been pushing that really is a double edged sword. People think "omg I absolutely NEED async now"... when people have being solving scalability issues before MS made it so easy. Now people are going "oh ill just use async" rather than fixing the actual problem for their slow web applications.

I agree with half of the post: using EF and implementing "some sort of repository pattern" with it will often lead to all sorts of problems. That can be fixed by sticking closer to the database, avoiding unnecessary abstractions, i.e. by using RavenDB and a Micro ORM for SQL databases. EF should really be avoided for high-traffic websites, it kills performance.

But what exactly is wrong with MVC and Web API? I actually like those. They are modern and open source. Some of the MVC 4 project templates come with DotNetOpenAuth and provide a fully functional social login system by only adding the client keys. Outside of Mono support, I don't see other advantages of Nany or ServiceStack over MVC / WebAPI.

Testing is easier with both, than it is with Web API / MVC. Both are faster than Web API / MVC. Routing is far superior in Nancy than MVC / Web API. Content Negotiation is far superior in Nancy/ServiceStack than it is in WebAPI.

I could do this all day. You end up fighting the framework using MVC / WebAPI, once you build an app or service with Nancy or ServiceStack, you will be like "wow why was I using the MS stuff so long..."

Move to F#. Then you'll get a very lightweight, far more expressive syntax, while still keeping the upsides of .NET/VS, and using whatever libraries you want.

Indeed, if libraries were designed with F# in mind, they'd allow even more expressive code. The downside with F# is that libraries usually take advantage of C#-specific hacks and workarounds due to C#'s limited type system and expressiveness.

But in general, I've found that even if you aren't gonna commit to F#, using F# as a "better C#" still results in a lot less code.

Article lays out some examples of some things the author thinks make C# better than C#-with-MS-libs.

Doesn't quite lay out how this makes C# a better choice than the other languages mentioned at the start of the article.

Yeah, your right to an extent. The point I was trying to make is not that C# is better than those other languages. More that I was looking to those languages thinking C# was the problem when in fact it was the libraries I was using that were the problem.

Still C# comes with it verbose baggage and it shows, even with your simple example of:

    Get["/"] = _ => "Hello World!";

Or even the class declaration:

    public class SampleModule : Nancy.NancyModule

My RSI is starting to flare again...

Seriously? Your two examples make the counterpoint to your argument.

The first example in Python would be some variant of

   @get('/')
   def whatever():
       return "Hello World!"

Or in Ruby:

    get "/" do
        "Hello World!"
    end

Or in Go:

    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprint(w, "Hello World!")
    })

These other languages, all popular on HN, are nearly identical to the C#, or even longer in a couple of cases. You'd have to go with a project-specific macro package on a Lisp to get much terser.

The second C# is also quite terse, IMHO. What would you have preferred? The equivalent Python would be something like

    __all__ = ['SampleModule']
    class SampleModule(nancy.NancyModule):
        pass

which, even if you want to say well, no one in real life uses __all__ (which isn't correct) is still nearly the same length. I don't quite remember the Ruby off the top of my head, but it, too, is similar, as would be Perl.

Older C# versions could be verbose, but this seems quite terse to me.

It's not so bad when you lean on Visual Studio to do your typing.

I imagine there's some sort of causal relationship between ultra-powerful IDEs and languages that are verbose. The question is: are the IDEs powerful because the languages require them to be OR did the language evolve to become more verbose due to the IDE eliminating most of the pain associated with verbosity? Both? Neither?

A mixture. The verbosity is basically enforced documentation - you're describing more about your code, and how you expect it to work, but that gives the IDE information to help you with that description.

I typed way more doing ruby on sublime than I ever did C# with resharper. I'm writing less than half the code now, but still typing way more.

You are comparing a text editor with a full-fledged IDE.

I type even less on RubyMine. Try it out, it's free for the first 30 days and then it is fairly priced.

>*My RSI is starting to flare again...

I call BS. The same things are just as lengthy in most languages you'd use.

And there's nothing there that does not need to be. You still get the "class" signifier in Python or Ruby, and even more BS on Javascript (the huge word: "prototype").

The only thing that COULD be missing is the "public" modifier, if things were public by default.

1. There's nothing verbose about those two snippets. 2. Comparing a dynamically typed language to a statically thped language and complaining about type/access modifiers is silly.

Besides the C# compiler being able to infer types in almost every situation.

ehh the language is what it is, its a good language within its constraints but if your philosophically opposed to its core tenets you arent going to like it