Hacker News new | past | comments | ask | show | jobs | submit login
What's New in the .NET Framework 4.5 (microsoft.com)
80 points by Garbage on Sept 15, 2011 | hide | past | web | favorite | 23 comments

I actually think there is a lot here to get excited about. .net forms getting model bindings is quite big, as taken from MVC. Page speed performances, html5 support, web socket support.

It seems to me they are actually taking their head out the sand and realising the web is not all about Microsoft now and there is a whole world of new technology happening around them that they need to include in their products.

I have actively pulled my Silverlight projects now and am concentrating on html5, javascript and websockets since last night. Massive coincidence that this morning Silverlight is getting a bum deal in other press.

I think this is a prelim release to 5 as they want to show their commitment to becoming more engaging to html5 standards and other technology.

Also, there is a comment that this is a weak release for 2.5 years work, .net 4 had a massive amount of work done on it and this is a partial release. The library is already very concise so I would be interested to know what "massive" changes they could make right now apart from just making the library more stable.

Consider this the Windows version (in development terms) of the Leopard to Snow Leopard that Apple released.

All the html5 stuff is in there because of windows 8, pure and simple.

Also I don't know who in their right mind would chose to use classic ASP.Net anymore.

But compared to 3.5 there's nothing in here that I find exciting or that's looking particularly like it's going to make my life as a programmer better. Personally I find the more they work on MVC the more they seem to be giving in to the temptation to put 'magic' in there like the old forms, which sucks imo as it encourages new programmers to write very bad code.

We actively use asp.net "classic" as you have referred to it. It's an alternative and in by no means inferior to MVC. We are looking at implementing MVC3 but to do what we do with asp.net webforms will be a difficult task. We wrote a CMS framework for our own clients and we use quite a lot of specific .net webforms controls to do what we do.

The main reason I started moving away from silverlight and more into html and js, mvc etc was because of Windows 8 not having silverlight as part of the interface.

This is exactly what I mean by Microsoft getting it's head out the sand though, they have chosen to use the more adopted methods going forward than it's own solutions. It's a sign that Microsoft are no longer at the center of the universe.

I'm not putting down your comment on who in their right mind uses "classic" asp.net any more but I find it a little closed minded as asp.net webforms is far more tried and tested. It's a developers choice and it's not a wrong choice to use forms over mvc.

I don't mean to be rude toward the .NET community but I'd have to ask this because it has been bothering my mind a little bit.

Let me begin by praising the CLR and C#. Their latest features are great (both at runtime level and syntax level). But I have not seen something great (or notable) coming out from the .NET communities whether a new library, a new ORM, a new framework, a new paradigm, or even a new tool despite all these cool lambdas, task, linq, etc.

Why is that?

Coming from Java, a language/platform that is considered less superior, where there are tons of good tools like Ant, Ivy, Maven (is NuGet comparable to Maven? or still lagging?), or libraries such as JBoss Netty, JAX-RS, Spring MVC 3.0 (very close to Rails: routes, return XML/JSON depending on request, minus the ORM), JAX-WS (with annotation style programming), EJB 3.1 style programming (which helps a lot!), a few of NoSQL flavours to keep developers busy (Neo4J, Cassandra, HBase), distributed libraries such as Hadoop, I find this situation to be odd.

Two reasons imo:

1. MS advances their product at a semi-decent rate so people just wait for MS to bring out a solution. I don't mean this as a dig, it just seems MS is more plugged into emerging trends in programming. Asp.net MVC came out within a year of Rails and Django becoming popular and lots of MVC frameworks appearing for PHP. I also had just seriously started playing with NHibernate when Linq2Sql and the Entity framework came out. Same with lambdas and all that goodness. They seem to bring stuff out just as people are saying 'hey, this is a really good idea'. I don't see that happening in Java. They get it wrong sometimes, like their over engineered SOAP solution which personally I think contributed to its downfall. Also WCF and WF are both pretty shitty.

2. I think a lot of the other tools is because Java came out first so some of these problems were were already solved when it came to .Net, so we got nant, etc. I personally have never worked on a project where something like Maven seemed worth it comapred to some slight customisations to MSBuild which you can do in VS, so can't comment on that.

You nailed it. The other thing is that .NET devs generally aren't framework devs. They're app devs.

With that said, there are some nice frameworks that exist, but competing against the top framework vendor, Microsoft, is tough. And while most on HN won't understand this, most .NET devs are actually quite happy with what MS is doing -- and most generally feel like MS actually does listen to the dev community.

Is NAnt still around? I thought MSBuild caught the wind and run with it.

I think you're onto something with your statement that Maven might not worth in .NET since there aren't many 3rd party libraries that you would include to your project. That is probably tied to point #1: relying on Microsoft to provide everything.

RavenDB http://ravendb.net/ is an excellent document database written in .NET. It leverages lots of LINQ and C# 4.0's dynamic abilities to provide a really clean API. I'm sure it'll soon be taking advantage of the new async stuff coming in C# 5.0 as well.

It's open source as well. Well worth a look.

I heard about RavenDB but doesn't seem to gain a lot of followers among .NET developers. MongoDB seems to be the choice for .NET communities.

As a .NET dev, I have to kind of agree with you. While I have been quite pleased with the evolution of C# over the years and am stoked about F#, MS's involvement in Node.js, ASP.NET MVC, etc., I can't say that about the .NET developer community.

