
Anders Hejlsberg – What brought about the birth of the CLR? (2004) - mkr-hn
http://channel9.msdn.com/blogs/thechannel9team/anders-hejlsberg-what-brought-about-the-birth-of-the-clr
======
mkr-hn
I came across this while looking into a question in the thread on Microsoft
Edge:
[https://news.ycombinator.com/item?id=9481043](https://news.ycombinator.com/item?id=9481043)

~~~
rottyguy
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.

~~~
shawnb576
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.

~~~
frik
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.

~~~
shawnb576
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.

~~~
pron
> 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?

~~~
shawnb576
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.

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

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

~~~
pron
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).

~~~
zerr
> 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.

~~~
pron
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.

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

~~~
iwwr
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).

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

------
vermooten
To copy Java.

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

~~~
bitmapbrother
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.

------
pcunite
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.

~~~
seabrookmx
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.

------
bootload
no mention this is vid/audio

