4 ms·

I agree. IMHO Microsoft made a rather poor choice earlier by pushing Mono-based Ahead-of-time (AOT) compilation - when they should have thrown their weight behi

by jeswin 6y ago

I agree. IMHO Microsoft made a rather poor choice earlier by pushing Mono-based Ahead-of-time (AOT) compilation - when they should have thrown their weight behind CoreRT (now called native AOT). It looks like it's moving in the right direction now with native AOT [1]. Ability to target native code and WASM (without the baggage you mentioned above) with C# can give Go a run for its money. 1: https://github.com/dotnet/runtimelab/ https://github.com/dotnet/runtimelab/

csharptwdec19 6y ago
I get why they did it to some extent, although I agree with the sentiment they didn't put enough weight behind CoreRT (Honestly I blame their cloud-centric view; the result is ASPNETCORE has been swarmed with developers while CoreRT has a few that also tend to have to work on the main runtime.) BUT, putting Mono out there let everyone else in the community start developing tooling (that Microsoft will take the best ideas from before politely acting like the community didn't keep the whole idea afloat.)
zigzag312 6y ago
+1 Trying to quickly build something based on Mono will probably result in a subpar solution, that they won't be able to really fix later on, because it would break backwards compatibility. End result will be half-fixed solution with some great technology, but with just enough underlying issues that will remain there forever. Classic Microsoft.
kevingadd 6y ago
The strengths or weaknesses of CoreRT aside, it's a simple fact that Mono was ready and CoreRT was not. No number of strategic or tactical decisions will change whether a piece of software is ready to ship. Uno going all-in on CoreRT would have meant they shipped a working product later. For context, the Blazor team started with their own interpreter compiled to WASM (via emscripten) instead of using either Mono or CoreRT - because shipping and getting user feedback is really important, and you can't do that while waiting for the ideal tech to be ready. It was swapped out later. CoreRT is pretty cool tech but I rarely encounter anyone using it. Hopefully that will change in the future. The only CoreRT-based production app I know of is Streets of Rage 4 and it's a very recent release.
- zigzag312 6y ago
  To be fair, CoreRT was an experimental project that was never officially released. So, it's not surprising you rarely encounter anyone using it. Issue is that it seemed like it's development never got allocated a serious amount of resources. I agree that getting early user feedback is really important, but IMO it would be better if a limited version of Blazor WebAssembly (that would support only subset of .NET features, but have usable runtime size) was released on CoreRT tech and then slowly add more features. Blazor WebAssembly at it's current state, even though it supports all features, is too big to be really usable. Spreading development resources thin between old tech like Mono and future tech just means future tech will be delayed even more. And when they figure out that in order to get the size down to a competitive levels, it would be better, if some features were kept out of the WebAssembly runtime (eg dropping reflection and relying on code generation instead), it will be too late, because it'll break compatibility with released Blazor WebAssembly projects.
- pjmlp 6y ago
  I really hope that they actually deliver proper AOT, specially now with the uncertain future for .NET Native. Otherwise many devs will just look into alternatives (D, Go, Java (GraalVM)) even if that means lousing the benefits of the .NET eco-system.
mycall 6y ago
It is planned to merge CoreCLR into .NET 6.0.

by jeswin 6y ago

csharptwdec19 6y ago

I get why they did it to some extent, although I agree with the sentiment they didn't put enough weight behind CoreRT (Honestly I blame their cloud-centric view; the result is ASPNETCORE has been swarmed with developers while CoreRT has a few that also tend to have to work on the main runtime.) BUT, putting Mono out there let everyone else in the community start developing tooling (that Microsoft will take the best ideas from before politely acting like the community didn't keep the whole idea afloat.)

zigzag312 6y ago

+1 Trying to quickly build something based on Mono will probably result in a subpar solution, that they won't be able to really fix later on, because it would break backwards compatibility. End result will be half-fixed solution with some great technology, but with just enough underlying issues that will remain there forever. Classic Microsoft.

kevingadd 6y ago

The strengths or weaknesses of CoreRT aside, it's a simple fact that Mono was ready and CoreRT was not. No number of strategic or tactical decisions will change whether a piece of software is ready to ship. Uno going all-in on CoreRT would have meant they shipped a working product later. For context, the Blazor team started with their own interpreter compiled to WASM (via emscripten) instead of using either Mono or CoreRT - because shipping and getting user feedback is really important, and you can't do that while waiting for the ideal tech to be ready. It was swapped out later. CoreRT is pretty cool tech but I rarely encounter anyone using it. Hopefully that will change in the future. The only CoreRT-based production app I know of is Streets of Rage 4 and it's a very recent release.

zigzag312 6y ago
To be fair, CoreRT was an experimental project that was never officially released. So, it's not surprising you rarely encounter anyone using it. Issue is that it seemed like it's development never got allocated a serious amount of resources. I agree that getting early user feedback is really important, but IMO it would be better if a limited version of Blazor WebAssembly (that would support only subset of .NET features, but have usable runtime size) was released on CoreRT tech and then slowly add more features. Blazor WebAssembly at it's current state, even though it supports all features, is too big to be really usable. Spreading development resources thin between old tech like Mono and future tech just means future tech will be delayed even more. And when they figure out that in order to get the size down to a competitive levels, it would be better, if some features were kept out of the WebAssembly runtime (eg dropping reflection and relying on code generation instead), it will be too late, because it'll break compatibility with released Blazor WebAssembly projects.
pjmlp 6y ago
I really hope that they actually deliver proper AOT, specially now with the uncertain future for .NET Native. Otherwise many devs will just look into alternatives (D, Go, Java (GraalVM)) even if that means lousing the benefits of the .NET eco-system.

mycall 6y ago

It is planned to merge CoreCLR into .NET 6.0.