3 ms·
Indeed. C# is statically typed. Python is not. Which is the one with a notorious backwards-incompatibility story?
by anonymars 11mo ago
Indeed. C# is statically typed. Python is not. Which is the one with a notorious backwards-incompatibility story?
- shakna 11mo agoBoth. https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/breaking-changes/compiler%20breaking%20changes%20-%20dotnet%2010 https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/br...
- mrsmrtss 11mo agoCome on, those are very rare and minor things that are very easy to fix.
- shakna 11mo agoPort me something from DotNet 9.0 and say that again. https://learn.microsoft.com/en-us/dotnet/core/compatibility/10.0 https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
- mrsmrtss 11mo agoWe have already ported many projects from .NET8 and .NET9 to .NET10 with close to zero issues.
- shakna 11mo agoGuessing you never used OpenAPI or Razor then. Which were core features in 9 and no longer existed in 10.
- mrsmrtss 11mo agoWhat are you talking about?? OpenAPI and Razor are both still present in .NET10.
- anonymars 11mo agoYeah, I'm confused at these examples, along with the implicit idea that the existence of breaking changes means C# had equivalent compatibility challenges to, say, python3. .NET Framework -> Core was more persuasive, but I stand by the overall point that compatibility is more about project philosophy than "static vs dynamic typing" and indeed I think Framework/Core illustrates just that: Framework more heavily favored preserving compatibility compared to Core edit: I assume this was a superficial grasp onto "Deprecation of WithOpenApi extension method" ("WithOpenApi duplicated functionality now provided by the built-in OpenAPI document generation pipeline") and "Razor runtime compilation is obsolete" ("Razor runtime compilation has been replaced by Hot Reload, which has been the recommended approach for a few years now.")
- shakna 11mo agoOf course, its an entirely trivial process to completely replace serialisation everywhere in your product and swap out your own custom hot reloading compilation pipeline you created before the language created its own one incompatible with your API...
- anonymars 11mo agoWhich breaking changes required you to completely replace serialisation everywhere in your product? I guess it's true that a dynamic language wouldn't have lent itself to creating a custom hot reloading compilation pipeline so, yeah, checkmate I guess
- Macha 11mo agoThe .NET framework to .Net Core migration broke a bunch. Similarly java 6 to 8, and when they introduced the new module system in Java 11 broke a bunch in another case. You’d still need to fixed that they swapped the string types, renamed a bunch of core APIs etc. in a statically typed python
- anonymars 11mo agoThose are good examples. But python is dynamically typed -- indeed, python 3 is what I was alluding to That being said, I think backwards compatibility comes down to project philosophy and foresight (e.g. https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/ https://learn.microsoft.com/en-us/dotnet/standard/design-gui...), not static versus dynamic typing