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...
It may seem decent until you look closer. Just like with a junior dev, you should always review the code very carefully, you can absolutely not trust it. It's not bad at trivial stuff, but fails almost always if things get more complex and unlike a junior dev, it does not tell you, when things get too complex for it.
How do optional inheritance and namespaces (which you can ignore to use a single global namespace) make a language inflexible? If anything, these traits make your language more powerful, not less.
The Result pattern also works exceptionally well with C#, provided you ensure that code returning a Result object never throws an exception. Of course, there are still some exceptional things that can throw, but this is essentially the same situation as dealing with Rust panics.
IMO, Rust panics should kill the application... C# errors shouldn't. Also, in practice, in C# where I was dealing with Result, there was just as much chance of seeing an actual thrown error, so you always had to deal with both an explicit error result AND thrown errors in practice... it was worse than just error patterns with type specific catch blocks.
I think you just had experienced a bad codebase. If you opt for using Result then you can not throw at the same time. If you follow this rule, then it works perfectly.
I really do wish them luck! C# is a really nice language and I can't wait to see what they do once they introduce sum types. I've been doing Advent of Code in F# and it's been pretty nice.
For new .NET SDK style projects you hardly ever need to customize the defaults and I know it's used for more stuff than .NET, but I just wanted to give an example where it actually doesn't suck. Also, you may not need to do everything in MSBuild, for some more complex stuff, you can use something like Cake (https://cakebuild.net/) in .NET for example and skip the programming in XML.
.NET made into my toolbox before it was announced to the world, thanks to be working at a MSFT partner that was selected to be part of the Portuguese launch event for .NET with ready made products.
Never seen any big corp using alternative .NET build tools, rather wrestling MSBuild, or before it came to be, nmake.
Microsoft isn't going to abandon C#, it's just using the right tool for the right job. While there are certainly cases where it is justified to go lower level and closer to the metal, writing everything in Rust would be just as dumb as writing everything in C# or god forbid, JS.
reply