Hacker News Reader

Comment by gmaster1440 | Hacker News Reader

Curious to see how this plays out with Microsoft investing in cross-platform development with .NET Core and .NET Standard.

The consequences of having multiple competing cross-platform options are already evident when using tools like intellisense in VS Code where you can (or used to be able to) switch between Mono and .NET Core runtimes and certain libraries were only compatible with one. And then there are build tools like Paket which currently only support Mono even though Paket itself can provision .NET Core runtimes.

View on HN

We now share a lot of code between the runtimes, it is an effort that we have taken seriously to improve compatibility, and capabilities.

Today, when you checkout the Mono source code, it brings CoreRT and CoreFX.

From a user perpective, we have worked to make a universal API surface that goes everywhere Mono, .NET or Xamarin go, it is called the .NET Standard, and last month we released a major upgrade to .NET standard that grew the API surface across the board.

As for the runtimes, they have different pros/cons so they currently can not be unified into a single one, so we need to maintain different ones, but we are working to make the tooling work better across the board.

Until .NET Core starts supporting GUI frameworks there will always be a use case for Mono. I can get up and running with GTK# relatively quickly for a cross-platform desktop application using Mono when that isn't the case for .NET Core. That being said, if I were to build a web app I would definitely go with Core over Mono.

There is nothing preventing these GUI frameworks from working on .NET Core. They might need some work to support it but its entirely possible.

https://github.com/AvaloniaUI/Avalonia

Avalonia is in alpha right now and I would not trust a production desktop application with an alpha GUI toolkit. It is entirely possible to get frameworks like GTK# working on .NET Core but the problem is who is going to do that?

The last time I looked, GTK# wasn't a good experience for Windows users as it has to be installed separately - has this changed?

As long as we have things like this: https://github.com/dotnet/corefx/issues/19773

And this: https://stackoverflow.com/questions/27266907/no-appdomains-i...

And did I mention this? https://github.com/dotnet/coreclr/pull/8677

As long as we have things like that, and as long as .NET Core continues to pander only to the lowest common denominator of developers, then the Mono project is still providing value. It is not a matter of "competing".

I can't believe that people want to bring their old anti-patterns to coreclr. Running processes is a work for the operating system, not the language runtime. Maybe asp core should run kestrel as a kernel module too?!

I guess if those people have to re-write their code from scratch to port to .NET Core, porting to other programming language becomes an option as well.

I think you're right to call out that it's not competing in every way, but there are some cases in which it is competing directly—and it's in those cases where it can be a frustrating developer experience.

I've been a (mostly) C# developer for 10 years, and am terribly disappointed with the way .NET Core is being managed. Something is definitely wrong when promises are made to assign a developer to the issue, full-time, and then no communication happens after that, for months. All they needed to do is test and merge the hard work done by a volunteer!

These problems are eclipsed by the the marginal success of the 95-99% of use cases that are covered by .NET Core.

One of the lesser-known areas that C# and .NET has shined, involves plugin and modular development. AppDomains and secure code regions are a feature of the runtime. For more esoteric use cases, the classic .NET runtime itself is customizable, with replaceable COM interfaces using the C++ hosting API. This is how SQL Server implemented stored procedures that could be written with C#.

The way .NET Core has treated the issue is tantamount to a betrayal of trust. I understand that they are trying to take things in a different direction, but doing so undermines the other features that .NET provides, and does so well with. Not to mention they did promise to work on, and merge the feature, before leaving people hanging with no further updates in communication. A cross-platform .NET Core that doesn't have this kind of feature is not going to do much that Python or Java cannot do. We should be far more worried about .NET Core competing with .NET Framework, than .NET Core competing with Mono.

Is Microsoft trying to provide a good tool, to empower developers to build things that could not be easily built before? Or is the primary goal to be seen as friendly to the Open Source Community, by providing yet another dumbed down, cookie cutter cross-platform SDK that deserves no relevance? Are they intentionally omitting or delaying features that one would use in more advanced scenarios, forcing developers to make a choice to use classic .NET Framework (Windows/Mono)?

