Anders Hejlsberg – What brought about the birth of the CLR? (2004) | Hacker News Reader

Anders Hejlsberg – What brought about the birth of the CLR? (2004)

channel9.msdn.com

62 pointsmkr-hn33 comments

I came across this while looking into a question in the thread on Microsoft Edge: https://news.ycombinator.com/item?id=9481043

Thanks for the digg. Still not clear he's considered the father (definitely a mind-share contributor according to your link). Perhaps there was none, but usually there is front-person leading the charge for things like this w/in an organization.

I worked with Anders for years (he was on my interview loop, still no idea how I got in), and no, he's not the father of the CLR. That project (Project 42, COM+, NGWS, among other names) I think even pre-dated his arrival at MS. Anders was pretty focused on C#, which _was_ a direct consequence of the dust-up with Sun over Java. The MS Java libraries (WFC, etc), COM+, and C# sort of all converged to become what is considered CLR+.NET today. When VJ++ was killed via the Sun suit, the CLR was already in existance, but still pretty rough. It was a solid (fun, but painful) 3 years between when that happened and when .NET 1.0/VS 2002 shipped.

The "father" of the CLR is probably Mike Tougtangi, or Chris Brumme. I'm not exactly sure who was on that original team.

Who killed VB6 and thought VB.Net would be a good idea? I remember a long gone Channel 9 video where the VB guys had arguments for .Net and showed a demo of the third part transition tool, that ship as Lite-version with Visual Studio 2002/3.

