[Analemma_]

I think it's a combination of monopoly effects plus the benefits of open source: back when .NET was closed-source and only available on Windows, the only way to ship a performance improvement was if an individual developer at Microsoft could convince his boss it was worth it. And it was rarely worth it, because .NET only ran on Windows, its only customers were .NET-only enterprise shops who weren't about to move to an entirely new framework because of perf problems, and there was always a long list of feature requests that PMs would give priority to.

But now that .NET runs everywhere, it has to compete with projects that have been shipping performance improvements all along. Happily, since it's now open-source too, it can accept those changes from anyone.

[sebazzz]

It is more about backwards compatibility than anything else. Remember that .NET Framework is something that ships with an operating system (Windows) and has components built on this shared runtime: not only devtools like SSMS and Visual Studio but core Windows components like MMC applets and things like ADFS / Remote Desktop Gateway as well. This puts up a bar regarding backwards compatibility. Not only code that is written against the runtime need to be compatible, but also code hosting the runtime, debugging the runtime, the profiler API, and I could go on.

This yields some constraints in whatever is possible changing. Want to add new IL instructions? No can do. Need to change the debugger API? No can do.

Please also see this: https://news.ycombinator.com/item?id=18364032

[fortran77]

The "proprietary" .NET was very performant. It's the new "open" one that has to catch up.

[gameswithgo]

You have posted something along these lines twice, it is not correct. .NET Core has been better performing than Framework from the start. You may be thinking of Mono.

[nathanaldensr]

Just an aside: Thanks for using "better performing" and not the non-existent word "performant." ;)

[grokys]

.NET Core isn't based on Mono.