It is a completely different architecture from the ground up, completely re-written with modern development in mind.
For one example it has native support for dependency injection, and in general testability has massively improved since it was a core design goal.
They've also de-coupled several layers, which is hugely powerful since you can write your own middleware. For example check out this article on "Handling Errors Globally with the Custom Middleware"[0].
If you want to see how different it is from .Net Framework look at this diagram:
Frankly because nothing outside of the .Net Core's Web/Asp.net/MVC/WebAPI improvements actually matters. And the changes there are massive and significant.
While you can technically create Forms, WPF, and UWP applications using .Net Core on Windows, that isn't really the direction or focus of the framework. Just a niche for legacy software or people who continue to need Windows specific desktop applications.
Console applications might have a future for cross-platform headless sever loads. But outside of that it is a web framework that happens to support non-web projects on the side.
It is competing primarily with e.g. Java, Ruby on Rails, Node.js, PHP, etc.
As well as the underlying .NET Core framework, and .NET in general. We have great new memory types like Span<T> and Memory<T> and tiered compilation, along with thousands of other improvements that has made major improvements in performance.
So? We're talking about .NET Core here. These new APIs are compatible with netstandard, so they can still be used with Framework but wont be as fast. What libraries are using these newer APIs but refusing to target Core?
Well it has always been performant. The whole Stackexchange is built with ASP.net, and it render things 10x faster than Ruby Rails while requiring 10x less hardware resources.
I think many were more concerned about .NET performance against tech in the same class, mainly the JVM, which previously blew .NET out of the water in the benchmarks for a number of years.
"The degree of improvement is absolutely astonishing, going from 2,120 requests per second on Mono in Round 11 to 1,822,366 requests per second on ASP.NET Core in Round 13. That’s an approximately 85,900% improvement, and that doesn’t even account for Round 11’s hardware being faster than our new hardware.
That is not a typo, it's 859 times faster! We believe this to be the most significant performance improvement that this project has ever seen."
In the past, TechEmpower benchmarks only ran on Linux, so their benchmarks for .Net actually used the Mono project's implementation of ASP.NET, which was slow.
That's why the increase was so significant. If they were comparing ASP.NET Core with .Net Framework on Windows, the difference would have almost certainly been much smaller.
Mono has always had terrible performance. It was mostly useful as a way to sell developers who wouldn't normally go for a Windows-only solution on something that was effectively Windows-only in practice, if you cared about things like performance.
But there was no good way to edit .csproj files without an IDE and you needed to edit them for every source file you added (or moved).
Now you don't have to edit them as often (wildcards for files), they're easier to edit by hand (because they contain almost no clutter) and there are also command line tools to edit them (like dotnet add package).
As I understand it, if you ever opened such project in VS, it would replace the wildcard with the current list of files. So the usability of that approach was very limited.
Ah, I see. I wasn't using VS (which is why I found the wildcard trick). It seems like VS was the issue then, and one of the reasons donet core has a better experience is because it's much less bound to VS.
You've never needed Visual Studio to build .Net projects. They have supported MSBuild from v1.0, you just needed to write the project files by hand - a very tedious process.
It's just that building from Visual Studio is by far the most convenient method.
And Mac OS X, also a lot of work was done to make Core nice; it builds fast, low latency for ASP.NET and more. I use vim under Linux and I could not be happier. I was always against the choice for .NET because of the lock in; now that that is gone, it is great.
It also makes running Docker a whole lot easier. I know there is Docker for Windows, but it feels like a red headed step child compared to Docker on Linux.
I'm not disagreeing to any of that, what I'm saying is that to run a Linux Docker container on Windows, you'll need a Linux VM which runs Docker, which is exactly what Docker for Windows does for you using HyperV.
A 10mb Linux container will still share the Linux kernel with the host, hence it's still running on Linux, even if it doesn't have any dynamic dependencies.
There's no OS "inside" the container, no, but it's still dependent on an OS.
