Hacker News new | comments | ask | show | jobs | submit login
.NET JIT and CLR – Joined at the Hip (mattwarren.org)
121 points by benaadams 7 months ago | hide | past | web | favorite | 38 comments

These blog posts on deep dives into the .Net internals is one of my favorite side effects of it being open sourced.

I also enjoy the internal blog posts from teams such as Edge at MS.

It is a great time for software to be sure.

> ... is one of my favorite side effects of it being open sourced.


I would never have the time or expertise to work all this out just using WinDBG or similar. Having the source, including decent comments and things like the BOTR [0] is amazing for exploring the internals!

[0]: https://github.com/dotnet/coreclr/tree/master/Documentation/...

It's great for sure but there were deep dive books much more comprehensive than this on the clr and jit that I read a decade ago. Microsoft press has always had great technical resources. I actually really miss the days of technical books. Blog posts serve a purpose but they definitely never adequately replaced books.

> It's great for sure but there were deep dive books much more comprehensive than this on the clr and jit that I read a decade ago.

Out of interest, which books are you referring to? I'm always on the lookout for more (decent) technical books to read! :-)

These are great!

I'm impressed with the testing approach.

Is anyone aware of similar articles/explanations of the JVM runtime and JIT?

> I'm impressed with the testing approach.

Likewise, I really liked the SuperPMI tool, it's a very interesting way of testing

> Is anyone aware of similar articles/explanations of the JVM runtime and JIT?

I've recently come across this article about the JVM that discusses internals, http://blog.jamesdbloom.com/JVMInternals.html

Also the slides from this presentation a very good https://jpoint.ru/en/talks/5vqeeeo89yk6q8qmm0y8sg/

.NET, Java, etc. all sound so 1990-ish.

> .NET, Java, etc. all sound so 1990-ish.

.NET 1.0 was released in 2002 ;-)


It already felt 1990ish back then, a "me too" moment because of Java. At least it was not tied to a PL but they couldn't refrain from inventing yet another one anyway.

It wasn't a "me too", it was a "we can do better", and IMHO, they did.

C# as a language is very nice to use. 1.0 was lacking a few crucial features, such as generics (while using 1.1, I was using a code generator to create strongly-typed collections). It sort of felt like Python at the time - Batteries included. Even at 1.0, the standard library was quite extensive. By 2.0, generics were there, and that ameliorated my biggest complain with the language. Every iteration since has been a boon to developer productivity.

Some features, such as Linq are hit & miss for me. On one side, Linq is great in that it allows one to succinctly express complicated logic. On the other hand, it also hides a lot of complexity and it can be hard to determine the algorithmic complexity of even the simplest Linq statement, unless you closely examine all of the types involved.

