Book of the Runtime – Internals of the .Net Runtime not in the documentation | Hacker News Reader

Book of the Runtime – Internals of the .Net Runtime not in the documentation

hanselman.com

151 pointsbenaadams37 comments

That should be an interesting read. Going through the introduction, there is a whole part highlighting that the success of .net comes from its simplicity (which I strongly agree with).

Then I think about the massive compatibility matrix between the different versions of the different sub-fameworks, the confusing core vs non-core naming and versioning conventions, the new language syntax features that are available through nuget packages only, etc. I can't help thinking that the .net team has lost its way, and needs to have a hard think about how to keep all of that simple.

Keeping it simple is what has made the success of competing languages like python.

The 'NET Core' movement feels like they got that feeling too.

Whether they've lost their way or not, from what I hear it runs a lot faster on Linux, which is great, because that's what I'd rather be running on server-side.

> the new language syntax features that are available through nuget packages only, etc.

Which features?

Value tuples. If you want to use them you need to add a nuget package to the solution. I am not saying it's not doable, but it's a bad UX. Think of the experience of a newcomer to the language.

I could be wrong, but I was under the impression that this was temporary.

The new tuple syntax in C#7 required the addition lf the ValueTuple class in the framework, but as framework and compiler versions are released independently it has to go into one first. This means people can upgrade their compiler to C#7, and install the ValueTuple nuget package and get the benefit of the new langauge feature without having to move their entire project to require the latest version of the .net framework. I believe the next version of the framework will include ValueTuple by default and the package will no longer be required.

That's the reason why they did it. But that doesn't change my point on keeping it simple.

Yes, true.

Although at least in this case it will return to being simple at the next release.

But I do see your point, .net has certainly grown in complexity since the early days.

Ok, but the alternative is to simply wait longer for both the compiler and framework to be released together. There's no option C which gets you the feature just as quickly and still allows for parallel release of the two pieces need to implement it. So... Don't use the feature or be happy you have the ability to use it sooner.

I kind of like that; it's nostalgic for me. Most of my early career was spent writing Perl code, and in Perl it's possible, and common, to write optional add-on modules that give you new core language syntax. (Not everything is possible, but you can go a long way.)

For example, Perl 5 only has barebones support for OOP, and the community developed various approaches to fuller support. It was kind of like the way we've had multiple Javascript frameworks trying out various approaches to MVC. Eventually, Moose[1] was developed and became the most popular approach, and my understanding is that it greatly influenced the core support for OOP in Perl 6.

If you look at the docs for Moose, a lot of the syntax which looks like core language keywords is actually made of functions defined in the module.

This approach is great for letting the community of language users figure out what works and what's needed in the language, so that the language can evolve naturally instead of being designed by a detached committee. Again, it's much like the way Javascript is evolving, where the core language has been picking up features that were originally developed as add-on libraries.

[1] http://search.cpan.org/~ether/Moose-2.2006/lib/Moose.pm

It's how they release compiler versions at a different cadence to Visual Studio.

I agree. I hope they get it all sorted out and start deleting some intermediate docs from the internet. And core is fine and all, for data center usage where watts matter, and to run in Linux, but as someone writing enterprise solutions, switching operating systems would be a huge waste of effort. I’m happy to run on the framework, but I’m constantly having to battle developer sentiment that we should “be ready to run .NET on Linux” that comes from all the Core propaganda.

Rewriting framework and standard libraries — I’m sure that will be nice after a while, but I’ll sit this transitional phase out.

Specially irritating is what is still left out of .NET Standard 2.0.

Apparently Xamarin.Forms alongside XAML Standard is going to be the UI story for .NET Core, as communicated at .NET Conf 2017 sessions.

WinForms will never die.

There are people still writing fresh COBOL and RPG code in 2017 as well.

I do have an ongoing WinForms project, but only because it integrates with an application that was initially developed for Windows XP.

XAML designers, specially Blend, are much more powerful than the WinForms one.

But the reality is that when I want to create a simple UI to automate a task or visualize something internally, winform is just perfect. None of my users care whether there is a flashy colorful touch friendly UI or a bunch of grey forms. They are all going to run it on crappy workstations running windows 7 anyway. And it's not about the UI, it's about the numbers that it shows.

XAML designers can be used just like Forms for those purposes.

Dropping elements from the toolbox into the form, setting properties and code-behind event handlers.

No difference here, there is no need for MVVM over-engineering if the requirements are basic as you say.

With the advantage that XAML layouts are much easier to work with than TableLayoutPanel.

WinForms doesn't exist on .NET Core.

They're getting more and more opinionated in some of the frameworks too, it's getting quite tiresome in the asp.net field. First it was harping on about pure restful controllers which are nothing but a massive PITA, then I had a dabble in ASP.net Core and they'd changed ConfigurationManager to be Dependency Injected instead of an incredibly simple static object.

Yeah it's great improvement to have it nicely typed, but keep it static, I don't want to be DI-ing everything, especially when I'm just throwing together a prototype.

I want easy to use, not dogmatic adherence to ideals that gain you absolutely nothing but a confusing mental model in something like semi-permanent config.

Opinionated and changing opinion frequently... First we had webforms, then rest api, then asp.net mvc, then asp.net core mvc and now razor pages to bring back webforms...

With a couple of dabbles in OData.

ODataControllers are some of the most painfully bad things I have ever had the displeasure of programming with, I'm migrating our code bade back over to using API controllers with the semi-broken OData plugins rather than use them.

Admittedly part of that is because OData is great for plugging into grids like datatables for jquery or kendo grid, but otherwise incredibly over-complicated.

It sometimes feels as if they can't make their mind up about anything, and yet invest heavily in the latest fad that disappears a year later.

Surprised they've not released an update yet that forces everyone to use yarn instead of nuget.

Not that frequently.

Web forms are from 2002. It‘s ancient by today’s standard, much older than e.g. facebook or youtube.

> Keeping it simple is what has made the success of competing languages like python.

It's harder than that.

If you come to the Python mailing list, you'll notice that we get heated debates about:

- rejecting awesome features;

- allowing very complex use cases;

- integrating radically different paradigms;

All that while keeping in mind the general look and feel of the language should not change.

Honestly the python-idea mailing list is a land field because of this, and an exhausting place to contribute, but the result is amazing.

It's why we have the type hints the way they are: most people can completely ignore them. You can even provide them using comments, or in separate files. Checking types is done with an external program or your IDE. They are completly non intrusive.

This way Python remains Python, but you can scale up to full type checking when you need to.

This is a damn hard balance to find for a language born in 1995 with millions of users including sysadmin, data scientists, web devs and geographers.

Yes, the fragmentation at the .net framework level is just incredible. Especially as Microsoft own the entire platform -- they've inflicted this problem on themselves!

It seems like every couple of years they decide to try to carve out a common subset of all the different frameworks, and have that be the real Core Standard Portable .Net Framework, but it never quite catches on and they end up with just yet another variant to support.

The languages are great (both C# and F#), the runtime is great, the compiler and debugger are great, but the SDK versioning is a total mess and the package manager (NuGet) is pretty bad too.

(Sounds like this book covers the bits that are great)

> "the package manager (NuGet) is pretty bad"

Have you had a chance to try Paket? It's meant to have overcome the common issues with NuGet, as well as provide new features that NuGet doesn't provide:

https://fsprojects.github.io/Paket/index.html

I haven't, I'll check it out!

Having worked for 7 years on the .NET runtime team, I can attest that the BOTR is the official reference. It was created as documentation for the engineering team, by the engineering team. And it was (supposed to be) kept up to date any time a new feature was added or changed.

Reply on news.ycombinator.com