The idea was that a converged, single, multi-language runtime and framework was the way to go. This is the way the culture works in Redmond - that's considered "strategic thinking", which is only exists in that bubble. It wasn't that the plan was bad, it's that it was unrealistic to think that the users of a very mature, very scenario-focused product would be happy with a V1 generalized product that was sorta-kinda the same thing. This was obviously false, and I actually fought against the porting tool because I didn't think it would work (it didn't), and just piss people off (it did). To keep VB6 alive until VB.net matured is anthetical to the way the place runs. Newer is _always_ better, even if it's not, and there lacked any incentive in the comp system for people to take care of the existing userbase. So, that's what happened.

> there lacked any incentive in the comp system for people to take care of the existing userbase

Can you explain that? Are there incentives to do other stuff?

The basic system - no. As of 2012 when I left, comp was about what your management was interested in. Maybe "take care of existing users" is on your review commitments, but what's really on there if you want to get ahead is: ship features, drive future business, etc. As such people wanted to work on the next new thing, it was relatively bad for careers to be on existing old things. Massive variations between groups, but basically that was the culture.

Thanks for sharing your experience, it helps to understand some of the business decisions.

This really puts into focus the meaning of "strategic thinking": abandoning current customers in favor of potential future customers.

Honestly there were a lot of bad design decisions in VB6 that needed breaking backward compatibility. Requiring to use "SET" to assign objects, parameters being BYREF by default, inconsistent base (1 or 0) for various collections. VB.net isn't that difficult to migrate to and when one gets used to it, it's hard to have much nostalgia for VB6.

Where you there when generics got brought in? What was that like from MS's side?

Yeah - this is where Anders shines. Generics were brought in primarily to avoid boxing/unboxing costs of value types, but really are incredibly powerful when used properly. And I'll say that generics in C#/.NET are done very well. Every time I use Java, I want to use generics until I remember Java's generics are confusing and almost useless.

I really miss having them when doing work in other languages, even with some of the covariance gotchas, they're just amazingly good.

I thought the CLR team had no plan/way to ship genetics in the CLR, and C# would have had to gone with erasure, like Java. That the first C# with generics came from across the Atlantic. Isn't that so?

According to Wikipedia [1] ("which never lies"):

> He was the original author of Turbo Pascal and the chief architect of Delphi. He currently works for Microsoft as the lead architect of C#[1] and core developer on TypeScript.

[1]: https://en.wikipedia.org/wiki/Anders_Hejlsberg

In 1996, Hejlsberg left Borland and joined Microsoft. One of his first achievements was the J++ programming language and the Windows Foundation Classes; [...] Since 2000, he has been the lead architect of the team developing the language C#. In 2012 Hejlsberg announced his new project TypeScript—a superset of JavaScript. -- https://en.wikipedia.org/wiki/Anders_Hejlsberg

For better or worse, he influences with his C# syntax ideology now TypeScript and indirectly JS/ES6.

Also interesting - why this kind of framework (.NET) required to be under managed runtime instead of being native? Like Delphi.

People often say "managed runtime" or "VM" but those things are not clearly defined. For example, if we look at Java and .NET, the two best known language VMs, they really provide few completely orthogonal features:

1. OS isolation -- the VM provides a platform-neutral API for OS services, and abstracts away details like clocks etc.

2. Intermediate language representation, a JIT (or several JITs, in the case of the JVM) and dynamic code loading/manipulation.

3. A GC (or several GCs, in the case of the JVM).

Each of these features is completely independent (in fact, some JVMs don't even provide #2, opting for AOT compilation. Golang, OTOH, is not perceived to run in a "VM" -- simply because its "managed runtime" is statically compiled with the program, and no JIT is available -- yet it provides #1 and #3, just like some JVMs).

Now, as to why you'd want to provide each of those features -- well, there are different reasons. #1 is great for cross-platform portability. #3 is great for simplifying programming, esp. in multithreaded settings. #2, the JIT, is actually an optimization layer with some tradeoffs. A JIT can always produce machine code at least as efficient as the most sophisticated profile-guided optimizing compiler, and then some; to do that, it trades off warmup-time, and extra CPU cycles that can make a difference on energy-constrained platforms (although a JIT with caching might enjoy both worlds). In addition, a JIT is an absolute necessity when trying to achieve high-performance when running dynamically-typed languages. Another downside to JITs is that they're very hard to write well (i.e. while they can surpass the code quality emitted by AOT compilers, it takes more effort to even match that quality).

So, in general, there is no such thing as a "managed runtime" -- just a collection of features, each with its own motivation. That name also has a connotation of overhead, which again, is completely false. A GC may add some overhead (RAM, latency) but may also reduce overhead (throughput, more scalable concurrency) -- depending on your application. A JIT may add overhead -- warmup time, extra cycles -- but may also reduce overhead (more efficient generated code).

> So, in general, there is no such thing as a "managed runtime" -- just a collection of features

To rephrase my question - why it is not possible to have statically linked this collection of features into standalone executable? Like Go. I understand that Go is bare-bones compared to .NET, but Delphi/C++Builder also supports fully standalone executables. As for cross-platform (source) portability - it could use Ahead-Of-Time compilation into native exe.

OK, so you're talking about AOT compilation, i.e. doing away with the JIT. Of course it is possible. There are even JVMs that do just that. The question, then, is when is AOT compilation (and static linking) desirable? There are, of course, many situations where it is and many when it isn't.

Go is designed mostly for smallish programs (command line programs like Docker or simple services), so static AOT compilation and static linking makes sense.

Java, OTOH, is mostly used in large, important, performance-critical server-side services, where the added performance offered by having a JIT is important, and the warmup time isn't, while dynamic linking allows for dynamic code loading/swapping.

Just like there are JVMs that do AOT compilation to a native binary, there's nothing stopping .NET from doing the same[1]. There's also nothing stopping a single SDK from providing both options. It usually boils down to a question of what the users of that SDK need.

[1]: I would bet that that's exactly where MS is going. Like I said before, writing a good JIT is hard, and OpenJDK's HotSpot is years ahead of the CLR in that respect and only widening the gap with its next-gen JIT, Graal. I think MS would realize that it's easier for them to just do AOT.

You can compile C# native now.

Well... certain C#, which I don't know anyone actually writing (i.e. Windows 10 Universal apps).

It would be interesting if you could compile a traditional desktop app into a dependency-free EXE, or bundle up an ASP.NET app with an embedded server as you can with modern Go microservices. I would go from "somewhat interested" to "chugging Kool-Aid and changing my career path" if those use cases entered the picture. I'm not sure whether either of those are in future plans, though.

> It would be interesting if you could compile a traditional desktop app into a dependency-free EXE

I might be wrong about this, but my understanding is you can do this. The restrictions are mostly just about certain uses of reflection and dynamic linking.

> or bundle up an ASP.NET app with an embedded server

You can do that today: http://docs.asp.net/en/latest/conceptual-overview/dotnetcore...

I have been reading about ASP.NET 5 with much interest, but I'll probably engage with it more seriously in six months or so. It was still pretty flaky when I tried to get an OS X environment up and running last week.

It's also a bit confusing whether this "Kestrel" embedded server is production-grade (like Golang, or the embedded server options for Spring Boot in the Java world)... or whether it's meant for development only (https://www.nuget.org/packages/Kestrel).

It's amazing that CoreCLR is coming to multiple platforms within the next year or so... but what IS the production deployment story for Linux going to be, seriously? What is the development story for OS X? (VS Code looks interesting, but surely they're going to have to port the "real" Visual Studio, right?)

Don't get me wrong, I'm not a naysayer! Since I've started exploring .NET, I've found C# to be an improved version of Java that I'd really like to work with. F# seems like a more coherent alternative to Scala. Documentation, availability of learning resources, and community friendliness are outstanding. Still, I'm not 100% convinced yet of the cross-platform reality living up to the extraordinary hype. It really is too soon to judge, but I'm definitely watching closely and believe that the next 6 to 12 months will be crucial.

Had Sun not sued Microsoft for making an incompatible JVM, would the CLR exist?

Had Sun not sued Microsoft then Microsoft would have ran off with the platform and built themselves an incompatible JVM and framework (common java + Windows-only Microsoft extensions).

Essentially, that's what they ended up doing anyway..."built themselves an incompatible JVM and framework (common java + Windows-only Microsoft extensions)."

To copy Java.

Yeah, copy the good stuff. And then leave it in the dust :)

But, in the end Java won. Open sourcing their CLR was pretty much a sign of defeat as it was never gaining traction.

As for the language differences, Java will eventually catch up with all of the syntactic sugar.

I've worked with COM quite a bit. The .NET runtime does makes working with Windows much nicer. However, COM has not been completely been abstracted.

Still waiting for things like Extended MAPI and other parts of the ShellAPI to get "wrapped" up somehow. But I'm moving on from those spaces so it does not matter to me personally too much now.

It's true. I recently explored In-process side-by-side, a feature where you can call legacy .NET 3.5 code running in the 3.5 VM from code running in .NET 4.5. It does this by spinning up two copies of the CLR.

We figured this would be awesome, as we wouldn't have to port the old libraries to .NET 4.5 (and yes - porting would be required. Sadly that library was written very poorly and used reflection on private methods that didn't exist in 4.5, among other uglyness).

The long and short of it though is the way you "call into" the .NET 3.5 code is through COM. This had lots of implications, such as no support for generics, lots of difficulty debugging, etc. We decided to just bite the bullet and upgrade the old lib instead, and I think we made the right choice. COM is a mess.

no mention this is vid/audio

Reply on news.ycombinator.com