9 ms·

Why I'm no longer giving up on C#

34 points by invalid_arg 13y ago

sergiotapia 13y ago
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 13y ago
  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 13y ago
    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.
- apalmer 13y ago
  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
- nahname 13y ago
  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.
  - sergiotapia 13y ago
    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.
- gecko 13y ago
  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.
- EpicEng 13y ago
  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.
  - cmircea 13y ago
    Besides the C# compiler being able to infer types in almost every situation.
- coldtea 13y ago
  >*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.
bigdubs 13y ago
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.
- joshuaellinger 13y ago
  Looks interesting. Are you going to build an editor/generator for VS?
  - bigdubs 13y ago
    Yes, it's in the roadmap (done through T4).
- Griever 13y ago
  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 13y ago
    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 13y ago
      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.
- cmircea 13y ago
  How about PetaPoco?
junto 13y ago
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 13y ago
  ServiceStack is stuck on .NET 3.5 unfortunately. No taking advantage internally of dynamic or async; especially async. Kinda sucks.
  - philliphaydon 13y ago
    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.
skrebbel 13y ago
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 13y ago
  > 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.
  - Maarten88 13y ago
    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.
  - adamconroy 13y ago
    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.
    - 13y ago
MichaelGG 13y ago
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 13y ago
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 13y ago
  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.
Maarten88 13y ago
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 13y ago
  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..."

34 points by invalid_arg 13y ago

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 13y ago
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 13y ago
  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.
apalmer 13y ago
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
nahname 13y ago
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.
- sergiotapia 13y ago
  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.
gecko 13y ago
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.
EpicEng 13y ago
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.
- cmircea 13y ago
  Besides the C# compiler being able to infer types in almost every situation.
coldtea 13y ago
>*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.

bigdubs 13y ago

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.

joshuaellinger 13y ago
Looks interesting. Are you going to build an editor/generator for VS?
- bigdubs 13y ago
  Yes, it's in the roadmap (done through T4).
Griever 13y ago
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 13y ago
  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 13y ago
    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.
cmircea 13y ago
How about PetaPoco?

junto 13y ago

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 13y ago
ServiceStack is stuck on .NET 3.5 unfortunately. No taking advantage internally of dynamic or async; especially async. Kinda sucks.
- philliphaydon 13y ago
  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.

skrebbel 13y ago

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 13y ago
> 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.
- Maarten88 13y ago
  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.
- adamconroy 13y ago
  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.
  - 13y ago

MichaelGG 13y ago

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 13y ago

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 13y ago
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.

Maarten88 13y ago

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 13y ago
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..."