11–20 of 256 posts
Making JIT 4% (or whatever) faster is cool but it would probably have higher ROI for the .NET ecosystem if Microsoft assigned some of these high caliber people to instead work on improving or simply rewriting some of the atrocious open source libraries that are available. Would you rather have an A language/runtime with a D open source ecosystem or a B for both?
Where should someone start if they wanted to get familiar and proficient with .NET?
Where should someone start if they wanted to get familiar and proficient with .NET?
This YouTube channel is pretty good.
Making JIT 4% (or whatever) faster is cool but it would probably have higher ROI for the .NET ecosystem if Microsoft assigned some of these high caliber people to instead work on improving or simply rewriting some of the atrocious open source libraries that are available. Would you rather have an A language/runtime with a D open source ecosystem or a B for both?
They wrote a gRPC library [1],and a high performance JSON library [2]. Granted, these are .NET libraries, but still.
[1] https://github.com/grpc/grpc-dotnet [2] https://docs.microsoft.com/en-us/dotnet/standard/serializati...
Impressive work (and blog post)! Somebody noticing real world performance impact after upgrading to latest .NET Core versions?
[1] https://devblogs.microsoft.com/dotnet/azure-active-directory... [2] https://devblogs.microsoft.com/dotnet/bing-com-runs-on-net-c... [3] https://devblogs.microsoft.com/dotnet/migration-of-bings-wor...
Making JIT 4% (or whatever) faster is cool but it would probably have higher ROI for the .NET ecosystem if Microsoft assigned some of these high caliber people to instead work on improving or simply rewriting some of the atrocious open source libraries that are available. Would you rather have an A language/runtime with a D open source ecosystem or a B for both?
My sense is that things are improving though.
Where should someone start if they wanted to get familiar and proficient with .NET?
Earlier quoted context omitted.
Becomes again, Native AOT is the only way on WinRT since Windows 8, but has been stuck in C# 7 and .NET Standard 2.0, which contributes even more for the little love UWP still has.
Not just stuck - it was buggy and poorly maintained. We were forced to switch to Desktop Bridge after dealing with all the UWP performance and productivity crap and constraints just to have .NET Native one day stop compiling things right and leaving us stuck.
Making JIT 4% (or whatever) faster is cool but it would probably have higher ROI for the .NET ecosystem if Microsoft assigned some of these high caliber people to instead work on improving or simply rewriting some of the atrocious open source libraries that are available. Would you rather have an A language/runtime with a D open source ecosystem or a B for both?
I think that you're making a good point, and at the same time I think that tasking MS Devs with rewriting parts of their ecosystem is a bit of a minefield for any company, but especially Microsoft. Long-term they need people to make good contributions to the ecosystem and I imagine it would be hard for third parties to sustain interest if it was a known risk that MS would rewrite whatever they were contributing. I th…