For the last year or even more I've been waiting for "usable" build, beta, release candidate, whatever, of the new Core .NET framework and tooling support.  I played with RC1 and betas before, but always had so much trouble in configuring everything, from configuration of project file to producing DLLs and nugets. Specially figuring out various target framework names and standards (dnxcore, net standard, etc – that’s still a mystery too me mostly!). 

Also, lot of things have changed along the way. Since whole development process is so public now, we can see all the changes, mistakes, proof of concepts, some more changes, which were happening behind closed door before where we would just get final RTM bits. So there's that price we as community had to pay, going from DNX and DNU to CLI,   project.json going away soon, who knows what else ...

But I guess, important thing is that framework bits are stable and ready for production use! Runtime, web server (Kestrel, RIP Helios btw), MVC and WebAPI are good to start serious development. Also, Visual Studio for RC2 works fine, which is absolutely necessary for any serious work. 

Lot of blog posts have been written on this topic already, but I would like to point few things which are important now, for us, normal developers working in some company:

• whole new platform to learn & explore: we can now develop on Mac, host on Linux, even run Sql Server on linux! I would say it's a big and important change, going from (not always so) easy-to-use point'n'click server interface to bash command line. It's so serious thing that even Win 10 includes full bash support now!
• new tools available on linux: things like nginx, haproxy, which are mandatory for ASP.NET on linux - you shouldn't expose Kestrel to public! Then different databases, from awesome PostgreSql (my bets are on that one, combined with Marten for NoSql story), Redis, Cassandra, and list goes on ... We have to switch from "IIS application server" mindset to docker style of deployment, with chef and puppet0 for configuration management. That leads naturally to bunch of small services instead of few monolithic one, and that involves service discovery tools like zookeeper and consul.
• To be honest, as a .NET dev I was really jealous on all linux-platform devs for last few (10?) years! They had docker, bunch of fancy data stores, mezos, big data tools, bunch of analytics and logging tools (Kibana, Kubernetes) ... while we (windows server centric) developers where totally isolated, there's whole brave new world of tools, frameworks and services emerging and we're still fighting with MsBuild and MsDeploy and Sql Server. I will not even mention MSMQ here. I don't want to find myself in "who moved my cheese" position, and it looks I'm awfully close.
• actors. Really important concept, not the silver bullet for every use case, but it has it's place. Microsoft is pushing that also with Azure Service Fabric, with statefull and stateless variants of actors and services. Akka in JVM (java and scala) is quite successful, and even though we had Akka.net it really never became "mainstream" framework. Personally, think it's not the problem with akka.net itself, but with regular-Joe-.net developer, who uses only what MS releases.  There's Orleans framework, but it's made for specific use case (Halo game on Azure) and should be avoided for general usage IMHO.
• cloudify all the things. Most of the companies where i worked are slowly switching to the cloud. That brings scaling, resiliency, failover to the list of non-functional requirements. Application needs to be designed differently to accommodate almost-certain outage and downtime of a service, and also to control overall costs.  

What I Like:

• new domain http://dot.net is totally cool
• VS Code, since VS Full + Resharper can be unusably slow sometimes. It will force me to learn how to program without Resharper :)
• exposure to Linux
• new modular and minimal design of .NET, and whole cross-platform support
• attention to performance. Just to show off how "my framework is faster than yours" when talking with other devs. Important stuff.
• Xamarin will get proper attention now, when it’s part of the same company.
• community standups, great way to hear what’s going on and ask questions

What I Don't Like:

• changes beta -> rc1 -> rc2. RC2 looks like real beta to me. Think it could be communicated better, in form of; what's todays state, how to install nightly builds and use that with VS Code, what's working and what's not, what are all the "net standard" targets and what the hell do they mean, etc. Community standups are great, but I would like to have one up-to-date web page describing how to setup dev environment and how to pick right target framework
• Xamarin and .NET Core – I’m guessing some merging will happen, this way it just doesn’t make sense to have 2 frameworks and runtimes doing almost the same job
• VS becoming even more slower. Has many problems with Update 2, had to completely reinstall VS on one machine, and even reinstall whole Windows on another!
• whole .NET could be released in more "agile" or incremental way: first core bits, then standard library (one nuget at the time!), then app frameworks like MVC, and so on. So not wait until everything is RTM (framework, web server, libs, tooling, EF, Xamarin, ....) but bunch of small RTMs. Until MVC is RTM, we would have many libraries and frameworks already ported and ready. I think MS is here aiming at regular dark-matter developer who wants the whole package of absolutely everything, but this is framework for next 10y, customer shouldn't be a developer from 2006.
• like Json.net become a part of official .net, i would like to see more examples like this: for logging (Serilog?), messaging (EasyNetQ?), database (dapper, marten), architecture (akka.net), where MS officially endorse and support some OSS project. I don't mean full SLA where I can call MS in the middle of the night and ask some crazy question, but more from marketing perspective (if that's even possible or makes sense) 
• Win 10 issues: forced restarts, burned by those several times. Lack of High DPI support. Not related to .net, but I'm just so angry about this. If high DPI doesn't get fixed soon, I'm switching to Mac book.

RC2 is out, VS Code and VS Full have full debugging support, there's no excuses any more to try new platform! It's a call to action!

Looks like 2016 and 2017 will be years of learning new platforms, environments and tools! Maybe it sounds scary, but I can't wait:)

IMPORTANT UPDATE:

It seems I was wrong all the time! Lot of partial views WILL NOT slow down page rendering!

Profiling tools you use can slow down the application! After I disabled Glimpse, time-to-first-byte in Chrome was the same, in optimized version with 10 partial views, as in version with 182 partial views! It seems Glimpse injects some code into MVC execution pipeline to measure timings and who-knows-what, which introduces around 5-10ms per view call.

There’s no simple and quick “turbo button” for you application, unfortunately But you need to learn how to use development tools, and how to read the results. The devil is in details.

The old blog post, if you’re interested:

Here goes a quick advice how to speed up performance of your website, at least Time-to-first-byte!

I had a performance problem with one e-commerce web site, where visitor needed to wait at least 5 seconds  to see the web page. There were some changes with database server, so my first assumption was the speed of new server. 

But to verify that, I had to profile page rendering pipeline. The easiest way is installation of Glimpse plugin, with EF add-on. After doing that, to my surprise, I saw database takes less than 10ms to return the results, so the devil has to be somewhere else! Going through glimpse Tab, I noticed this horror (here's just the part that fitted into my screen):

There were than 180 partial view calls from main page (remember, it's an e-commerce web site, each partial view renders one product. There are 9 categories with 9 products each rendered on the home page, and each product partial view calls another partial view to show some additional information – total of 182 views rendered)! And that took at least 80% of the whole rendering time for that page!

Now when I knew what's the problem, solution was easy, refactor of few Razor views, and rendering time went from 5-10 secs to under 1 second (on my local box went from 2+ secs to around 400ms, on remote VM from 5-10 secs to less than 1 sec). All done by simply reducing number of partial view calls from 180 to 10.

Side note; it makes code uglier, since I don’t have nice encapsulation of each partial view, than can be called from different places, but rather duplicated code in few Razor files. But the business value here is obvious! From development perspective, each duplicated content  is well marked with code comments, so when someone modifies the code in one place,  he/she will know that code needs to be copied to another location.  

Nice, small and quick optimisation! MVC version I’m using is 5.2.3, but in v6 we can expect some major performance improvements of Razor view engine, so can’t wait to revisit this little test in about half year!

Moral point of the story; measure first, then fix! And definitely use Glimpse if doing any ASP.NET MVC work, it can save you hours of investigation!