It is starting to seem like the same old tricks by Microsoft, just more cleverly hidden.

I think it's pretty weak to assume that because MS isn't supporting your extremely rare and complicated scenario they are obviously malicious.

.NET Core has been a huge rewrite of the old framework, focusing on common scenarios which are easily cross-platform first, then the harder ones later. E.g. System.Drawing, which they eventually included (in 2.0 in believe) via incorporating several implementations for each target architecture, including one from Mono.

They'll probably get to AppDomains eventually, assuming it isnt outright impossible on linux/osx or introduces a massive security hole.

But not doing it right now cause you want it isnt evil: which is more important? Full support for System.Crytography, or say Oracle Ado.NET, or runtime loading/unloading of dlls? Hint, the answer isnt dll unloading.

I would be careful with the term "rewritten". CoreCLR is really old (Silverlight), before it was bound to UWP(x86/arm) and before it was cross platform ported to other operating systems. There was heavy code stealing from the .NET Framework, but the split is already long time ago (like 2005).

There are elements of truth in this, but it is not the whole story.

While Silverlight did produce the first portable version of .NET and produces a lot of the code that allowed .NET to be portable, this code has been now retrofitted into the main CoreCLR and the VM source code has been upgraded.

What you see in the public CoreCLR is now the state of the art and while I do not know how the exact mechanics work, my understanding is that the CoreCLR and the .NET Desktop VM that ships source codes are very close to each other - modulo branches, deliverables, freeze dates and other loose ends.

On the library front, there has been a lot of rewriting for the sake of portability, cleaning up the code, and making the code more maintainable, and bringing it to the 2017 standards of coding.

I stand corrected. Thanks Miguel for your work.

Perhaps remixed, trimmed and partially augmented are better terms

Yeah. I just commented it to avoid confusion. .NET history is more complicated but also more rational than often seen

Extremely rare? You did check the links I posted, right? There are many comments, and that is just the outspoken minority. It's one of the most requested outstanding items in their entire repository.

And it's not a matter of priority or security, it's a matter of transparency. The community was promised a review, and stress test, and that someone from MS would be working on it full time. They followed up with more promises multiple times. And then silence. You're completely missing the point.

I enjoy .NET a lot, but as polyglot consultant we currently are only focused on .NET for straight Windows development.

For us to consider to use .NET Core instead of Java or C++ for UNIX-like OSes, it still needs to catch up a bit with its bigger brother.

.NET Core and .NET Standard

I don't understand why they need so many different "cross-platform" standards. Why is the platform so fragmented when MS controls the whole thing?

.Net Standard is the standard. There is only 1 standard.

.Net Core is one implementation of the standard. .Net 4.6 is another implementation of the standard. Mono, Xamarin, Universal Windows Platforms are other implementations.

The idea is that any code written for .Net standard, will work across the different implementations.

As I said, I don't really understand how it's all supposed to fit together, but what I've found in practice is that completely random and innocuous methods are missing from the System frameworks depending on which "standard" you target in Visual Studio.

The .NET Standard spec has multiple _versions_, each of them adding more APIs: https://github.com/dotnet/standard/blob/master/docs/versions...