For the most part, the .NET devs I know just don't care to be involved in community open source projects and/or use those projects as much as you see with other stacks. I do see that changing quickly though.

However, it is nice to see this new respect for MS I'm seeing from non-MS developers lately. Just a few years ago it was pretty depressing, but that seems to be changing.

A few of points:

1) Perhaps you don't use .NET a lot so maybe you're not as aware of all the great tools that are available (open or commercial).

2) .NET developers are more likely to be commercially minded. In other words, their tools aren't always free.

3) There really are a lot of great tools. Check out RedGate, JetBrains, Telerik or DevExpress .NET tools among others. CodeSmith. CruiseControl.NET. See also http://visualstudiogallery.msdn.microsoft.com/ .

The Async / Await pattern looks very cool. This will make my code a lot cleaner and shorter.


Looks like the most dramatic changes will be in writing Metro style Apps: http://msdn.microsoft.com/en-us/library/windows/apps/br23030...


So, the baked-in async / await wouldn't be useful? For the kinds of apps I'm writing, I can't wait for this - I've made a lot of use of Tasks/PFx, and this really simplifies the mental model for me. In addition, I appreciate that it's consistent throughout the framework (as opposed to Node.js, Twisted, EventMachine, etc.)

"await" will be huge. It will just be a while before most of the .net community figures out how powerful it can really be, much like what happened with lambdas and linq.

Overall though, 4.5 seems like a pretty weak release for 2+ years of work. I hope that 5.0 was being worked on in parallel.

Async/await could have been even huger. What the C# designers don't seem to have noticed is that async/await is very closely related to LINQ and could have been built as a new syntax on top of LINQ. Let me explain.

The core of LINQ essentially the same as the core of F# computation expressions and monadic do-notation in Haskell: two operators Return(x) and Bind(m,f). The name of Return is datatype dependent in LINQ, but its purpose is to create a container with a single thing inside. E.g. for IEnumerable Return(x) creates an IEnumerable with a single item x in it. Bind is called SelectMany in LINQ.

F# has something similar to async/await in the form of asynchronous workflows. It is implemented on top of computation expressions, i.e. monads. The F# async feature is similar to the continuation monad. But the F# designers didn't limit the computation expression syntax specialized to asynchronous computations, it actually works for any monad. For example for sequences (=~ IEnumerable in C#) and parsers and probability distributions. You can also do these same things with LINQ: you can do asynchronous computations and parsers, probability distributions, reactive streams (Rx) and many other things with LINQ.

The trouble is that the C# designers have limited the async/await syntax to just asynchronous computations. That means that you cannot use the very convenient async/await syntax for anything other than the async "monad". Had they not limited this feature and had they built the feature as a new syntax on top of the LINQ operators then you could use it for IEnumerable and parser combinators and anything else that implements LINQ's SelectMany method. Specifically async/await is limited to monads where Bind(m,f) invokes the continuation f exactly 0 or 1 times.

For the people who are familiar with the theory around monads, C#'s async/await basically correspond to Moggi's monadic reflection and reification operators. The async operator reifies a monadic computation (in this case limited to asynchronous computations) into a data structure, and await is the inverse that reflects a computation represented as a data structure into the computation.

That is:

The operator async takes a block of code representing an asynchronous computation returning a value of type T and turns it into a Task<T>, and await takes a Task<T> and runs it as an asynchronous computation returning a value of type T.

The operator reify takes a block of code representing a M-monadic computation returning a value of type T and turns it into a M<T>, and reflect takes a M<T> and runs it as an M-monadic computation returning a value of type T.

What the C# designers don't seem to have noticed is that async/await is very closely related to LINQ and could have been built as a new syntax on top of LINQ.

Considering the C# designers include Erik Meijer and work closely with Don Syme, I find it hard to believe that they didn't notice this. But you're right, it's not as powerful or general as what is in F# (which I really need to learn better, as every time I look at it, I want to code in it).

I suspect the C# designers looked at what one of the biggest problems they have is, and it is asynchronous computation (especially w/ respect to the UI thread) and said that F# async workflows solve this problem. But too generally. What do I mean by that. With the current C# solution the syntatic changes are minimal to a completely sequential program. It's not as general, but easier to write and understand.

I wouldn't be surprised if C# added async workflows full on in a future version, when they'll point to async/await and say "you've been doing it for years -- it's not hard at all!"

The full power of F# async workflows can be had with the same syntax async/await has now. Basically async workflows could have been a more convenient syntax for let! in F# async workflows, in the sense that you can directly apply await inside an expression instead of having to insert a let statement:

    ... Foo(await m) ...
Instead of, in F#:

    let! x = m
    ... foo x ...
It is certainly possible that the C# designers did recognize the possibility to make await work for any monad, but decided against it because it could possibly result in confusing code or worse performance.

If that's the case then it would be great to hear the reason from one of you who are on the C# design team and reading news.yc :)

If that's the case then it would be great to hear the reason from one of you who are on the C# design team and reading news.yc :)

I'd second that. Maybe someone @MS could send this to the Async team?

That's rather interesting actually - nice bit of reading - thanks :)

I did kind of passively think that more syntax was not the way to solve these problems but shrugged it off. I've been slightly worried about the complexity of C# after some awful decisions (nullable types for examples).

Actually I think the syntax is quite nice, it's just a pity that the usefulness is limited to asynchronous computations.

This wasn't mentioned in the article. I'm using "vanilla" threads. But yes it is an improvement for PFx users.

Agree, async is going to be huuuuge :)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact