Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Port me something from DotNet 9.0 and say that again.

https://learn.microsoft.com/en-us/dotnet/core/compatibility/...





We have already ported many projects from .NET8 and .NET9 to .NET10 with close to zero issues.

Guessing you never used OpenAPI or Razor then. Which were core features in 9 and no longer existed in 10.

What are you talking about?? OpenAPI and Razor are both still present in .NET10.

Yeah, 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.")


Of 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...

Which 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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: