C# 6.0: An Introduction | Hacker News Reader

C# 6.0: An Introduction

booker.codes

123 pointsbookerio81 comments

Fyi, Mads Torgersen from Microsoft has given several "What's New in C# 6.0" presentations:

https://channel9.msdn.com/Search?term=torgersen#ch9Search&pu...

You can pick the 7 minute quick overview, or the 1 hour session at Ignite2015.

(Side note to the poster... your blog layout displays a constant masthead using over 40% of the width. A technical audience for your blog might find it excessive to have that much space dedicated to "brand awareness" about your availability to create custom websites.)

Indeed, those are some really nice resources. Thank you for mentioning them.

In response to your side note: 40% is a bit of an exaggeration (unless your resolution is extremely low) but I do appreciate your point - I can see how the masthead might be a bit obnoxious. I will tweak the theme accordingly in the near future. Thanks.

> 40% is a bit of an exaggeration (unless your resolution is extremely low)

No, it's not exaggeration.

I'm measuring the width of your actual text content. I'm guessing you're measuring the width of the browser window which is not relevant to the ratio calculation.

Your masthead takes up 530 pixels. The total width from left edge of masthead to right edge of actual text is about 1296 pixels. On my Chrome browser, even if I maximize the window (press F11) to be 2560 pixels, your text content still maxes out at 1296 pixels (which leaves 1264 pixels of empty space on the right).

40.9% = 530/1296

His layout seems fine to me. Out of curiosity, I shrunk the sidebar down to 20%, but found that the main difference was that it made the content's line length uncomfortably long to read.

Agreed, the sidebar width is overwhelming. On the other hand, if the purpose of the blog is to advertise his services then the sidebar being obnoxious might be the point, however unpleasant it might be.

This article doesn't seem to have any info on the syntax changes yet - here's a run through: https://github.com/dotnet/roslyn/wiki/New-Language-Features-...

Out of interest, how many people here actually use async methods? Excluding being forced to by a library.

They haven't revolutionized my code at all. I can't decide if I'm too stupid to realize when to use them, or if they're really just a bit useless for most normal code. I can see the point to it, it's just that most of the time I'd consider using it, it just isn't worth the extra effort. Usually seems to be a premature optimization.

Lambda expressions, now they revolutionized my code completely.

It isn't the end of the world in .Net but it will be the difference between a server handling fewer than 10K simultaneous requests and over 100K on modern hardware.

In general, as much as possible service could should be async... That said, a lot of code isn't. The breakup of the request pipeline and thread pooling in ASP.Net make it slightly less necessary, as it's still very efficient.

That said, you should probably introduce it using Parallel Linq as much as possible, and/or when you need to consume multiple resources in a given request.

If you're writing stand alone applications, and already using threads/thread pools, then it's probably less of an impact. If you're writing server/service applications then it does make a difference in terms of scalability.

But that's kinda my point, I don't use it because it makes the code more complicated, it's a premature optimization. C# is already blazingly fast.

To put it in context, 10K simultaneous requests is 10 billion page views per day (10000 * 10 * 60 * 60 * 24, assuming 100ms processing time, which is actually pretty high for .Net, mine are usually 60ms even on crap hardware. Yes it's a silly calculation, but it gives you an idea about the scale we're talking about). If you're at that scale, you can afford to hire John Skeet to go back over your code and add a few `async`s into it where appropiate.

From what you just said it seems that anyone using it all the time is unnecessarily cluttering their code.

I don't think that it's really a matter of cluttering code all that much... the keyword implies the intent and should be relatively easy to understand. Then again, I've spent about half my time in node the past few years, and getting async/await with babel makes the world easier to use.

Also, It's not like it doesn't do you any good. With async you may be able to reduce the size of your cloud instances, as an example... saving money in the end. Doesn't mean as much if you have a dedicated server, or existing codebase though. If you're doing a green web project, you should probably use async from the start.

In general, denormalizing and caching data, and using async requests are what improves overall responsiveness in an application. Async allows for a given request to have more than one outbound IO statement waiting for a response, and return the aggregate together.

Yes, but how many C# projects ever need that scale? If it's an internal enterprise app, the bread and butter of C# apps, it's a totally useless optimization. It wouldn't reduce the size at all.