It's true that .NET Standard 1.0-1.6 had a lot of gaps but these should be rectified with 2.0 now so you shouldn't run into these problems anymore (otherwise there's usually a good reason why a method/API is missing from the standard).

Disclaimer: I'm working on Mono for Microsoft/Xamarin, primarily class libraries and tools.

Thanks for your work!

It's been covered by others here already, but my understanding, as an outsider reading all this, is that .Net Standard is like C99 or C++14, a standard or specification that defined how the language is to function, and then .Net Core is implementation, like GCC or Clang are compilers that implement the C/C++ standards. In the prior example given, Java has a standard for each version that defined how the language functions, and then there are virtual machines that implement that standard, such as Oracle's (originally Sun's) JVM implementation, OpenJDK, or in the distant past, the Blackdown Java port[1].

Contrast to languages where there isn't a spec, or the spec is the interpreter, such as Perl 5 (Perl 6 actually has a specification and multiple implementations or various levels of conformance), or things in between, such as Python with the Python Language Reference. There are benefits and drawbacks to a standard/specification. One benefit is that it's easy for someone to start their own implementation and test for conformance and have a high degree of surety whether it will work with existing programs. One downside is that when there's a problem found in the spec, it often requires more work to fix, as the changes need to propagate out to the implementations, which will have their own timelines as to when they can implement it.

1: https://en.wikipedia.org/wiki/Blackdown_Java

from what I've heard, .Net Standard 2 should be stable for a while and should fix the random missing stuff that was present in the various versions of .net standard 1.x

Naming is still one of the most difficult things. Then again we get used to bad names, and keep on... (For example why The JSON standard persist on calling things objects, rather than say... maps or dictionaries)...

.NET Standard is a standard like JDK version, which can be JDK 8, JDK 9 and so on... .NET Core is an implementation like OpenJDK, Oracle JDK If you write something for JDK 8 standard, like using the Java Time API, you expect it to work with either Oracle JDK 9 or OpenJDK 9 In .NET, the standard version, means that up to specific version of .NET Framework or .NET Core or any other implementation like Mono can execute the software. I don't see any real fragmentation here, one is solely for people that are ok with Windows and the other one is meant for people that are not okay with Windows (ofc the .NET Core is meant for more than just this). The same with Java, OracleJDK is meant for people that are ok with Oracle and OpenJDK for people that are not okay with Oracle. What fragmentation? There are but a few implementations and each of them have a clear use cases. It's not like choosing a JavaScript framework or a tool, now that ecosystem is a true fragmentation... And who knows, maybe with some time, the .NET Core will evolve to the point, where it will be the only .NET implementation

Because they have different runtimes, and Microsoft has been trying to clean up the mess created by Sinofsky regarding .NET, UWP and C++/CX.

Historically spoken, it was the WinXP security mess which forced the .NET team to take over WPF and then as a consequence build the different CoreCLR for Silverlight. That however was killed by the same guy who killed Flash. Mr. Jobs from Apple. The Win8/Mobile Team Just harvested the most modern technology at that time (CoreCLR).

There is a nice talk about it, somewhere on YouTube.

Win 8 sucked for .NET developers regarding API compatibility, because it required lots of incompatible changes, which are the reason Windows 10 FCU is the first UWP version to be finally compatible with .NET Standard 2.0 (4.6.1).

Then there was the whole 8.0, 8.1 with UAP, and finally UWP transitions.

The two only good things from UWP for .NET devs were finally getting .NET Native, which should be there since 1.0 given the Delphi roots of Anders, and the COM Runtime model that was in the genesis of .NET (formerly known as Ext-VOS).

I think the talk you refer to, is one from OS research group at MSR.

No the talk is from the .NET Rocks guys.

https://youtu.be/IqWar6cEWsA

UWP/UAP is a new UI stack from the Windows team BOUND to a CoreCLR. That is different with the existing .NET UI technology stacks.

Additional, the CoreCLR and its more modern Assembly packaging (System.Runtime vs mscorlib) made the code difficult to share (recompile or PCL). This is solved now by the .NET Standard.

> UWP/UAP is a new UI stack from the Windows team. That is different with the existing .NET technology stacks.

Which is what I meant with "mess created by Sinofsky regarding .NET, UWP and C++/CX.". I do have UWP experience since WP 8.

Thanks for the link about the talk.

Agree. History has not played nice with .NET but neither has with Java or Python.

Two other favourite ecosystems of mine. :)

I think the only popular ecosystem with a positive trending history is JavaScript. But... Na I do not start there :)

