Hacker News Reader

Comment by alkonaut | Hacker News Reader

I hope most or all these will find their way into the full framework. It's a bit odd that this is so rarely mentioned. I still haven't quite grasped the relation between core and the full framework when it comes to fixes like this being merged into the full framework.

View on HN

From the post:

“We expect that many of these improvements will be brought to the .NET Framework over the next few releases, too”

We still need to ensure that all the changes are behavioral compatible. Other than that, we are intending on improving the .NET Framework as well with these same performance investments.

> I still haven't quite grasped the relation between core and the full framework when it comes to fixes like this being merged into the full framework.

From what I can tell, from following the CoreCLR repo (https://github.com/dotnet/coreclr), it's changed over time.

In the beginning the sources of the 2 were more closely tied, changes were (automatically?) copied over. Now it seems like it's more ad-hoc, done as and when they decide it's needed. See the mentions of 'TFS Mirror' in this thread for a bit more info https://github.com/dotnet/coreclr/issues/972#issuecomment-25...

If you take a look as these issues, it's clear that they're happy to make the source code very different, i.e. hard/impossible for changes to be automatically ported across.

Just look at how much .NET Framework (Desktop) code they removed from CoreCLR earlier this year!

- https://github.com/dotnet/coreclr/issues/8857 - https://github.com/dotnet/coreclr/issues/8763 - https://github.com/dotnet/coreclr/issues/4651 - https://github.com/dotnet/coreclr/pull/9058

> Just look at how much .NET Framework (Desktop) code they removed from CoreCLR earlier this year!

Perhaps I'm missing something but wouldn't removing Windows specific code from a now cross platform runtime be the obvious thing to do?

FWIW (I work on the .NET Team and I wrote the mirror we use to keep TFS and GitHub in sync). When we started the project we maintained a mirror which kept our GitHub repository and internal TFS branch in sync. After a while, we decided that trying to maintain this was more harm that it was worth (the internal TFS branch used a completely different build system and there were other interactions between code which had been open source and code that hadn't that meant our internal branch was on the floor every few days), in addition it meant that we were carrying around a bunch of effectively dead code in the source tree.

We still do mirror some code (mainly the JIT) into TFS to make it easier to share code with the Desktop in an automated fashion. However, for the rest of the code (e.g. the VM and BCL), if there are improvements we want to bring back, an engineer will just port them manually.

As .net core is a full rewrite, all these optimizations are .net core specific, so porting them isn't going to be a easy thing.

Hopefully these optimizations are for a particular version of .NET Standard and will see themselves in both .NET Framework and .NET Core.

Skimming, but it doesn't look like these optimizations are relevant to .NET standard (which is a formal specification of a set of APIs - not a particular implementation.)

Correct. Performance improvements are out of the scope of the standard. Much like how the HTML spec doesn't tell Google and Microsoft how fast their browsers need to work.

.NET Core is not a rewrite in any way. It's the same runtime with the same GC and JIT, same language compilers and mostly the same standard library. It has just been stripped down by removing deprecated features (such as code sandboxing / partial trust) and made support non-Windows platforms.

You might have confused it with ASP.NET Core, the web development framework, which is a full rewrite.

If a developer confuses .NET Core and ASP.NET Core, is that a fault of the developer, or of Microsoft's nomenclature?

You are right, i was confusing asp.net core with .net core.

Reply on news.ycombinator.com