The kind of web scale business that should be using async, let's be frank, those kind of projects don't use C#. Go look at the YC list of technology, not a single C# user on there.

If that's all you the benefit of using async is, it hopefully looks like I'm ok not using it.

But even in the enterprise responsiveness is appreciated... if you're making multiple calls on the backend... resource authentication, related item lookup, and other services, if you can run all of these requests asynchronously, then it's the max of those items plus a little overhead for conjunction... not using async is the aggregate... it's the difference between a sub-100ms response, or over... 100ms is nearly transparent, more than that is not.

I don't disagree that it isn't that much of a benefit in many cases, but tbh if I'm to chose between async usage and, for example ever seeing EntLib Data classes, or a DI/IoC tool when no testing is being done, I'll take async. There are plenty of practices in C#/.Net shops that are just hideous to work with, async imho isn't one of them.

We have a site that hits 10k simultaneous requests all the time and we do not get 10 billion pageviews per day. Here's a few reasons why:

Most sites have a peak load. Some of ours have a difference of 4x from peak to trough.

Traffic bursts are also common. Especially if something is going wrong. You should always plan for something going wrong.

Nothing sucks more than going down because of a traffic burst because you just brought your systems back up from a failure. In the past we didn't always plan for this and it could take an hour to get the site back to full health even after we fixed the original problem.

That's what I meant by a silly calculation as it assumes uniform load. But on the other hand, you've been so tight lipped about the actual details, I have no idea what to make of that. What is your normal response time? 60ms or 6 seconds? What tech stack are you using? What is your actual daily traffic?

Async has nothing to do with C# being fast. In fact, the faster C# is, the more you need async, because the more the % time blocked will increase.

Ideally, you'd have one thread per CPU. That's the most efficient. In reality, enough stuff blocks we gotta throw extra threads to let things saturate.

You can scale up the number of process-scheduled tasks much more than the number of kernel level threads. (Though, esp on x64, people might get really far just spamming threads.)

That's mixing speed up with volume. It would only matter if the volume of requests was higher too. If everything runs faster, the number of required threads goes down as the requests will be less likely to happen at the same time.

Scenario 1

    inbound service request
    request remote resource
    wait
    request additional details for logged in user
    wait
    request X info
    wait
    resolve inbound request

Scenario 2

    inbound service request
    async requests
      request remote resource
      request additional details for logged in user
      request X info
    wait
    resolve inbound request

Scenario 2 will finish quicker...

I can't think of a perfect example for using async other than imagining your application is pulling in stock ticker quote on demand. Some of those quotes will be old so you have some logic that removes them so to keep the ticker marquee fresh. While the method responsible for culling ticker quotes need not be asynchronous the method responsible for getting the ticker quotes themselves may be best suited for an asynchronous call if the data source is remote (like a web service). This way the rest of your application can still do whatever tasks that are essential while the ticker quotes trickle in from the async method. You just have to deal with the possibility that when it times out you'll have a gap in the data being displayed which is trivial by comparison to writing the entire application synchronously where any minor delay can stop its operation.

Highly cache-friendly data that can tolerate being slightly stale should be cached or kept in application memory, where the most recent version is returned. In this case, if the data is being used from a foreign source, then a separate thread processing a stream of incoming data that updates a shared/static state may be best.

