Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: