Live data from Hacker News

A History of .NET Runtimes

mattwarren.org

71–80 of 102 posts

Re: A History of .NET Runtimes

#71
post #67

Earlier quoted context omitted.

> Java has everything that .NET has Java offers nothing for game developers, there're multiple game engines written in .NET or using .NET. Java only runs on Android, .NET on all mobiles. Native interop in Java is a joke.

Actually Java had jMonkey and LibGDX before Unity became the engine it is today. Which initially was Mac only and only used Boo and Unity Script as programming languages. Khronos does have some official OpenGL specs for Java. There are none from them for .NET. Java runs on iOS via Codename One and Gluon AOT compilers. Native interop in Java was made hard on purpose, as Sun was pushing for WORA. Oracle is in the proce…

About games, maybe the reason is lack of value types in Java which stresses GC and creates pauses. .NET works OK, Unity is the most obvious (cities skylines, kerbal space program, etc.), but also XNA, MonoGame, SharpDX. This creates an ecosystem with healthy amount of libraries and other resources.

About native interop, I know Java did it on purpose, but as a developer I don’t care much about the rationale. I’ve heard about upcoming Valhala years ago (announced in 2014), still not ready.

Related to both of them, .NET core 2.1 already has SIMD support. Some parts of it is experimental, but it already works more or less OK, esp. on Intel/Amd.

Re: A History of .NET Runtimes

#72
post #33

As someone outside the .net world, is there a wasm version? Can I run a .net language in a web browser and have access to the DOM, or render the UI for a .net app as DOM objects on a web page? That would be super useful.

or if you like functional, http://fable.io/ compiles F# to js to run in the browser

Re: A History of .NET Runtimes

#73
post #7

I think the history of the internal politics at Microsoft in regards to .NET and also the external industry trends is fascinating. The common thinking is that C# & .NET was a ripoff of Sun Java because of the "write once run anywhere" threat. That's sort of true but missing some nuance. I'm not a MS insider but here's my understanding of what happened. We have to separate the C# language from the CLR runtime. In the…

It does seem like all these .NET projects are reactions to rival technologies. C# is a Java clone, C# generics are an (arguably improved) Java generics clone, .NET Micro is J2ME, Silverlight is Flash, etc. What are some examples of where C# / .NET paved the way and others followed? Maybe popularizing async/await? I’m definitely not claiming MS as a whole is always a follower. It seems like Direct3D led the way for th…

> C# generics are an (arguably improved) Java generics clone

That depends on who you ask.

My opinion is Java doesn’t have proper generics. In Java they’re just language-level syntactic sugar.

Type system is broken i.e. type information is lost at compile time. This makes it hard to do functional-style programming in Java, that’s why other people made Scala.

Performance is broken too, generic containers box everything into objects causing huge performance penalty for containers with value types.

Re: A History of .NET Runtimes

#74
post #59
post #49

Earlier quoted context omitted.

> 1. It is possible to write reasonably "functional" applications in .NET. The only problem I had with that is lack of built-in copy-on-write data types and prevalent nullity. I've tried to minmise that pain over the past few years with my 'functional language extensions' for C# [1]. It's a library with most of the common monadic types (as structs so there's no null issues); Immutable collection types that don't have…

Wow, what a nice project you have there. I've read that the next C# will have non-nullable reference types, have you thought about how to make your framework fit in with that? It's a "natural" Some/None in a way.

> Wow, what a nice project you have there.

Thanks :)

> It's a "natural" Some/None in a way.

If we lived in the perfect non-nullable reference world from the start then it's arguable whether Option would ever have been needed - and so going forward it should be needed less, or not at all for some devs. The question comes when you need an optional value, and so you use nullable references instead of Option. With nullable references the `null` still honours the contract of `A` - this is what Option protects against. If the flow-analysis for nullable references is good enough to spot that you're possibly going to use null and then forces you to use a predicate of some sort (if/switch/ternary/...) to validate the referenced value exists then I think we're good. I understand that is what's planned, but it needs to be bulletproof.

There will be devs working in the nullable reference world for a long time (due to difficulties with moving to the new world when it comes) - and so I fully expect Option to be useful for its null protection reasons for a long time.

The story is a bit bigger than just protection against null though. If instead of seeing Option as A|null, you see it as A|B, where B is the single-value type: Unit. Then Option is A|Unit. If you then look at Either which is designed to represent one of two alternative values: L|R then it's pretty easy to see that Option is Either. And then when we look at Try which is designed to return A or capture an exception and return it as a value, then that can be seen as Either...

