Hacker News new | comments | show | ask | jobs | submit login
What .NET Developers ought to know to start in 2017 (hanselman.com)
61 points by andysinclair on Jan 11, 2017 | hide | past | web | favorite | 26 comments

I don't agree that async/await is in "should know" and LINQ is in "nice to know".

LINQ took C# from MS's Java clone with nicer generics to one of the best languages out there. It is phenomenal for increasing developer productivity.

Async/await, while a nifty, sometimes useful addition, is overhyped, code-complicating, unnecessary for most programmers, adds almost no performance benefits to most programs and infects the call stack above and below it with debugging problems, bad stack messages and extra code. It can introduce subtle and very nasty bugs, as well as impeding your ability to code some common patterns.

Why they keep pushing it as if every tom, dick and harry should write all their code using it, I do not know. It has a price so you should only use it when it's actually useful.

LINQ (the syntax) is borderline useless in a post-lambda C#. The query expressions don't fit with the rest of your code well, and it makes it unclear that you're calling library code to perform the query. LINQ (the standardized collection library) is amazing to work with, very powerful, and most importantly of all, very intuitive and discoverable (thanks to great IDE support from Microsoft). You don't need to take a course to use learn to use the basics of LINQ's Enumerables - I would even suggest that most novice C# programmers start using it without even realizing they're doing so.

Async/await, just like query expressions, are a syntax construct - they are something that is difficult to discover. You don't find it in the auto complete list in the IDE (usually). This is why you need to learn about it to use it at all, let alone use it correctly, hence why it should be in the top things a modern C# dev needs to actually learn about - since the upsides for using it correctly are so great (code clarity), and the alternatives are so poor (chained tasks? managed threads? All comparable minefields that are difficult to grok). Plus, all the "call stack problems" you claim are inherent to any asynchronous tasks in C# - async/await actually gives your better traceability and debugging across asynchronous operations than any alternative.

So yeah, I'd say in terms of actual learning, knowing what/how/why for async/await is much more important than from/in/where/select (which you can forget using and just use the more discoverable library methods instead).

Doesn't Async/Await help dealing with nested callbacks and simplify exception handling? I wouldn't push everyone to use it. But it is really useful in a lot of places. I cannot imaging writing Xamarin apps and distributed cloud services without it.

It certainly does help, but it's also (IMO) not a pattern to be adopted without some forethought, especially if want to mix async and sync style patterns. In practice, I have usually seen people go (mostly) all in on one or the other.

I disagree that it doesn't add to most programs... it absolutely does as most programs are deployed web applications and use of async/await affects the number of users/requests a server can support dramatically.

Of all the .Net web apps I've worked with I've seen an app maxing out IIS threads once, but I've seen plenty of web apps with shitty SQL queries maxing out the SQL server.

I've admittedly never had the 'millions of requests per second' clients, but the number of available threads has never been remotely the problem.

Back in 2006/2007 we had one app maxing out the IIS threads, but that was back when there were 100 threads max (as far as I can remember, might be wrong) and the actual underlying problem was slow SQL requests. Temp fix was to up the IIS threads, but once we fixed the SQL problem, no need for those extra IIS threads any more.

And even then, what will implementing async/await get you that you couldn't fix with a load balancer and web farm? Web farm is cheaper, easier and more effective. I think there's a Jeff Atwood piece somewhere on coding horror, or maybe a Joel one, to that exact effect. Cheaper to throw hardware at it then dev time. There's a certain scale that async/await actually fixes, the vast majority of C# web apps won't ever get close to it.

Every client I've taken on who were having performance problems were always fixed by monitoring SQL and fixing the bad queries. Or it was stupid loops calling moderately expensive SQL that did the same query over and over. Or something that could be easily cached. Or the same query being called several times in a stack where you could easily just pass the result down. One of those clients even had a previous dev who went async/await happy for extra 'performance' and it did zip. I ended up ripping most of it out, as I said, it infects code up and down the stack and complicates the code. All the 'optimized' async code was taking 1-2 milliseconds to run while the problem SQL was taking 5-10 seconds.

In a web app I can see the need if you're doing lots of external requests

What it gets you is not having to run as many servers... I've worked on IIS apps that required 6+ servers to handle high load, and that was before async was available, Similar situations could reduce the servers needed to 3-4. But agreed, in most situations it may not be needed... However, if you're in an org an want multiple apps per server/cluster then it benefits all the other applications.

I've seen far more issues with people not understanding how to use static and how it applies in a web application.

But most programs written are internal corporate apps at SMBs, and async/await isn't needed at that scale.

This is a great start but I still find .net framework & .net core confusing. May be small example (not code) would have been nice.