Requests as part of a Service pipeline are best served as async. User -> http -> service endpoint <(requests to db's, and another service as async)> -> async response

In general, if you are IO bound (waiting on IO/service responses), then you will be well served with async. As part of a service pipeline that will access multiple backend resources it makes a lot of sense. If you can share/cache foreign data sources, it makes less sense. Cache first, other optimization strategies second and as needed. Unless it's a green project, then try to be async from the start.

It sounds like you're talking about multithreading in general rather than async specifically. If you don't need multithreading then you don't need async... that's not too surprising.

I write an application that previously wasn't using threading to avoid blocking the UI. Certain long-running tasks would freeze the app for some time. It's not a big deal since it's an internal app for my work team, but now that the async syntax and semantics are a bit easier, I've started using them and my app is more responsive.

Async doesn't do anything fundamentally new. If you already implemented multithreading in your application that you're happy with, there's no compelling reason to switch to doing it the async way. But for new development it seems like it should be the default.

I thought WPF did that for you? I only ever used Silverlight but I seem to remember the UI was on a different thread to the rest of it anyway.

> Async doesn't do anything fundamentally new.

This is correct, but not in the way you're describing. The API calls that it ultimately makes have been in place before C# 5. C# 5 just made writing that kind of code significantly simpler than it was before.

> If you already implemented multithreading in your application that you're happy with, there's no compelling reason to switch to doing it the async way.

This isn't necessarily true.

From the perspective of a client application, it's less resource-intensive to use async code than to spin up another thread. On mobile devices that's less battery life used, which is always a good thing.

From the perspective of a server, multithreading only gets you so far, plus they can eat up tons of memory in the process. Async code does not spin up new threads and allows for spikes in traffic to be handled gracefully rather than (a) using tons of threads, or (b) being unable to handle the load at all.

A pattern that i am finding a lot is using await on a single call async Task, so it pauses the current thread waiting for that single call to finish in another thread.

It looks like multithreaded code, it taste like using multithread technics, but it is sequential code with thread jumping.

The only benefit that I have found is that in winforms apps the call to back end does not block the ui thread. Otherwise it is just silly.

On the code revolutions, lambda expressions and half implemented linq. I call it half implemented because I am missing the ability to yield return to 2 separate IEnumerables from inside the same method, think results and errors.

Think of it this way:

What happens when IIS runs out of threads?

Without async code, it queues of requests and users sit there getting nothing from your server.

With async code, that's not the case! Well, until you reach the limit of what async code does, but that limit is quite high.

Typically a request thread that ends up blocking on I/O in some way (like accessing a database) sits there doing absolutely nothing for a very long time. The time it takes to get data from a database could be spent servicing many, many more requests! Async does just that. And before you ask, it doesn't spawn off any threads ... it leverages the asynchronous nature of the operating system to service I/O requests. It's actually really, really rad.

> Usually seems to be a premature optimization

If you have a user-facing system, it's most definitely not a premature optimization. If you know, for a fact, that you'll never need to worry about responsiveness, they're not worth it.

There are 32,768 threads in the thread-pool on a 64bit machine. How many do you need?

> How many do you need?

That's an irrelevant question until you legitimately need to scale out. Async code lets you scale up so that when 32,769 users access a site relatively at the same time, you don't force a user to wait for IIS to free up a new thread.

> 'to wait for IIS to free up a new thread.'

Apologies if I'm not following your train of thought here. The thread-pool has the threads right, not IIS? When you do something like Task.Run(...) the task-scheduler will schedule your work on a thread-pool thread (32,768 pre-allocated at start-up). Of course you have to wait for the scheduler to give you one of the threads from the pool.

Are you saying async doesn't need threads/TPL? I know it has some funky concurrency stuff that allows interleaved processing (rather than thread-pool processing), is this what you're referring to? Even IO would have to do something like this behind the scenes:

    Result IOMethod()
    {
       EventWaitHandle wait = new AutoResetEvent(false);

       // Do your IO - pass in the handle

       wait.WaitOne();
       return result;
    }

Wouldn't the pre-IO and post-IO need to be run via the scheduler if you want it to run asynchronously? The WaitOne will release the thread back to the pool. How is async any different?

Ok, did a bit of reading for myself. I had obviously only vaguely took in what was said when it was first released as a language feature. So async will run all code on the current thread, until it gets to some IO. At that point it switches to running the code that you'd normally expect to run asynchronously. Once the IO returns it runs the remainder of the async 'closure' (for want of a better word) with the result. A kind of coroutines system, I guess similar to node.js.

Yep! The async model in node.js is very similar.

Here's a fantastic blog post about the details of it all: http://blog.stephencleary.com/2013/11/there-is-no-thread.htm...

There's no way it's creating 32k threads on start up. That's the default max. Threads aren't totally cheap so they alloc a lot less. Asp.net allocates more. Used to be 25 or 50 per CPU.

async doesn't use threads.

Async is a goto state machine. While the IO is set as blocked at the operating system level, it does something else. Then when it's unblocked, it jumps back.

I'm still having a hard time with async. I see lot's of async code using Tasks, pretty much 99% of the time. Wouldn't this make async code using threads anyway?

A task may or may not be run on another thread. It just represents a unit of work with a potential result.

It can be confusing because Task objects original main use was running stuff on background worker threads. That is no longer the case.

Note, you can use async and threads. But a lot of code using async and task are NOT using threads.

Async code, down in the "guts" of the system, will borrow user-level and OS-level threads, so while it's correct that it does use threads, it won't spawn off new ones. Spawning off a new thread ultimately wouldn't accomplish much (after all, why not have IIS just use a new one?).

I like to think of it as utilizing the operating system more efficiently. I/O on a system is asynchronous by default. Async code will essentially delegate work so the OS can do what it does best!

Each of those threads has a stack allocated to it - and from what I understand, the CLR will actually commit a megabyte of RAM for every thread. You really don't want to have all of the threads permitted in the threadpool up and running at once if you can avoid it. Async allows you to handle 32000 simultaneous requests without having to have 32000 threads and 32000 stacks active at once.

This is another similar answer: http://blogs.msdn.com/b/dotnet/archive/2012/11/13/the-net-fr....

I use it to stop any long running io blocking my thread.

The async features are nice for when you need them, but just because the functionality exists doesn't mean you should use it all over the place (sounds like you aren't anyway :)). A good developer will know when/where to use async.