That sounds like the right answer. (I don't imagine Mono/Xamarin are to blame, as they were independent until recently. This is a big self-inflicted mess by MS.)

.NET Core and Mono are two different implementations of .NET Standard. It's a standard as described in the name.

.Net isn't the standard, it's Microsoft's implementation. (Or rather, .Net Core and .Net Standard are each Microsoft implementations.)

The standard is either CLR (Common Language Runtime) or CLI (Common Language Infrastructure), I'm not entirely sure.

Edit As far as I can tell, yes, even Miguel de Icaza is consistently misusing these terms.

Edit 2 - Nope, I'm wrong!

"The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations."

https://docs.microsoft.com/en-us/dotnet/standard/net-standar...

I see I'm mistaken -- thanks.

Jesus, it's like they went out of their way to make it as word-salad as possible.

There is no .NET Standard "implementation", you may be confusing .NET Standard with .NET Framework, which is the legacy Windows-entangled implementation.

(Yes, there are also ECMA standards for the CLR/CLI, C# language, and a somewhat small subset of the BCL [Base Class Library]. .NET Standard subsumes those underlying standards and then specs out a much larger set of the BCL and even some libraries that aren't strictly BCL but may as well have been in the way they've become standards such as ADO.NET.)

.NET Standard is an interface/spec and .NET Core and Mono are implementations of said interface/spec. .NET Core and Mono are currently focused on different needs/niches (as pointed out somewhat in the article here), partly born of their very different histories. .NET Core and Mono also share a bunch of code as it makes sense to do so with respect to their histories/needs/niches.

Right now it is kind of a cleanup phase ending with massive code reuse. But ultimately, I believe we continue to see both .NET Core and Mono flourish. Why? Because .NET Core and Mono have very different targets. Mono has nearly a decade of being factored into any kind of platforms while .NET Core and the CoreCLR will stay a workhouse for dedicated use cases. Same for the .NET Framework which has a full dedication to Windows with it's huge legacy and compatability burden.

>Mono has nearly a decade of being factored into any kind of platforms while .NET Core and the CoreCLR will stay a workhouse for dedicated use cases.

I thought the "dedicated use case" of .NET Core was to be THE cross-platform .NET implementation.

Yeah. Cross platform server side.

With factored I meant more: native compiled, three shaked, WebAssembly compiled, iOS allowed, Arm, PowerPC, ....

That's the status quo for historical reasons, but I don't think many see this as a desirable state of affairs.

Agree. But reverting this is really hard. Because it is crucial to .NET to play both fields right now for the next ten years :). Reworking Xamarin is not an option in a time when the race against Cordova, React Native, Node, Swift, Go and Python is fully ongoing. They are pragmatic here, how they should be.

.NET Core is the gateway to Azure, I doubt we would see it on anything other than platforms developers might use.

The source code for .NET Core as on GitHub now powers .NET Core and UWP. It is a toolbox. We might not see .NET Core with a UI stack directly, but other factoring might happen. E.g. Samsung is using it for their Tizen platform in an own CoreCLR based factoring, including an UI Adapter between Tizen and the Xamarin.Forms abstraction. That is pretty much toolbox thinking. Now they can offer a .NET Standard 2.0 / Xamarin.Forms based programming environment with "little" effort.

To be honest, I would refrain to use Tizen as positive example of anything.

Samsung already rebooted the SDK so many times, and the platform lack of security is well known, I doubt it will ever get serious beyond a few watches and TV sets from Samsung.

:) you are right. But at least it shows the toolbox character. Whether something good comes out of it... Let us see :)

I agree that having mono and .NET Core being developed at the same time is not a good thing. How do you pick one over the other? There is way too much overlap.

With .NET core being open source they should find a way to work with the mono team.

> How do you pick up one over the other?

I believe you do not have a choice. iOS, Android, macOS, Linux Desktop goes to Mono. No choice there. Application Servers go to .NET Core. No choice there considering performance and Cloud deployability. Windows Legacy goes to the .NET Framework. No choice there. Modern Windows App goes to UWP (another .NET Core).

