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:

https://msdnshared.blob.core.windows.net/media/2017/06/06221...

[0] https://code-maze.com/global-error-handling-aspnetcore/#buil...

The diagram (and your comment) appear to be about ASP.NET and don't tell anything about .NET Core compared to, say, .NET Framework 4.5.

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.

https://trends.google.com/trends/explore?q=%2Fm%2F02_qnn,%2F...

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.

One improvement that doesn't get enough attention, IMHO, is that Asp.net core is now performant as hell.

https://www.techempower.com/blog/2016/11/16/framework-benchm...

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.

Which aren't being fully backported to .NET Framework, whereas many libraries still don't run on Core.

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?

ODP.NET for example.

Managed ODP.NET for Core is a partial implementation of the ODP.NET for the full .NET Framework.

Libraries using EF 6, because EF Core is still playing catchup with EF 6, and even .NET Core 3.0 won't support 100% of the EF 6 tooling.

Libraries using WCF, which lack budget for anyone to rewrite them and the respective clients into other transport protocols.

Plenty of other examples.

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.

[1]https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...

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.

From the Techempower blog post I linked to above:

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

I saw claims of a 30% perf increase moving to .net core for a major software company. Can't remember which one, but that's still pretty impressive...

Perhaps you're thinking of Microsoft moving Bing to ASP.NET Core 2.1, with a 34% performance improvement: https://blogs.msdn.microsoft.com/dotnet/2018/08/20/bing-com-...

I see - good point.

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.

Also not tied to visual studio to build. `dotnet` is an node style command line tool.

You haven't needed Visual Studio to build .net projects for a long time, project files are MSBuild files.

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

Wildcards have been supported for source files for many years.

    <Compile Include="**/*.cs" />

I was doing this back in the .NET 3.5 days.

But nitpicking aside your point is well taken, the developer experience is far better with dotnet core.

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.

Correct. It wasn't really usable.

Speaking of the project files, the new csproj format is my favorite thing. We used to always get conflicts in them, and now we basically never do.

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.

MSBuild was introduced around .NET 2.0 after Ant's introduction in the Java world.

Before there was a project format, callable with devenv command line tool.

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.

^ that's now how Docker works. aka, the whole point of Docker is it doesn't matter what the host OS is.

That's not really true, OS definitely matters with Docker, both on the host and the container. Docker for Windows uses a VM to run Linux containers.

> OS definitely matters with Docker, both on the host and the container.

What OS in the container? A docker container is not a VM. Most of my containers are on the order of 10s of MB, and just contain a single binary.

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.

Docker can also make use of Windows containers.

I know, which is why I said Linux containers. Although, Docker on Linux can't run Windows containers, can it?

Certainly not, containers are a kernel level feature.

You're right on that, but there's no "OS" inside of a container to speak of.

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.

I think we agree. :)