
What .NET Developers ought to know to start in 2017 - andysinclair
http://www.hanselman.com/blog/WhatNETDevelopersOughtToKnowToStartIn2017.aspx
======
mattmanser
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.

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

~~~
mattmanser
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

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

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

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

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

~~~
JamesBarney
What UI framework are you using for the GUI?

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

~~~
purple-dragon
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.

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

~~~
RandomOpinion
> _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.

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

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

~~~
purple-dragon
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.

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

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

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

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

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

