Why I'm no longer giving up on C#(mat-mcloughlin.github.io)

34 pointsby invalid_arg13 anni fa34 comments

mat-mcloughlin.github.io

http://mat-mcloughlin.github.io/2013/07/22/why-im-no-longer-giving-up-on-csharp.html

7 comments

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.

dragonwriter13 anni fa

> 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.

adamconroy13 anni fa

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.

PommeDeTerre13 anni fa

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"?

adamconroy13 anni fa

Case closed (pun intended) :

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

spamizbad13 anni fa

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.

adamconroy13 anni fa

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.

Maarten8813 anni fa

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.

bigdubs13 anni fa

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.

Griever13 anni fa

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.

bigdubs13 anni fa

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.

Griever13 anni fa

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.

joshuaellinger13 anni fa

Looks interesting.

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

bigdubs13 anni fa

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

cmircea13 anni fa

How about PetaPoco?

bigdubs13 anni fa

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.

junto13 anni fa

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/

cmircea13 anni fa

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

philliphaydon13 anni fa

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.

Maarten8813 anni fa

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.

philliphaydon13 anni fa

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..."

MichaelGG13 anni fa

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.

dragonwriter13 anni fa

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.

invalid_arg13 anni fa

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.

sergiotapia13 anni fa

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...

gecko13 anni fa

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.

spamizbad13 anni fa

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?

AndrewDucker13 anni fa

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.

nahname13 anni fa

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.

sergiotapia13 anni fa

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.

coldtea13 anni fa

>*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.

EpicEng13 anni fa

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.

cmircea13 anni fa

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

apalmer13 anni fa

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