4 ms·
Hardly. They are achieving this by bringing Mono more "in-the-fold", making it interchangeable with CoreCLR, and ensuring CoreFX runs on every runtime. It see
by pknopf 7y ago
Hardly.
They are achieving this by bringing Mono more "in-the-fold", making it interchangeable with CoreCLR, and ensuring CoreFX runs on every runtime.
It seems that are leaning on Mono because of it's AOT abilities, which doesn't say good things about the future for CoreRT.
I like the idea of using Mono though, it's easier to embed in native applications.
- WorldMaker 7y agoThe article mentions that while MonoVM's (LLVM-based) AOT efforts are ahead, CoreRT has outpaced MonoVM in JIT performance, so CoreRT will still be the default in everything but iOS and Blazor which are the only two 100% AOT platforms.
- pknopf 7y agoIf you aren't doing AOT, why use CoreRT over CoreCLR?
- WorldMaker 7y agoSorry, I meant CoreCLR there where I wrote CoreRT. Got the acronym confused briefly.
- kevingadd 7y agoI think making Mono and the existing .NET Core runtime 'runtime options' simplifies the confusion a lot. Unifying the standard library was already a good idea, and had been partially done anyway. The existing Mono version of the stdlib was a good effort that historically hasn't stacked up when you try to port stuff (and incrementally had been replaced with chunks of the 'you can look at it i guess and it's sort of like desktop netframework' reference sources). I'm personally happy to see more of the .NET Core stuff end up in Mono since it usually is battle tested and has better compatibility, and I'm also happy to see more stuff approximating the existing .NET Framework and Mono workflows since .NET Core has historically been unable to do important things that netframework and mono can do. bias disclosure: I work on Mono