The style is great if you have a main thread you need to keep fast and responsive.

Async methods are mainly used in .Net apps that use an UI-thread paradigm since you avoid blocking the UI thread for things like IO calls

Async is fantastic if you do a lot of I/O and you have to scale. For instance if you have a web service that makes a lot of network calls.

In our particular case, and oversimplifying, the app is a smart router. Take a request, farm out pieces of it to multiple other servers, aggregate responses. Some of those requests finish in 5ms, some take several seconds, which is a crappy pattern to deal with. Today's not a particularly busy day, so we're doing about 70 req/sec/VM at 5% CPU on a dual core VM. In load tests I've had it up to 300 req/sec/VM with no problems. It actually bottlenecked our 10Gb network cards before the the CPU maxed out.

I haven't tried running the actual app without async because it would be a major rewrite. But I did some benchmarking making lots of parallel HTTP calls with threads vs async, and found that async was 10-20x faster and used less CPU.

> Out of interest, how many people here actually use async methods? Excluding being forced to by a library.

We use it almost exclusively. Because of the new async/await syntax it is (almost) as easy to write and get correct as non-async code.

Async/await makes an entire class of problems go away (and, ok, swaps it for a class of easier-to-solve problems).

In a web application you always need to consider how your application will be impacted by the traffic. Are all of your requests served within 50 milliseconds? Fine, then you do not need async. Do your handlers ever call out to an external site or even a local database where it may block for more than 50 milliseconds? Then you need to consider what happens when almost all of the requests block at at same time: A colossal waste of resources.

Traditionally we have handled this by increasing the number of threads we allow the server to use for serving requests. However, threads are expensive in overhead (memory, cpu for context switching) and it affects the footprint of your application, and with that how dense you can pack virtual servers.

Enter async: When a request blocks on an external call (to an external site, database etc), the request relinquishes the thread which will be used to serve other requests.

What's more: The more you use async/await, the more the application will auto-scale. It will only start new threads when there's actual work to be done rather than when there's waiting to be done.

I take the opportunity of this thread to ask for good ressources and books to learn C#, .NET, databases. I have a background in C, C++ for embedded systems but I would like to learn higher level stuff. Any recommendation on where to start? The final goal would be to be able to switch career from embedded to higher level development.

C# isn't hard to learn , it's one of the easiest language to pick up , and Visual Studio will make you productive in no time. The hardest is usually the APIs and diverse libraries and frameworks you'll have to know, what do you want to do ? Web dev? windows apps ? Plural sight has good education material that covers all these topics.

Check out https://github.com/quozd/awesome-dotnet :-)

If you know C++, the C# will be easy for you. Pick a program you have in C++ and convert it to C# (well maybe not an embedded one; just yet :-). You can download a free copy of visual studio community edition (https://www.visualstudio.com/products/free-developer-offers-...) and go.

Feel free to PM me if you get stuck. I'm no one special but have years on the stuff (and was in c++ for years prior).

C# the language is pretty simple, or at least it can be - you can produce some monstrosities if you really try, but some of the gnarliest bits of C++, like arbitrary operator overloading and template abuse, are pretty blunted. The difficulty lies in the extreme breadth of the ecosystem - just the libraries built into the .NET framework itself could take you years to acquire a healthy knowledge of, not to mention the couple dozen most-commonly-used libraries on NuGet.