I do not see a choice except when you want to run a service on Mono. Which everyone will tell you not to do.

> Which everyone will tell you not to do.

Why?

The performance is dramatically different (see TechEmpower benchmark) and the overall stability seems also a topic (the CoreCLR is pretty battle tested). Mono from it's first origin as GNOME technology till its current peak now in Xamarin somehow always played in the UI field (which has consequences on e.g. garbage collection or jitting).

I think a lot of the Mono Team worked for Xamarin. As Microsoft acquired Xamarin and by that act, opened up most of the Xamarin/Mono codebase that had previously been licensed to ensure a commercial fee could be generated.

Miguel posted the article and he's a Microsoft Employee for sure.

I think the runtimes are slowly converging. The main issue at the moment is that Core is more focused on Web and back-end targets. To replace Mono, it needs to support UI targets such as desktop Windows, Mac and Linux, as well as mobile targets such as Android and iOS. It'll happen. Most of the .Net platforms seem to use the Roslyn compilers these days. Next step is to converge at a library level, then at a VM level I think.

> There is way too much overlap

It is, at least, good to see Microsoft attempting to prevent the opposite problem (fragmentation) by keeping the .NET Standard up-to-date.

https://docs.microsoft.com/en-us/dotnet/standard/net-standar...

DotNet Standard seems, at least in my limited experience so far(<2.0), to be a bit of a clusterfuck. I was trying to write a quick library to do some things, and continually ran into issues where things would compile, and fail with runtime errors upon loading DLLs, or namespaces and types would be mysteriously missing when switching from a lower version of the standard to a higher, ostensibly more complete, version.

Yup. Those days were painful. From 2.0 and on it has been a lot better. .Net 4.6.2 compatible libraries will be loaded by the runtime now, so you don’t have to repackage and redistribute every Library that has not already added a DotNet Core target. I’ve only had one library I’ve tried fail due to relying on an API that had not yet been ported to DotNet Core.

Less than 2.0 is more or less an alpha imo. I use 2.0 in production and love it. But not sure how they’re going to get over all the bad PR 1.0 and 1.1 generated.

That's like over a decade ago right?

I would recommend a bit reading to differentiate .NET Standard (more a spec; currently at version 2.0), .NET Framework (the big fat runtime as part of Windows; currently at 4.7.1) and .NET Core (the slender cross platform one; currently at 2.0.1).

They are very different things and due to the universal misunderstanding and terminology misuse easy to mix up.

I just misread it. The new naming is fubar beyond all belief and it's easy to make mistakes like this.

DotNet Standard 2.0 was just announced in August

https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcin...

Isn't .NET Core a Subset of Mono? I though Mono was like a cross platform version of the .NET Framework, of which .NET Core is also a subset.

No, Core happened before Mono integrated in to the Standard platform. I believe Mono started to use the open sourced components of Core/.Net framework to replace some of their components.That might be where the confusion lies. Then at some point after that, Microsoft acquired Xamarin and opened the Mono/Xamarin platforms fully (the Mono runtime used to have tricky licensing that meant that embedding it required a commercial license.)

.NET Core is incompatible with the .NET Framework which Mono is the oss counterpart to.

That's the official line but I honestly don't know anymore. We were trying to write a few cross platform libraries that we could also consume in Framework. We could not get .NET Standard libraries to import into Framework Apps without entering a dependency hell that made me long for the DLL Hell of the 90s. We discovered that re-targeting .NET Standard projects to .NET Core would allow them to be imported into .NET Framework projects without issue.

Of course you can't import .NET Core libraries into .NET Standard so in the end we actually made projects for each of them with links back to the .NET Standard libraries' files.

I think it depends on what you are trying to achieve. They are all slightly incompatible to some degree. I've written quire a few libs in .Net Standard and had them work on all three platforms, as well as writing Core command line apps and ported them to .Net 4.5. The issue is more with stuff like ASP.Net Core etc, where the libraries are slightly different conceptually.

Reply on news.ycombinator.com