
Exploring the .NET Core Runtime - matthewwarren
http://www.mattwarren.org/2018/12/13/Exploring-the-.NET-Core-Runtime/
======
giancarlostoro
C# was the first language after Visual Basic 6 that I learned the most
seriously, and after .NET Core I got the most excited about C#. I love that I
don't have to reach to Java anymore to go cross platform, or wonder if Mono
will support my .NET project or not. In fact, thanks to .NET Core they made
.NET Standard so I _know_ if and how my project will run on a modern version
of Mono.

I also love that people are doing write ups about the source of .NET Core and
it's internals.

~~~
matthewwarren
> I also love that people are doing write ups about the source of .NET Core
> and it's internals.

Me too!

BTW, if you want more on the same topic check out
[http://mattwarren.org/2018/07/12/Presentations-and-Talks-
cov...](http://mattwarren.org/2018/07/12/Presentations-and-Talks-
covering-.NET-Internals/) and [http://mattwarren.org/2018/01/22/Resources-for-
Learning-abou...](http://mattwarren.org/2018/01/22/Resources-for-Learning-
about-.NET-Internals/)

~~~
phoenix24
thank you for the links, this is amazing!

------
bad_user
I was never impressed with .NET, I always considered it inferior to the JVM
and its ecosystem in terms of runtime capabilities, tooling and open source
available, however .NET Core moving to an open source model is super exciting,
F# looks cool and I'm happy that Java finally has true competition.

Also Matt Warren's blog is super cool.

~~~
lwansbrough
Java is not an example of a forward thinking language anymore. It has lagged
behind C# in every major feature pretty much since C# arrived in 2000. The JVM
has had solid performance improvements since forever, and may still be faster
than the CLR, but the JVM still has some pretty glaring shortcomings coming
from the .NET world. For example, Java generics (and their underlying
implementation in the JVM) suffer from type erasure which makes for an awful
developer experience in many scenarios. Java/JVM's story for asynchronous code
is also pretty pathetic. This is stuff I don't even think about anymore when
writing C# but I groan every time I have to do any "modern" programming in
Java.

~~~
bad_user
My opinion is from the other side of the fence ... type erasure is perceived
as a weakness of Java, however I believe it is one of JVM's best features,
because it didn't cripple its runtime for other languages, this being one of
the reasons for why other languages have been flourishing on the JVM (that and
the tooling and the open source culture).

To understand why, we need to talk about 2 separate things:

\---

1\. Specialization is important for performance and when speaking of .NET,
specialization for value types is subsumed in type erasure, but that's not
necessarily the case. You can have compiler-driven or even runtime-driven
specialization without reification.

In Scala for example we've had the "@specialize" annotation for a long time,
with the compiler being able to specialize generic code just fine. It's not
perfect, a better implementation eventually happened in Miniboxing [1] but it
withered away due to lack of interest and the ongoing work happening in Dotty
/ Scala 3 and its newer TASTY distribution format, which should make
specialization easier to accomplish.

Also there is on-going work to bring value types to the JVM and it's
happening: [http://mail.openjdk.java.net/pipermail/valhalla-spec-
experts...](http://mail.openjdk.java.net/pipermail/valhalla-spec-
experts/2018-May/000618.html)

That said having specialization is pretty cool for fine control of the memory
layout and Java developers have to resort to a lot of unsafe hacks for
achieving the same thing. But if that cost was paid such that languages like
Scala or Haskell could happen on top of the JVM, until they figure out how to
do it such that everybody benefits, I think it was a cost worth paying.

