

Why I'm no longer giving up on C# - invalid_arg
http://mat-mcloughlin.github.io/2013/07/22/why-im-no-longer-giving-up-on-csharp.html

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

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

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

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

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

------
bigdubs
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](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.

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

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

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

------
junto
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/](http://www.servicestack.net/)

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

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

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

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

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

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

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

~~~
spamizbad
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?

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

