Guide to the CoreCLR Source Code

I guess I could've written 'Microsoft open-sourced the entire .NET stack'. I wanted to make it clear that they open-sourced everything, i.e. runtime, JIT, GC, base-class libraries, etc

It'd be a shame if the progress they are making were stymied in order to be compatible with the .Net of a decade ago.

> I've been porting .NET Framework code to .NET Core

Yeah, but you probably don't need to do that. .Net Framework is still supported, and will be for a long time.

.NET Standard is all about compatibility - so you can use that to determine which framework you can/need to use. However .NET Core is a distinctly designed for cross-platform reach so it will be a break from .NET Framework in some ways - this is just a given, otherwise they would've just released another .NET Framework version instead of doing all this.

You still might quibble over "entire" .NET Framework, but a lot of the .NET Framework is open source in addition to .NET Core.

Where did you get this "unused" claim? I've been following EF Core and EF6 for quite a while and I've never heard them say this about most of the major features missing from EF Core.

EF Core is a complete re-write from the ground up of Entity Framework. They're attempting to fix some design issues that cropped up in the original Entity Framework, improve performance, and improve the underlying architecture (the APIs are similar, but the "under the hood" layout/design has shifted).

They've been extremely clear that the current release isn't on feature parity to Entity Framework 6, and they've told people to avoid it until it is. If you look at their EF Core TODO list it will come back into EF 6 feature parity eventually and with some new functionality provided by the underlying changes they're making in EF Core.

Honestly your whole post is full is misleading claims, this is just one example. You've started using brand new technology (which is a rewrite) and are complaining because you ignored their very specific warnings about the state of it. Then you justify your own lack of research by making wild outlandish claims about how it is everyone else's fault.

To quote EF Core Team's Roadmap[0]:

> Because EF Core is a new code base, the presence of a feature in Entity Framework 6.x does not mean that the feature is implemented in EF Core.

> We have provided a list of features that we think are important but are not yet implemented. This is by no means an exhaustive list, but calls out some of the important features that are not yet implemented in EF Core.

> The things we think we need before we say EF Core is the recommended version of EF. Until we implement these features EF Core will be a valid option for many applications, especially on platforms such as UWP and .NET Core where EF6.x does not work, but for many applications the lack of these features will make EF6.x a better option. [Big List of missing features]

> There are many features on our backlog and this is by no means an exhaustive list. These features are high priority but we think EF Core would be a compelling release for the vast majority of applications without them [Big List of missing features]

> Our team is currently working on the EF Core 2.0 release. It's early days, so our plans will likely change as the release progresses, but here are the major features we are planning to address in this release. [Big List of missing features]

The truth is that YOU started using a piece of technology they expressly told you not to use and told you why you shouldn't. Then created fictional justifications for why it is their fault you screwed up.

But I welcome you to cite your "[won't implement features] which were deemed 'unused'" claim. Somehow I don't think you will...

[0] https://github.com/aspnet/EntityFramework/wiki/Roadmap

BTW if it's reading material you want, you should also check out me other post 'Research papers in the .NET source' http://mattwarren.org/2016/12/12/Research-papers-in-the-.NET...

I think the reason for it being soo large is that the GC is shared across all the .NET versions, so having it in one file has some advantages.

See https://github.com/dotnet/coreclr/issues/408 for a discussion on reorganizing it.

There's absolutely no reason they should be in C# and encourage bad coding practices (like overly long .cs files). Even if you need all your code in a single class, you can shard that class across several .cs files to make organisation and maintainability easier.

Regions are just a crutch people use to allow them to create 10K+ line .cs files that will eventually become a maintainability nightmare (as well as making merges/check-ins/finding things more annoying in general).

Only region I'll use is the built DEBUG one and I only use that to create:

     private bool IsDebug()
     {
     #if DEBUG
       return true;
     #else
       return false;
     #endif
     }

https://github.com/dotnet/coreclr/search?l=smalltalk

BTW if you want a bit more info on it, I wrote a whole blog post, see http://mattwarren.org/2016/02/04/learning-how-garbage-collec...

Hmmm really? I'm not sure I can think of many technological breakthroughs in the area of JITs that Microsoft have been responsible for? Google and Mozilla have made lots of advances, as have Sun and Oracle, and lots of academics like the PyPy people, HP with Dynamo.

What have Microsoft done in the area of JITs that so notable as to earn them the title 'king' of JITs? Can you say anything specific?

That’s... not really true. JRE’s HotSpot is much faster than CLR, even today.

I’d be interested to see benchmarks proving your argument, because basically every benchmark out there proves you wrong.

Sun’s HotSpot does recompilation and profiling, to reoptimize depending on use case, while CLR only JIT’s once, so the base performance is very low. This is also why HotSpot can reach better-than-C performance in some cases (because it can optimize at runtime for actually taken code paths, and jump to interpreted code for rarely taken paths), while .NET (and native code) can not. (This is what gives HotSpot the name – it recognizes hot spots, and swaps them out for more and more optimized versions at runtime)

really? since when? can't say i've ever heard this claim before.