Ultimately, I think the best thing to do is just jump in and start a project that you're interested in. Accept the fact that you'll be hitting StackOverflow all the time, and when you're there, pay attention if you see comments and answers from Jon Skeet, Eric Lippert, etc. There are some decent email link-dump newsletters that are good and have a .NET slant, like Morning Brew[1] and Morning Dew[2], which can help keep you up on what's new, and often link to articles explaining various nooks of the .NET world. Avoid CodeProject - most of that shit is old, poorly written, and as often as not incorrect. Once you have your bearings a bit, C# In Depth[3] is a great resource on the nittier, grittier details of C# and the .NET framework.

[1] http://themorningbrew.net/ [2] http://www.alvinashcraft.com/ [3] http://amzn.to/1fv0zNH

C# is super simple compared to doing C or C++, especially at the embedded level.

If you are just getting started I always recommend the msdn tutorials.

https://msdn.microsoft.com/en-us/library/aa288436%28v=vs.71%...

.Net In a Nutshell, flip through it for the syntax reference and an overview of the APIs.

Download Visual Studio Community (if you don't already have it) then try out one of the project templates. The tooling is excellent and it's very easy to get started.

Then it depends on what kind of code you need to write. I work with web/information systems so the focus is on SOLID over pure performance. Using DI and TDD is more important than being an absolute language expert.

Drop me a line if you want more details tips; I've helped a number of people make the transition. Email is in my profile :)

Seconded, I want to escape the low-level ghetto as well; my mind desperately needs to think in higher level abstractions, too many years down near the metal is enough.

You may find Rob Miles's books helpful. He wrote on C# basics, C# with XNA, C# for windows phone. (Rob Miles is a professor of University of Hull, UK)

You've gotten some good responses so far - I'd like to chime in as I'm still in the 'early-stage' of learning C# myself.

A book that should get you up to speed on 90% of C# relatively quickly is Professional C# 5.0 and .NET 4.5.1 by Jay Glynn. It's not got info on C#6 and .NET 4.6 yet, but the differences there are pretty quick/intuitive to pick up.

Afraid I can't help to much with the databases portion - it's something I'd like to find a book on myself! Good luck on the career switch! (:

FYI Alex:

> Read-Only Auto-Implemented Properties - Allow you to omit the getter from an automatic property, which makes it read-only.

This should be omit the setter right? :)

BTW, is there somewhere I can get notified as the new chapters become available? I'll probably miss the tweet and I don't think this is your blog?

