Hacker News Reader

Comment by jpgvm | Hacker News Reader

Generics, Partial Classes, awesome Reflection API, Lambda syntax, LINQ, C/C++ compatibility, async/await, concurrency primitives, etc.

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.

View on HN

async/await is HUGE.

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

FYI emcrazyone, it appears that you have been shadow-banned. I don't have any specific recommendations for your question, but I thought you should know.

Telling people they have been shadow-banned defeats the purpose of it.

It does not serve a purpose to me. To whom does it serve a purpose to shadow-ban that user, and what purpose is it?

In that case, it's a purpose that I don't support.

FYI Python has had an await equivalent for a looong time through the Twisted networking library and now asyncio. It has the same semantics, but you use the yield keyword instead of await.

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.

Having used Python during my time at CERN, I would never use it for anything besides scripting tasks. Maybe when PyPy reaches feature parity with mainline Python.

Tasks are pretty awesome and just about as convenient as Go-routines. Now if we could just get typed channels in .Net >:]

I don't think it would be very hard at all to create a generic CSP system with C# (or F# for that matter). I've built similar systems using WCF.

Doesn't rx fill that role?

With Rx you can do similar things but the semantics are different. When you use an Rx Stream you will get the data pushed from a different thread. With Go-like channels you pull the data from the other thread (or the channel).

How about BlockingCollection<T>? If I understand it correctly you can even have select like sementics with BlockingCollection.TakeFromAny(...)

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

Could you please contrast async/await implementation with Future in Java?

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.

Futures in .NET are tasks and the Fork/Join framework is TPL (Task Parallel Library).

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.

You know what I also really like about C# is the .net runtime. I know that allot of people dislike it because there's so much leftover stuff from previous versions, however despite this it's one of the most comprehensive runtimes I've every worked with.

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.

> Ohh I see you want to write a tcp server with asynchronous processing? Here's some generics you can just c&p.

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.

That's actually one of the features of C#, if something is needed or is hot in another language, it will appear in the core libraries.

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.

This is my main grudge with .NET development, a culture of preferring The One True Way. It (among other things) leads to a lack of .NET FOSS diversity.

The biggest problem with this culture is that it means that when the One True Way is wrong, we suck it up and use it anyways.

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.

Dont mock msbuild.

i never slept as much or as well than when i tried to work through the documentation.

>I've used all three XML serializers in the .NET framework and they're all cringeworthy.

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.

XamlServices serializer. Technically it serializes Xaml, but afaik it can be prodded to produce vanilla XML.

Generic code is made to be copy-pasted. Also, what's wrong with copy-pasting when it lets you write features faster?

It's a code smell that usually means there's something there to be abstracted, or that your API isn't as clean as it could be.

I'd take a bit of copy-paste over premature generalisation any day.

I'd take a premature generalisation over a false dichotomy.

So if its not a dichotomy, what are the other options? If you want to avoid copy/paste, you have to use generalisation techniques.

Yes, and generalisation doesn't mean premature generalisation. It's very possible to just have a well-designed generalisation.

Well OK. But in a lot of cases I see badly designed over complex generalisations ("premature generalisation") because of a phobia of copy/paste. A bit of copy/paste is OK guys, seriously. Wait and see how it goes for a bit and then refactor the general case in later _if_ it seems worth it.

Also it compiles fast and tools are really good.

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.

I would add "yield" to your lits - a small feature, but it allows for very elegant code and easy implementation of deferred evaluation / execution.

Dartlang also will get C# style await async (as of 1.8) and has very similiar syntax. Additionaly it has more CLI oriented tools (eg. pub) and Google ecosystem integration (recent app engine managed vms integration)

I'm happy .NET is going open source path but still think we need others to compete.

I'd like to add extension methods & default parameters to your list. Being able to extend any object with new methods has made programming in C# much more pleasurable then most languages I've used.

Thanks for your extensive answer.

multiple competing event loops for instance

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.

Those type of event loops are for Win32 API GUI applications.

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.

Are Strings a separate entity to built-in types like they are in Java? If so, I find that behaviour odd and welcome C++'s "a user-defined type is not different to a built-in type" approach

LINQ is _the_ only reason I tolerate .net

You mean C#? Let's keep those separate shall we?

Linq makes C# much better, especially compared to java. It's a whole different story in F# though.

What's the story for F#?

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.

F# has Query Expressions[1] which are just Computation Expressions[2], i.e. not a language extension, a library.

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

[2] http://msdn.microsoft.com/en-us/library/dd233182.aspx

[3] https://code.google.com/p/fsharp-typeclasses/

Agree - also I think f# can't dispatch on the return type of a polymorphic expression as I thought that was only possible with type classes?

I think it's possible by including the return-type in the argument list and using inline operators. You really have to jump through hoops though to make it work and the resulting code is damn ugly. Take a look at the source for FsControl[1]. It implements what they call 'type methods'. So there's types for Monad.Bind, Functor.Map, Applicative.Pure, etc.

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.

[1] https://github.com/gmpl/FsControl

oh, this is such a great response to a question that I didn't think anyone would be able to answer - thank you!

I'll have to go study FsControl now ;)

My pleasure :)

F# has a huge momentum at the moment. Quickly rising in the Tiobe index. It's an ML-style functional lang for the CLR. It's not as powerful or pure as Haskell in terms of type system and style, and it is lacking (or is more pragmatic) in a few places to be interoperable with other .NET langs. It has some really cool features though that are quite unique, such as

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://fsharp.org/

F# 4.0 pre-release was just announced/shipped:

http://blogs.msdn.com/b/fsharpteam/archive/2014/11/12/announ...

Reply on news.ycombinator.com