A short summary would be: .NET Framework allows you to build Windows apps (desktop) and webapps; .NET Core allows you to build cross platform webapps (so, no desktop apps).

The reason is .NET Core doesn't ship with any cross platform desktop graphical class library unlike .NET Framework (ships with at least 3: Windows Forms, Windows Presentation Foundation and Universal Windows Platform).

I beg to differ. I am building a desktop/server app in .Net core right now.

What UI framework are you using for the GUI?

Really not sure what there is to find confusing. It's just a runtime with currently terrible tooling. 99% of what you write on full .NET is going to be the same on core.

You could know all of this stuff and have no idea how to get a basic CRUD app working.

If you know all of this stuff, I'm fairly certain you know enough to research, i.e., Google, writing a basic CRUD app with ASP.NET Coreā€”and it won't take long.

I'm relatively new to .NET (though an experienced developer) and it took a couple of hours tops to research and write my first .NET CRUD app. It took even less time to begin writing useful cross-platform tools. That said, .NET Core still has some warts, and I look forward to it maturing throughout the year. From my perspective, it looks as if the development team moves pretty quickly.

I think this is great collection of resources to help onboard an engineer new to working with .NET and understanding the landscape.

I've been writing C# code for four years now and love it, but you have to be careful with the Microsoft stack, they would have you chasing your tail with the constant stream of new frameworks and tools.

>you have to be careful with the Microsoft stack, they would have you chasing your tail with the constant stream of new frameworks and tools.

It's not as if that couldn't be said about the other popular stacks as well.

Yes but not to the same extent, with MS frameworks there seems to be an amount of churn just for the sake of it. Just take a look at the way we write Windows apps: Win32, MFC, WTL, VB, WFC, Windows Forms, WPF, Store Apps, Universal Apps. I may have missed some in that list.

In fact that seems to be an explicit goal of the Web side of things

Hanselman mentions Reactive Extensions. Has anyone here built a large reactive extensions application and been happy with the readability/maintainability of the result?

I built one. And while it worked, it was never as readable or maintainable as if we had skipped Rx all together and written using other parallel paradigms.

I have written a medium-sized code base Angular 2 app with RxJs... mostly because my hand was forced by its use in the Angular 2 http service. Once I wrapped my head around it, I grew to accept and appreciate it. That said, it can certainly seem like overkill, especially when you have the abstraction of "subscriptions" and "streams" for transmitting a single value.

For our application it didn't seem like overkill. We thought it was would be the sweet spot for Rx. We pulled realtime data from a couple different sources, merged/aligned them, did some physics calculations, deposited the results in a couple of different destinations, and handled time travel/replay issues if we got out of order data.

But we kept on running into subtle issues because when we wrote the code we didn't fully grok scheduling/threading. It took us 3 months of spending 30%-50% of our time writing reactive extensions code to finally grok it, and we were highly motivated to learn. We eventually realized there was just no way the next developer who came on board could troubleshoot or debug it. So we ripped out all the reactive extension code and our app became a little less performant but a heck of lot more readable and maintainable.

From my "less than awesome" experience over the last couple of days with .net core on Linux, I doubt that there is anything I ought to know about it in 2017.

I realize that the situation on Linux is very new for Microsoft but the current state after this much time is quite sad.

I don't know that I agree, mid last year I was able to run a few .Net server applications in docker -onbuild images, and it worked with minimal changes. You also may have better outcomes using the Mono runtime, which is more encompassing.

You should try the new docker images.

In the transition to msbuild projects they mixed-up the runtime versions. The documentation on using docker is wrong and very confusing - the Microsoft web site and the instructions on docker hub are not the same! The SDK image is broken, it seems to assume a Windows docker host - it tries to compile with the .Net Framework on Linux!

Publish a 5 line "hello world" program to a docker core runtime and you'll get a 250MB image. Try running more than a couple of those in a microservice configuration ... I hope you have deep pockets.

I can't say that I'm enthusiastic about the move to msbuild. After too many years of that on Windows I was hoping they would have seen the error of their ways.

Sounds like the build system doesn't have an appropriate base image... or create one. If I had to do it in production, I'd probably have a base image with the appropriate runtime, and the dependencies, then a release image with only the application's updated dlls added. ymmv though, and probably a lot of work.

I do think there's definitely an opportunity to streamline this, and separate the commit for the libraries from nuget, and the output from the build process... If they can automate this, all the better... I was pretty happy basing from the *-onbuild and it just built the project nicely and ran... but if you're constrained on space, I can definitely see this becoming wasteful very quickly.

Applications are open for YC Summer 2018

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