| I think you're pretty much right. Firstly, I guess we can ask whether Azure is genuinely the Microsoft "stack". Most Azure servers are Linux and the services they provide are mostly web, ML, RDBMS related. I don't think that's what the OP had in mind. If by the Microsoft stack we mean Windows, SQL Server, .NET etc. Then it's definitely looking more and more dead end. In the past few months I've been working with MS tech a little bit again, getting back into a bit of Windows development. It's a mess. I am constantly left astonished by the state of internal decay that evidently exists inside the Windows divisions. Basic subsystems have serious bugs, even after being pushed for years. Their docs are a mess. Their platform is absurdly complicated - look at the schemas for an AppX manifest for an example [1]. UWP and Windows Phone are deprecated/gone yet references to it can be found everywhere. The recommended way to write Windows apps is still C++. The most exciting things they're doing with Windows are upgrading the command line support to match what Linux was doing 20 years ago. dotNET is some kind of mess with many forked versions, a language that's behind Kotlin and a runtime that's behind the JVM. And the problems just continue. One thing that becomes clear when you look around is that very few people are really writing Windows apps at all nowadays. They exist, but they're mostly older codebases. Their attempts to move beyond Win32 have mostly tanked for this reason - the people who would once have been writing against the new APIs switched to cross platform tech. So in this regard I feel it's a dead end stack, yeah. [1] https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uap... |
Where I'd disagree strongly is dotNET being a mess of forked versions, the language being behind Kotlin, and the runtime behind the JVM.
The DotNet versioning annoys me, but it is actually straightforward. The Windows-only framework stopped at v4, then cross-platform Core began at v1 and now we've reached the point where Core v6 is just DotNet v6 because there is no non-core alternative at this versioning point. If you set aside naming/numbering confusion, you have a forward-moving framework up to v4 being overtaken by a rewritten cross-platform framework catching up then replacing it. There were some mishaps on the way, but this is not a mess of forked versions it is actually a pretty fast deprecation and replacement of a huge system with a massive high quality effort.
As for the main DotNet language, C#, it is generally not considered to be behind any other language out there. Perhaps in some areas different approaches have been taken when it comes to syntax, structure, tooling, but it is a very well designed language that is professionally respected, advanced, and innovative.
As for the runtime, it really isn't behind the JVM. It is supported on fewer platforms, but those it is supported on are very well catered for. Including not needing a (shared) runtime at all as builds can produce single binaries too, as per Java.
So no, the problems don't continue.
I do wonder if your recent experience of it may well be true, but is influenced by it being Windows development. Outside of internal enterprise tools, the main work is on the web/network (not Windows) and that's where it excels.