4 ms·

Microsoft reverses controversial .NET change after open source community outcry

49 points by cube2222 5y ago

aae42 5y ago
well done, everyone
alunchbox 5y ago
They've been working so hard on getting their image better, they've probably started to understand how important it is to have a positive conversation about their technology vs their image of the 00's and late 90's.
- eyelidlessness 5y ago
  Now comes the hard part: being responsible for all the sub-organizations that were spun off to compete amongst themselves.
kjaftaedi 5y ago
The additional story attached, (of Microsoft covertly taking control of the .NET foundation) is equally interesting.
pacifika 5y ago
This highlights the problem again of a large corporation being effectively in control of an open source project, instead of a funding member of a steering group.
- sharken 5y ago
  It also highlights the problem when business persons are allowed to make decisions without understanding the market/users.
xg15 5y ago
Not a .NET dev, but hot reload always sounded somewhat sketchy to me. Wouldn't you have a high risk of putting the running process in an effectively undefined state? After all, you end up with a process that runs code from after your change but using heap memory, threads, file handles and other resources from before your change. Even if the process doesn't crash, this puts it in a unique state that will be irrevocably lost when the process is terminated. Usually, the industry moves towards more determinism and reproducibility in build processes. Hot reloading seems to go in the exact opposite direction.
- nonbirithm 5y ago
  I also thought the same way at first, but Hot Reload in .NET is limited to simple actions like changing the body of a non-generic method. Changing anything in a generic class, adding or removing new methods/fields/properties, changing the implemented interfaces of a class, etc. all require a restart. Currently the generic class limitation impacts me severely and I still have to restart the program too often for my own liking, unfortunately. Otherwise it works pretty well.
  - xg15 5y ago
    Makes sense and this definitely lowers the risk. However you could still end up with situations where the new method body assumes different constraints/invariants on field values than the old code, so calling the hotswapped method on existing objects could still lead to unexpected behaviour. Example: A class has a private read-only field int foo that can take any value and a DoStuff() method which uses foo's value. Now the constructor is hotswapped to validate that foo > 5 and DoStuff is hotswapped with an implementation that also assumes foo > 5. This is all good for new objects created after the hotswap - however calling DoStuff on objects created before the swap (which might have foo <= 5) is unsafe.

49 points by cube2222 5y ago

well done, everyone

They've been working so hard on getting their image better, they've probably started to understand how important it is to have a positive conversation about their technology vs their image of the 00's and late 90's.

eyelidlessness 5y ago
Now comes the hard part: being responsible for all the sub-organizations that were spun off to compete amongst themselves.

kjaftaedi 5y ago

The additional story attached, (of Microsoft covertly taking control of the .NET foundation) is equally interesting.

pacifika 5y ago

This highlights the problem again of a large corporation being effectively in control of an open source project, instead of a funding member of a steering group.

sharken 5y ago
It also highlights the problem when business persons are allowed to make decisions without understanding the market/users.

xg15 5y ago

Not a .NET dev, but hot reload always sounded somewhat sketchy to me. Wouldn't you have a high risk of putting the running process in an effectively undefined state? After all, you end up with a process that runs code from after your change but using heap memory, threads, file handles and other resources from before your change. Even if the process doesn't crash, this puts it in a unique state that will be irrevocably lost when the process is terminated. Usually, the industry moves towards more determinism and reproducibility in build processes. Hot reloading seems to go in the exact opposite direction.

nonbirithm 5y ago
I also thought the same way at first, but Hot Reload in .NET is limited to simple actions like changing the body of a non-generic method. Changing anything in a generic class, adding or removing new methods/fields/properties, changing the implemented interfaces of a class, etc. all require a restart. Currently the generic class limitation impacts me severely and I still have to restart the program too often for my own liking, unfortunately. Otherwise it works pretty well.
- xg15 5y ago
  Makes sense and this definitely lowers the risk. However you could still end up with situations where the new method body assumes different constraints/invariants on field values than the old code, so calling the hotswapped method on existing objects could still lead to unexpected behaviour. Example: A class has a private read-only field int foo that can take any value and a DoStuff() method which uses foo's value. Now the constructor is hotswapped to validate that foo > 5 and DoStuff is hotswapped with an implementation that also assumes foo > 5. This is all good for new objects created after the hotswap - however calling DoStuff on objects created before the swap (which might have foo <= 5) is unsafe.