C# 6.0: An Introduction

https://booker.codes/csharp-6-an-introduction/

by bookerio • 11 years ago

123 81 11 years ago

kule• 11 years ago

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

jasode2• 11 years ago

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

bookerio3• 11 years ago

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.

jasode2• 11 years ago

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

Encosia• 11 years ago

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.

Scramblejams• 11 years ago

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.

VinzO• 11 years ago

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.

aikah• 11 years ago

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.

ghuntley• 11 years ago

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

rottyguy• 11 years ago

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

douche3• 11 years ago

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

snarfy• 11 years ago

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

radicalbyte• 11 years ago

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

aswanson• 11 years ago

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.

dafrankenstein22• 11 years ago

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)

artimaeis• 11 years ago

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! (:

mcintyre1994• 11 years ago

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?

bookerio3• 11 years ago

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

WeaselNo7• 11 years ago

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!

srean3• 11 years ago

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#

jaked892• 11 years ago

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

srean3• 11 years ago

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.

ygra• 11 years ago

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

poizan42• 11 years ago

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

jeremiep2• 11 years ago

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

jaked892• 11 years ago

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.

CmonDev• 11 years ago

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

mhomde4• 11 years ago

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

guiomie3• 11 years ago

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

srean3• 11 years ago

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.

mattmanser6• 11 years ago

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.

tracker15• 11 years ago

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.

mattmanser6• 11 years ago

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.

norea-armozel• 11 years ago

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.

tracker15• 11 years ago

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.

Renevith• 11 years ago

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.

mattmanser6• 11 years ago

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.

edgyswingset5• 11 years ago

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.

jorgeleo• 11 years ago

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.

edgyswingset5• 11 years ago

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.

louthy3• 11 years ago

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

runfaster2000• 11 years ago

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

UK-AL3• 11 years ago

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

alimbada• 11 years ago

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.

jayd16• 11 years ago

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

mhomde4• 11 years ago

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

breischl2• 11 years ago

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.

useerup• 11 years ago

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.

dafrankenstein22• 11 years ago

C# plus Visual Studio plus MSDN is real awesome

diimdeep• 11 years ago

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

smileybarry• 11 years ago

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.

ubojan• 11 years ago

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

bookerio3• 11 years ago

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

scottc• 11 years ago

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# 6.0: An Introduction

Related Stories