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.)
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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# 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.
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.
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).
.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 :)
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! (:
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.
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).
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#
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 :)
[+] [-] jasode|10 years ago|reply
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.)
[+] [-] Encosia|10 years ago|reply
[+] [-] Scramblejams|10 years ago|reply
[+] [-] bookerio|10 years ago|reply
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.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] kule|10 years ago|reply
[+] [-] mattmanser|10 years ago|reply
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.
[+] [-] edgyswingset|10 years ago|reply
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.
[+] [-] tracker1|10 years ago|reply
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.
[+] [-] jorgeleo|10 years ago|reply
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.
[+] [-] useerup|10 years ago|reply
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.
[+] [-] breischl|10 years ago|reply
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.
[+] [-] norea-armozel|10 years ago|reply
[+] [-] Renevith|10 years ago|reply
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.
[+] [-] alimbada|10 years ago|reply
[+] [-] mhomde|10 years ago|reply
[+] [-] jayd16|10 years ago|reply
[+] [-] UK-AL|10 years ago|reply
[+] [-] VinzO|10 years ago|reply
[+] [-] douche|10 years ago|reply
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
[+] [-] aikah|10 years ago|reply
[+] [-] rottyguy|10 years ago|reply
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).
[+] [-] radicalbyte|10 years ago|reply
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 :)
[+] [-] artimaeis|10 years ago|reply
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! (:
[+] [-] snarfy|10 years ago|reply
If you are just getting started I always recommend the msdn tutorials.
https://msdn.microsoft.com/en-us/library/aa288436%28v=vs.71%...
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] aswanson|10 years ago|reply
[+] [-] dafrankenstein2|10 years ago|reply
[+] [-] mcintyre1994|10 years ago|reply
> 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?
[+] [-] bookerio|10 years ago|reply
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).
[+] [-] srean|10 years ago|reply
[+] [-] jeremiep|10 years ago|reply
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 :)
[+] [-] jaked89|10 years ago|reply
http://www.telerik.com/blogs/understanding-net-just-in-time-...
[+] [-] poizan42|10 years ago|reply
[+] [-] mhomde|10 years ago|reply
[+] [-] smileybarry|10 years ago|reply
This is on stock Android 5.1.1, unrooted.
[+] [-] ubojan|10 years ago|reply
[+] [-] bookerio|10 years ago|reply
[+] [-] scottc|10 years ago|reply
Looking forward to using these features someday but I'll pass on Windows and Azure for now.
[+] [-] dafrankenstein2|10 years ago|reply
[+] [-] diimdeep|10 years ago|reply