Why not statically compile and tree-shake? If this already exists why is it not effective?
[1] https://devblogs.microsoft.com/dotnet/introducing-c-source-g...
JS is also exposed to this. Some libraries can be shaken but I've always ran into random things breaking when trying it.
> We're talking about saving how much disk space anyway?
Surely this is relevant to how the customer values disk space, not the developer.
Tons. Serialization, for one, And plugin systems are commonplace.
> You have zero grounds to dictate the value of resources.
Nonsense and worse words. We know how much disk costs. It is a rounding error for the overwhelming majority of people and the overwhelming majority of apps. Prioritize what matters.
Surely this is doable statically. What is the advantage of doing this at runtime rather than at compile time?
> Nonsense and worse words. We know how much disk costs. It is a rounding error for the overwhelming majority of people and the overwhelming majority of apps. Prioritize what matters.
Got a citation? Disk space is the only variable that people even know to complain about... Not sure what you're drawing this from but it stinks to high heaven of corporate propaganda.
If you're talking about the server side....well I think you'd save a lot more on less vCPU than a little more attached storage.
So let me put it back on you: except maybe IoT, where do you run into problems where your app takes up too much disk space?
EDIT: Maybe it's an update/bandwidth thing? Or a Docker pull time in CI? I'm trying to play devil's advocate here...
What does this have to do with C#? Surely you hold it to a higher standard than electron of all things—C# has been around for 18 years. Electron is just repackaging a browser as an app. Is this the standard to which microsoft holds themselves? Might as well sell scripts for google docs....
I'm not sure where "Disk space is the only variable that people even know to complain about" did come from, but games use 100-150 GBs nowadays, so things like 17 MB are basically irrelevant unless you do verrrrrrrrry specific stuff
If you have a phone with 8G of space like I do, obviously games which require 150G are beyond my means. How does this work towards disk space being irrelevant?
We know how much disk costs, but at any given moment a certain non-negligible share of businesses will be working with very old equipment in some of their branch offices, self-service terminals, factory floors, labs, etc.
I agree that 17 MB will rarely be a show stopper in isolation. But resource consumption is critical if Microsoft wants .NET to be a universal solution for business computing needs. Memory is far more likely to be the bottleneck in my experience.
If a company has modern equipment in 95% of their locations, but the remaining 5% are difficult to upgrade for some reason (cost of disk is unlikely to be that reason), then those 5% will determine which technologies are even taken into consideration.
Asp.net, entity framework, anytime you use an attribute, binding, autogenerating columns based on an object.