Also, not to be forgotten is the tooling. From day 1, tooling for .Net (C# in particular) was top notch, and it's only gotten better over the years. IDE support was great (except lacking edit & continue) - Intellisense was fast and worked incredibly great (and fast), with the built-in support for XML documentation, its was also helpful & informative. Compared to the Intellisense support for C++, which was so bad I've sworn off VS for C++ work (last time I tried was VS 2005, when it'd either hang or crash often) and rely upon command-line Vim instead.

I don't do much C# currently, but I still love the language. I'm probably about 1% C# and the rest C++ currently.

Edit: I'm aware that C# was largely born after MS's ill-fated embrace of Java (J#, IIRC) and the suit from Sun. I see C# as an embrace what worked, kill what didn't. Java still has some large annoying works (Exception specs), and C# said: we don't want that.Even C++ realized that exception specs sucked and ditched them in 2011, but Java's still clinging to them. Also: objects vs value types.

I want to offer my personal counter anecdote from the dissent around here. I recently got into fulltime C#, on purpose, over all other possible options. There's a lot of reasons why.

- Industrial strength language with static types. I used Python and JS a lot, I'm passing.

- Good tooling support, not every language has this.

- Good support in general, backwards compatibility (or side by side support).

- Game development possibilities with Unity.

- Mobile development with Xamarin.

- WebAssembly support already in motion with Blazor.

- Not cool, which is exactly what I want in tech. Fads don't belong in tech. Means more job opportunities for me too.

- Good serverside platform with .Net Core.

- Native on the most popular desktop platform.

- With full MS stack, opens up the option of being the sole IT guy at a small to midsize company. It's certainly possible.

- Similar to Java, lets me move over with minimal disruption if the job market demands.

- Write once, jobs everywhere. I can move back to the smaller area that I'm from. I live in Chicago right now but I've worked in 3 countries, 3 US states & .Net is popular enough in all those locales.

- Career stability, less technical churn in the C#/SQL space (and Java). I'm very tired of flavor of the week scripting languages that are many times really used heavily in NYC & SF.

- I'm not looking to learn new languages all the time. I'm looking to perfect myself as a consummate professional developer. I want to fully envelop all the things that I think people should, discrete mathematics, design patterns and I think learning new languages is great but there are other ways to become an exceptional programmer.

For me, it was C# or Java to base the next leg of my career on. I like the abstraction layer they're on, on a technical basis I think they nailed it. Sometimes newer isn't better. This isn't going to be popular, because a lot of people believe in Javascript and invested heavily there career-wise. I didn't want to and wasm is going to chunk out 25% of the single language fullstack market from Javascript in 5 years anyway and keep taking. Ideally going forward on the web side, I would only do a SPA with Blazor or static pages.

That's why I like C#. I'm looking forward to many relatively stable years in my career within the C#/SQL world without the trends. If it collapses, Java is in a similar situation marketwise.

The core of it is very good but the tooling falls on its arse on large projects and the build toolchain is dire and the update mill and roadmap schizophrenia has not been friendly. Also integration with other MSFT products is eyeball grating (VSTO for example).

Been with it since it came out in 2002. I wouldn’t start a new project on the platform in 2018, even .net core.

Can you give reasons why you wouldn't use it in 2018? Also, what is your proposed alternative? It's disingenuous to dissent without offering the people the savior. If I own a company, need a large swath of developers and we'll assume any random product that could consist of mobile/native app/games, you name it, I'm going with C# everytime because there's nothing else like it. I'm not committing 100KLOC+ of code in some random version of Python, that like all code, may live a lot longer than anyone ever expected. That's for sure.

It's one of very few fullstack solutions available for game (serverside+Unity), mobile (serverside+Xamarin) and web (serverside+Blazor), maybe you want a WPF or UWP app too. Or all of it for a single stack shop for anything you want. Nothing else is pulling all of that off today, and may never. MS is doing a fantastic job keeping it vibrant, alive and supported. You're not really convincing me without more than what you left there. A few years ago, yes, I would've agreed 100% with the general attitude but the tide has turned. I dove in deep on Python, got back out before I hitched my career to that.

To specifically address the points I disagree with.

-Tooling falling off? Examples? I've worked around or with it for a decade now and never saw the tooling fall off.. it's best in class. I really don't understand how this is any worse than anything else.

-Build toolchain? An example of a dire toolchain is Javascript's, not C#'s. That is a mess that I want nothing to do with. I can't get behind this one either.

-Roadmap schizophrenia? They have it figured out now on the .Net Standard and Core. Your alternative is Python 2 to 3 transitions. That was the real mess.

-Integration with other Microsoft products? Good or bad, you probably aren't going to find better integration with MS products than using .Net. I can't get behind this complaint either.

That said if anyone has attacks on .Net I'm willing to listen but I don't see it. It's the worst, except for all the others.

Tooling. Visual Studio doesn’t scale to large projects (2MLOC+). It’s still a 32 bit app and it regularly just throws the towel in and crashes.

Build toolchain. MSbuild performance sucks among other things. Also Consider VSTO build toolchain. We have to ship VS on build machines for example which is expensive and unnecessary. Even if we throw ridiculous IO capacity and CPU at build we hit a wall quickly where there is no return. On top of that managing framework upgrades across tens of solutions is a nightmare.

Roadmap schitzophrenia. The core is relatively stable. I’m talking about the ecosystem of abandonment over the last 10 years or so. See my post history for a list of just MSFT projects. Ancillary third party libraries in nuget also suffer from sudden disinterest from the maintainers and abandonment on a regular basis.

For your use cases it’s probably the least bad option but on the server side or the desktop these days I wouldn’t use it. Qt/ex/python on the desktop. Python or Go on the server side depending on the use case required.

The key thing is developer latency and maintenance cost. While the runtime performance is good the dev side of things is not. It gets expensive quick.

Which tooling (as far as IDEs go) and for which langs don't fall on it's arse on big projects?

I have been using C# a lot recently. I can't stand it. It feels like it it lacks a coherent design. I'm not a huge Java fan either, but at least it feels coherent to me. I have used a lot of different programming languages and can see the values in their different approaches, but I have a hard time seeing it in C#. Also C#'s tooling is only good on Windows.

what don't you find coherent about the desgin of C#? On HN there is far more value in being specific about your particular concerns rather than giving no reasons. There is a lot stuff written on the design of C#.

Some examples from an old timer.

Currently it has three different ways of using event handlers.

The original way, anonymous delegates and lambdas.

The semantics of for loop which were fixed around C# 6.0, need to hunt down release notes for this one.

Something like .NET Native and .NET Core should have been there on v1.0 instead of tying the runtime to the OS.

Those are 3 options, and have different nuance. They also were added to the language in later versions but you can use what you what works, I find it hard to see how that makes the language incoherent as if multiple options are bad.

What exactly changed with a for loop?

The runtime is different from the c# programming language. Originally when this all started, Windows was the focus and Linux/open-source were not an option, so saying it should be there from v1 doesn't fit when there was only one OS that it was planned to run on.

Multiple designs for the same feature makes a language harder to understand for beginners, only understandable by those that grew up with language.

I got it wrong, it was foreach, not for.

The semantics for the variable were wrong when given into a closure, it was a breaking change in C# 5.0 to fix it.



Thing is, there isn't just one version of Windows, and updating the CLR in place can be lots of fun, to the point many enterprise postpone it ad infinitum.

This was the original driving idea for .NET Core, when ASP team started doing it, making it easy to allow IT to update Windows production servers to newer versions, porting to other platforms came afterwards.

Can you say how those make it incoherent? 3 different ways to define a function, a breaking change in the language a while back. And only their implementation run time was tied to the OS, Mono came along and provided another

They are not the same features, delegates and lambdas are very different even if they look similar, and go far beyond just event handling. Also what language is perfect at version 1? It's good that the language keeps evolving and gets better and beginners can learn just fine.

Are you stuck on .NET Framework? If you arent then .NET Core already solves all of the maintenance problems by being deployed completely self-contained. It's a similar problem with many other language toolchains as well and .NET Framework at least saves work by being a single install that can be automated away with group policies. Enterprises postponing software updates is a problem with the enterprise, not the framework.

Try F#. There is a VS Code plugin with about all the tooling you need. Fully supported by dotnet core, so you don't have to use it on Windows.

I am not a fan of VS Code. It feels clunky and slow. Also Rider's auto complete is much nicer and faster.

So I have considered F#, but it doesn't seem that compelling. Also it seems like the tooling is worse on other platforms.

A friend who uses vim says adding the vim plugin to VS Code makes it very fast. Just passing this on.

Jetbrains Rider = win/macos/linux

Quite competitive with msvs, if not better

I could see how people could say that. As someone that loves to explore languages and frameworks. My opinion is if you haven't checked out the new .NET ecosystem it's worth a look/revisit.

Perhaps I will. I have a huge bias - PTSD from frameworks and I could not swallow why GNOME tried to steer to .NET/Mono at one point.

Can you expand a bit on what you mean by "PTSD from frameworks"?

Sure. Basically, fear from lock-in, fear from having to do major rewrites because version+1 is completely different, or because vendor ditches the whole thing or goes bankrupt.

To be fair, Java and .NET fared well since then - both still exist and it it is very convenient to e.g. drop an old JAR in a project and just use it without issues.

Microsoft is arguably the best in the entire software industry at maintaining backwards compatibility. They go to extreme lengths to maintain support for older code and it's relied upon by many major enterprises so you're not going to run into issues unless you're planning on having something running for 50 years.

No it’s really not. We’ve been left SOL on numerous occasions and the churn rate is so high that it’s literally only safe to use the bits right at the middle of their products. And we’re talking on a relatively short three year window here.

What are you talking about specifically?

WPF, WCF churn, silverlight, appfabric/velocity, the disaster that was windows workflow etc etc

WPF is still supported and developed. Appfabric/velocity is now Service Fabric which has much more functionality, runs many Azure and MS cloud services, and is open source.

Silverlight was unfortunate but overall good for the web. You must realize that even Flash, the vastly larger competitor, also died and gave way to much better browser native APIs.

I don’t know about Windows workflow but it’s important to keep in mind the difference between abandoned products vs the changing software trends landscape.

Is WPF dead? And what's it been replaced with?

.NET Core has pretty strong backwards compatibility rules:


> We generally don't accept change proposals that are in bucket #1.


> Bucket 1: Public Contract Clear violation of public contract.

> Examples:

> - Renaming or removing of a public type, member, or parameter

> - Changing the value of a public constant or enum member

> - Sealing a type that wasn't sealed

> - Making a virtual member abstract

> - Adding an interface to the set of base types of an interface

> - Removing a type or interface from the set of base types

> - Changing the return type of a member

> - ...or any other incompatible change to the shape of an API

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact