What languages have you got experience with that you feel C# is the best language you have worked with?
And what makes it such a good language for you?
And what makes it such a good language for you?
I have worked with prettier languages, for instance I have picked up Haskell recently, I have also worked with faster languages, C was my forte for many years and I have worked with languages in the GSD category like Ruby and Python.
C# is appealing not because of some feature that it has that other languages don't. But rather the long list of things they didn't fuck up. For instance by building concurrency and evented programming semantics into the core there isn't multiple competing event loops for instance. (unlike say Python or Ruby which have about 5 each, Java has more than I can count).
It's not so much there is one single thing that makes C# really nice, it's the whole package.
Want to make a screenshot of the desktop? Got it. Want to post keystrokes to another application? No problem. Ohh I see you want to write a tcp server with asynchronous processing? Here's some generics you can just c&p.
I know other languages have these features too, but C# makes it so damn easy to use in the stdlib it's just not funny anymore.
So we've come to the point where copy-pasteability is a language feature? Tell me I can use a library or module. Tell me that the language comes with built in features to help me do this or that. But never tell me I can copy-paste generic code. Please.
They've realised recently this is having a negative effect on open source C# code as so much of the community waits for the "offical" version, but it has its positives too, almost anything you want to do is in the core libraries.
I mean, Entity Framework is great, WebAPI is slick, and MVC has its moments, but there are some real trainswrecks. I've used all three XML serializers in the .NET framework and they're all cringeworthy. ASP.Net WebForms could have been something spectacular with open development instead of the hideous monstrosity it was. And MSBuild would have been laughed out of the room and regarded as some kind of bizarre eccentricity like TempleOS or UrBit instead of a serious build system.
i never slept as much or as well than when i tried to work through the documentation.
XmlSerializer, DataContractSerializer, and what is the third? I agree and was about to point out the same thing though; XML serializers in .NET are a joke but because they exist in the core libraries there is not really a compelling open source alternative.
That being said, it seems like the Asp.Net Web API is actually using Json.Net instead of the built-in serializer.
Linq makes C# much better, especially compared to java. It's a whole different story in F# though.
I'm a Haskell enthusiast, but it's not so good at Windows support, or libraries. I've been thinking F# might be just the ticket.
If you know Haskell then it's pretty easy to get into F#. The only thing you'll miss are higher-kinded types. Although they can be hacked in[3], it's not really worth the effort a lot of the time
[1] http://msdn.microsoft.com/en-GB/library/hh225374.aspx
I'm still trying to get my head around it; I thought I'd try to do so by implementing the core types and functions in Haskell's Pipes. So far I've managed to convince the F# compiler to take well over an hour to compile 70 lines of code!
The main argument against them has been lack of CLR support. But it seems that there's already the FsControl way, so I think some syntactic sugar would go a long way.
So yeah, until there's language support for type-classes I think it's probably not worth it.
I'll have to go study FsControl now ;)
Type providers http://fsharp.github.io/FSharp.Data/library/JsonProvider.htm... Code quotations http://msdn.microsoft.com/en-us/library/dd233212.aspx
Most importantly it has become a first class citizen of the ecosystem so the tooling is already great compared to a lot of similar languages.
http://blogs.msdn.com/b/fsharpteam/archive/2014/11/12/announ...
People keep bringing up Scala, last time I tried Scala (~ year back) the compile times were pretty long and the IDE support was sluggish and I have a decent PC. Nowhere near to C#/VS development experience.
It opens an almost frictionless asynchronous pathway from your code all the way down to asynchronous capabilities of the underlying platform. Which was always the problem with leveraging async/overlapped IO: It was too complex and it turned your application logic inside-out because everything had to be performed in callbacks. async/await takes that on directly: You get everything executed in callbacks - only the callbacks are transparently created for you along with the necessary finite state machines so that your code still composes with exceptions, loops, branches working the way you expect - even across those "invisible" callbacks.
For server scalability as well as responsiveness on small devices (keeping number of thread low - even at one - while still serving the UI), that is really an advantage.
There is no "fakes" on the way - no extra threads being started just to wait for completion of an otherwise synchronous API. If the platform supports asynchronous IO/network/disk/database you can leverage that without any of the strange complexities of other languages.
Worth mentioning here is that Windows has an easier scalable and better designed completion oriented async model compared to the readiness oriented model of Linux - which is mostly limited to sockets anyway.
OS X has GCD - which is also a completion oriented model. I look forward to seeing how .NET with real global optimizing compilers from MS will do on OS X versus Linux versos Windows (on a Mac, obviously).
Also as of recently there is a standard library event loop package, and as far as I know Twisted was the defacto event loop on 2.x for most types of work.
Edit: Sorry, messed it up a little bit. BlockingCollection will block your current thread for any other computation and does not allow to await on it.
But there seem to be alternatives: http://stackoverflow.com/questions/21225361/is-there-anythin... http://blog.stephencleary.com/2012/12/async-producer-consume...
From the usability standpoint I see that they are more or less similar. However since you state that async/await exploits the asynchronous capabilities of the underlying platform I'm really curious to know how is this different from the way the way Future is implemented in a JVM.
Async/await allows developers to write code that looks sequential, but is rewritten by the compiler into a sequence of coroutines built on top of TPL, while taking care error propagation happens correctly.
Fortunately Windows has implemented message-passing event loops for you for a couple of decades. And they're pleasant to work with as long as you don't mind everything being a WPARAM/LPARAM.
Server applications like a async socket server use IOCP, a kernel based type of event loop that is highly performant and scalable. And by the way, the .NET CLR already uses them at its core for sockets and other types of I/O.
I'm happy .NET is going open source path but still think we need others to compete.