All of the types that represent one of two values have lots of additional powerful functionality: Fold, Map, Bind, BiFold, BiMap, BiBind, etc. and have been designed to seamlessly switch between each, which won't exist on the standard nullable reference types. So, there's still a place for Option in the bigger scheme of things.

Personally, I can't wait for non-nullable references to come in. I built language-ext to try and get a handle on a 10,000,000+ line code base that kept falling foul to null reference exceptions (along with other common C# coding world problems). It was 100% to help me and my team build more robust code. Non-nullable references is a feature we will turn on immediately, even if it takes a week to fix up the warnings and errors it spits out, this is going to be one of the most important updates the C# team have done.

Re: A History of .NET Runtimes

#75
post #7

I think the history of the internal politics at Microsoft in regards to .NET and also the external industry trends is fascinating. The common thinking is that C# & .NET was a ripoff of Sun Java because of the "write once run anywhere" threat. That's sort of true but missing some nuance. I'm not a MS insider but here's my understanding of what happened. We have to separate the C# language from the CLR runtime. In the…

I think the game changer (one way or another) will be webassembly, which will level the playing field in term of portability. Then the popularity of the different languages being ported to wasm will be based on their own merits.

Re: A History of .NET Runtimes

#76

Back in 2008/9 I was a co-founder at a company (Red Five Labs) that created a .NET Compact Framework runtime for Symbian OS (featured on most Nokia & Samsung smartphones at the time). We got to a .NET CF 2.0 level of compatibility. It was a venture-backed startup out of Johannesburg, South Africa. Although we wrote the runtime ourselves, we made extensive use of some of the mono libraries until we were able to rewrit…

Nice! Thanks for the info. I think that an update to the post is due, turns out that I missed quite a few!

Re: A History of .NET Runtimes

#77
post #30

You missed two that I can think of: (1) the runtime written in F# that Frank Krueger’s Continuous uses (and I believe also Xamarin Live player uses in some fashion.) (2) Goa WinForms was a C# compiler that targeted the Adobe Flash Player, and implemented part of the BCL and WinForms UI. If you include the CrossNet I think this also counts.

Nice! Thanks for the info, I'll check those out, I'd not heard of either of them.

I think that an update to the post is due, turns out that I missed quite a few!

Re: A History of .NET Runtimes

#78
post #51

The AOT compilers misses NGEN, which is part of .NET Framework since v1.0, although it only does dynamic linking with very little optimizations. And the cloud compiler created for Windows Phone 8.x, based on Bartok from Singularity. https://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-an... https://channel9.msdn.com/Events/Build/2012/3-005 .NET Native is an improvement of this work.

I tried to only focus on runtimes, although the line got a bit blurred at times! But yeah, it would be nice to have included a mention of NGEN. When I get a chance I'll update the post

> And the cloud compiler created for Windows Phone 8.x, based on Bartok from Singularity.

Interesting, I didn't realise that all this came from Bartok, thanks for the info

Re: A History of .NET Runtimes

#79
post #66

Earlier quoted context omitted.

Next stop, making UWP crossplatform :)) Regarding the political issues, the Silverlight/WinRT clusterfuck also helped with WindowsPhone downfall. Release 1.0 and next major update offered a API incompatible with 1.0, what a clusterfuck....

> Next stop, making UWP crossplatform :)) they do not need. they have xaml over xamarin.forms, which supports all major platforms (including desktopn and mobile) it still says that its in preview however the only things that did not work well is when you need some kind of file interaction with the os, you need to create native views for all your OSs (i.e. NSFilePicker, OpenFileDialog, etc..) since there is no Xamarin…

Xamarin.Forms has to manage a lot of friction interfacing with the native UI controls. It's both an advantage and a disadvantage to it's approach. It has to conform to the common denominator of the native platforms, but gets to leverage the native look and feel. But this seems much harder to maintain long term. It would actually make sense if they created a XAML platform (like cross-platform UWP) that used its own rendering stack (similar to Flutter's approach) that wasn't beholden to the design decisions of an externally developed platform and having to reconcile the differences between different platform paradigms.

Re: A History of .NET Runtimes

#80
post #34

Few more missed include (Device CLR's were in C, Desktop/Server in C++): (1) CLR for Sony/Ericsson phone OS and (2) Variant running on linux (in 2001/2002). I worked on the Compact Framework team back in the day so there's a few more things to point out related to the internal politics of Microsoft at the time. The devices strategy was a mess even back then due to Alchin/Valentine/Ballmers love of Windows desktop 'ev…

> The origins of the CLR can be found in the purchase of Colusa in 1996 which had the Omni VM for running C++ in a sandbox. The original C# language was called cool and came from that project.

Thanks, I'd heard about 'cool', but I didn't know the part about Omni VM, that's interesting to know

Post reply on HN