alt Hacker NewsI think a lot of people are sleeping on the advantages of "batteries included" ecosystems.
The need to select an appropriate 3rd party library represents an entire dimension of the search space that can be eliminated. Imagine having to make this choice multiple times per day when your competition is just mindlessly using System.* types. The fact that the .NET ecosystem is curated by one entity should not be underestimated.
Even when we do need to import 3rd party nugets, the models seem to follow this highly structured pattern. They scan the xml docs, and failing that they will build a throwaway console app to reflect over all the unique types and build a report. The fact that we can easily do this with a simple powershell command makes a big difference. How many other ecosystems can even consider doing this? Reflection is a superpower, not something to be avoided.
Replies
And those batteries will soon include the very benchmark in this article. There'll be no need to build a zstd decoder, .NET will ship one in dotnet 11: https://learn.microsoft.com/en-us/dotnet/api/system.io.compr...
Another slept-on feature is the ability to quickly write your own static analyzers, which along with the myriad of existing analyzers out there, provide excellent guard-rails to prevent slop.
Reflection is good for prototyping and get something setup quickly, but if you build your architecture around it, not only do you lose access to NativeAOT, the code becomes very hard to debug, and if you code with LLM a lot, you either have to spend time trying to debug reflections or just rewrite it with source generation to begin with, which is at least honest about the metaprogramming there.
Reflection is just such a dangerous feature that looks like ordinary code, which is why it is something to be avoided, and having an LLM write/analyze the code for eliminates the need to use a lot of reflective code to begin with.