Also consider that the lack of specialization forced the JVM 's engineers to
get creative in other areas. For example the JVM has always been great at
inlining code at runtime, even for megamorphic call sites. And the new GraalVM
has super impressive abilities to eliminate boxing at runtime, which works for
dynamic languages too: [https://www.graalvm.org/](https://www.graalvm.org/)

\---

2\. Reification is in fact about adding info about type parameters at runtime.
This aids in using reflection to make a difference between List<int> and
List<string>, but people miss the forest from the trees.

As a matter of fact such reflection is only needed because languages like Java
or C# have very weak static type systems, compared with other languages in the
ML family. With an expressive type system, you never need reflection
capabilities.

In Haskell for example the question of whether something is a List<string> or
List<int> never, ever happens. In Scala you sometimes need it, but much rarely
and you can get it via a compiler-generated `ClassTag`, which is actually a
much better approach, because it makes it clear in the signature, this being
compile-time reflection. People also like being able to do "new T", however
that need completely goes away via proper support for type classes, which both
Haskell and Scala have, this being another special purpose band-aid.

And reification is actually a bad feature to have in the runtime, because it
makes it hard for languages to support higher-kinded types, or to build
dynamic languages.

F# does not do higher-kinded types and is less expressive for that reason than
OCaml, Scala or Haskell and the primary reason for why it doesn't do higher-
kinded types is because it would have to do type erasure by itself, thus
forgoing the performance benefits and the interoperability it has with C#.

Ironically it is support for higher-kinded types in a language that increases
its expressive capabilities to the point that you no longer need runtime
reflection. In other words ... you're blaming Java for not having a band-aid
that happened in C# due to their static type system being basically unsound
and thus needing runtime guards and reflection. You quickly get over this once
you'll start using a more expressive language ;-)

[1] [http://scala-miniboxing.org/](http://scala-miniboxing.org/)

~~~
migueldeicaza
Reflection is the least of the problems this solves.

The majority of the issues and gotchas listed in the generics FAQ for Java do
not happen in C# at all. It is liberating.

Reflection is an advanced use case that some people use, but it is rare.

The lack of flourish in. NET overtime more to what happens when a company
takes the reins of a stack and later stops working on it.

Microsoft for a while invested and designed JavaScript, Python and Ruby
versions for .NET. But when conditions changed, there was no interest to keep
the projects going. These are all observations from an outsider at the time
the projects were defunded.

Because of the siloed approach to development at the time, and the lack of an
external county around those efforts, bootstrapping a community to drive those
on their own proved to be very hard. Ruby mostly died, Python is barely
surviving.

The mood in the ecosystem went from "we can build these and speed them up" to
"this is an ongoing cost, let us rather interop with the real implementations
rather than find constant catch up".

Meanwhile, languages that Microsoft did not build did flourish, like PHP

This corporate phenomenon deserves a blog post on its own

~~~
i_s
> The lack of flourish in. NET overtime more to what happens when a company
> takes the reins of a stack and later stops working on it.

But couldn't .NET not being a good target for dynamic languages be one of the
reasons to stop working on it?

I keep hearing that .NET is a good platform for other languages, but there
doesn't seem to be much empirical evidence for it (at least in dynamic
languages).

------
eksemplar
Do people really use .NET core, and if so, why?

We’ve been a C# house for several years, decades really, and I’ve always
preferred it to JAVA so I’m actually excited for Core.

But we rarely use it. Not because it’s not great, rather because we’re more
productive with flask or Django. For Core to really make sense for us, it’d
would have to stop being so damn low level, but I guess that maybe it can’t
without sacrificing too much efficiency. More importantly it needs better
libraries for things that aren’t “built-in”.

I can certainly see why .NET developers welcome it, because they finally have
good cross platform ability. At least until they need to do authentication on
a non-standard SAML token, that though easily supported by ADFS but is a bitch
in any .NET setup.

I know we aren’t most use cases, being the public sector and running a
gazillion different tech stacks at once, but .NET has never played well once
you stepped outside it’s comfortzone and it’s always been so low level that
writing library extensions were a bitch. And that may have worked out, so far,
but I just don’t see why people stick with it when there are more productive
alternatives.

I say productive, because I don’t think .NET core is lacking technically, but
delivering solutions on time and with minimum maintenance requirements
afterward is just easier in python or JAVA and I’d imagine others as well.

But maybe I’m missing something?

~~~
pepper_sauce
What's your definition of "low level"? You keep using that word, I do not
think it means what you think it means

~~~
eksemplar
It’s having to explicitly tell the computer what you want. C# is obviously not
C, but it’s not python either.

By the time we have an app running in Django, we’re not even finished with
Entity modelling in a Core web-api.

I do think stuff like Blazor.Net is promising, but we’re not a technology
company, we support thousands of employees who only care about how
digitisation can make their lives easier as fast and as stable as possible.

.NET isn’t the best at that, at least not for us.

Dont get me wrong, I don’t dislike .NET Core, it think it’s great, I just
don’t see how it benefits me.

~~~
BjorksEgo
>Do people really use .NET core, and if so, why?

>.NET isn’t the best at that, at least not for us.

You're comparing apples and oranges, djanjo is a web framework, for creating
websites, .Net core is a cross platform compiler and the standard library that
goes with the C# programming language, which includes some stuff for creating
websites (along with desktop, CLI, services etc). Django might work best for
you but I want to create a bunch of micro services I'm not going to use it, am
I? Not to mention Django works well as a general purpose solution for general
purpose websites, If you're building anysort of heavyweight, enterprises level
web architecture you're going to want a hell of a lot more control that what
django provides for you.

~~~
eksemplar
I specifically said python, flask and Django, the guy I was replying to then
asked for an example, where I used only Django, and now you’re using that
against me?

Obviously we don’t use Django for everything. But like with web-applications,
a python script or a flask application is always more productive for us than
.NET.

~~~
BjorksEgo
I don't disagree that django and flask are good general purpose web app
frameworks, but theres a mile gap between "Not the best for general purpose
web apps" and "not good for anything", which is why I highlighted the
following question

>Do people really use .NET core, and if so, why?

------
Traubenfuchs
How much of the old CLR is in the new .net core runtime /CoreCLR?

I once read CLR via C# and it was difficult but amazing. Is all of the
knowledge in that book now worthless? What about the IL, is the IL still the
same?

~~~
tybit
They forked the CLR, cleaned it up, added cross platform support and open
sourced it, so a lot would still be relevant would be my guess. The IL has
remained unchanged other than possibly a tweak or two to support newer
features like non nullable references.

~~~
matthewwarren
Interesting fact, when they forked the CLR, they actually started with the
Silverlight code base. See [https://channel9.msdn.com/Blogs/dotnet/NET-
Foundations-2015-...](https://channel9.msdn.com/Blogs/dotnet/NET-
Foundations-2015-03-04) (somewhere near the beginning)

I guess it makes sense. Before .NET Core, Silverlight was the most x-plat
version of the Microsoft .NET Runtime(s) (excluding Xamarin/Mono), so it
would've been a good starting point.

------
revskill
Installing .NET stacks including Runtime, SQL Server is a nightmare to me.
When an error occurs during installation process, you got stuck , hopeless and
depressed. Hey MS, fix your installation process first.

~~~
pknopf
The build scripts (for coreclr, corehost, corefx) are a mess. I worked on
getting the build working for Yocto, and there were so many things done
differently all over the place. They need a single team to go through their
entire build process, top-to-bottom.

Don't get me wrong though, I worked to integrate it into Yocto because I
_love_ .NET/C#, but the build system needs a lot of love.

~~~
matthewwarren
I don't know if it solves your specific scenario, but I do know that there's
been some work done in this area.

See [https://github.com/dotnet/source-build#net-core-build-
script...](https://github.com/dotnet/source-build#net-core-build-scripts) and
[https://github.com/dotnet/arcade#arcade](https://github.com/dotnet/arcade#arcade)

------
memsom
The "two" books mentioned that were written by Serge Lidin are basically the
same book, the latter is just an updated version. So really, there's only one
book with two editions.

~~~
matthewwarren
Ah, I didn't realise that, thanks for the info