Thank you so much for pointing that out. I have [updated](https://github.com/alexbooker/articles/commit/735f8558851ce3...) the article.

Thank you for your interest in the series, too. If you want to be notified when new articles come out, you could [subscribe](https://booker.codes/rss/) to the blog via an RSS client or you could "watch" this [GitHub repository](https://github.com/alexbooker/articles).

There seems to be a bug at the end of the first page ('an introduction'), where the link to the subsequent page loops back to the introduction page!

Just to put it out there: If you like C# the language but rue the fact that it will execute on a VM layer, you might want to take a look at D. Especially if you are into number crunching with small memory footprint, it seems C# is not a good language for that. Otherwise, there is really a lot to like about C#

C# doesn't "execute on a VM layer". It's compiled to native code before execution, in a process known as JIT.

http://www.telerik.com/blogs/understanding-net-just-in-time-...

Given the scarcity of non-scripting language VMs that do not use JIT, this is what I mean by VM layer nowadays.

There is whole lotta difference between execution of a "AOT compiled to machine code, potentially profile guided if need be" program and a "selectively compiled under severe time pressure that precludes deep compiler optimizations" one, much that JIT camp would like to brush under.

There is still a substantial gap between the pregnant promise of a JIT and its delivered performance. The gap that needs to be bridge does gets narrower by the year though. [Mono does have AOT compilation, but I had given up on a then buggy Mono and haven't found enough motivation to go back. Should I ? A non bugged F# on Linux would be really sweet.]

Under circumstances JIT can, and do outperform, but those are not nearly the common enough cases and configurations, at least not in the number crunching world. And some of the scenarios that get held up in JIT's defense are plain hypothetical, 'for arguments sake only'.

C# is much better than Java about interoperating across the managed - non-managed bridge, D is significantly better still. The poverty of the C# eco-system in number crunching libraries, or even production quality glues to native number crunching libraries, is really stark. I guess it was never an area they wanted C# to venture in. For example their standard math library does not work on float32. WTF! The first time I realized this, I couldn't believe it.

By the way the author of the article you linked has this to say:

   JIT can generate faster code, because it targets the
   current platform of execution. AOT compilation must
   target the lowest common denominator among all possible
   execution platforms.

This points to another bridge that needs crossing (the one between the AOT and JIT communities). Had there been a garbage collector for the web, that should have been history by now. Command line options for compilers have been a thing for quite a while.

Actually you can AOT compile C# down to machine code. I haven't tried it, but they've been pushing it pretty heavily for a while now.

https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx

Technically it's an ahead-of-time compiler, unlike Java's Hotspot which actually does just-in-time compilation.

Or target Core CLR with C# and build with .NET Native...

Coming from using D for personal projects and now working in C# at work (in .NET 2.0 as well because of Unity) I find myself constantly missing D features. Especially given one of the main requirements of the work I'm doing is performance.

Things like array slices being first class in D while ArraySegment<> looks like a hack in C#, D templates beating the hell out of C# generics, functional programming in D is actually inlined almost 100% at compile-time while LINQ adds noticeable overhead, and the list goes on :)

Templating is one of the strongest features of D IMO, and the only reason I would ever consider using it over C#.

No decent IDE/debugging story though, so overall C# still wins for me at the moment. Especially for large projects.

I use Emacs as an IDE and gdb for debugging and it works like a charm.

Array slicing is likely to come in the next few versions. Templates and generics are simply different things.

That's no longer true with Windows 10 where .Net Native compiles everything into native code directly

For desktop apps. As far a I know, you can't run in IIS native apps.

True, and I'm not sure there would be much point. .Net native is mainly to reduce startup times and reduce memory footprint

For anything outside massively scaled web applications, I'm not sure IIS is worth bothering with anymore, now that self-hosted OWIN is more stable, and there is a version of ASP.NET MVC that runs on OWIN.

So, you are saying I could run a .Net Native app in a OWIN ?

Apparently I misspoke, and OWIN is not totally compatible with .NET Core yet. Still, I've found that developing and, moreover, deploying, OWIN self-hosted apps is much more pain-free than using IIS. App pool idle timeouts and recycling are a huge pain for anything that utilizes long-term background services, which happens to be the case with most of the stuff I work on. And ensuring that the appropriate IIS role services are installed is much more of a pain for customer deployments than building what you need into an OWIN app.

Does anyone happen to know what the AOT cross-platform story is? Can I build executables that targets eg: Linux/x86_64, OS X in addition to Windows 10 (I mean as three separate binaries -- having one monster, multi-target binary might be interesting, but that would be something else...)?

You mean AOT and with good optimization passes ? That would be quite awesome, any pointers (no pun intended) ? Please have one upvote already,

Now if you were to say that they are going to merge in a float32 math library, I will probably throw a party.

yes, .Net Native runs the managed code through a modified version of the c++ compiler and gains some benefits from it's optimization, not sure how much of a difference that does however. Good talk here: https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native

"You get highly optimized binaries that load and run faster than .NET code ever has before. Yes, my friends, .NET has gone native! :)"

It would be funny to review older "almost as native speed" claims from .NET JIT "overlords" vs current ".NET native is as fast as native" new claims :-)

Hey, just a heads up: your site's cert is coming up as invalid on my Nexus 5: http://i.imgur.com/kXNSygM.jpg

This is on stock Android 5.1.1, unrooted.

Yup, looks like CA bundle is not installed, causing issues on some browsers: https://www.sslshopper.com/ssl-checker.html#hostname=booker....

Thank you for the heads up. I'll fix that shortly.

Dang, c# looks so awesome! Was super interested in using for our most recent project, but alas, we chose python.

Looking forward to using these features someday but I'll pass on Windows and Azure for now.

C# plus Visual Studio plus MSDN is real awesome

and very huge download size and windows only, hope this changes soon.

Reply on news.ycombinator.com