Counterpoint: Social media allowed fools to find other fools with incredible efficiency, which amplified stupid ideas in ways that weren't possible before.
Example: QAnon.
Because conspiracy theories and populism are like a sugar hit to people who don't want to think too deeply.
All these changes, yet still no satisfactory UI framework.
Still no migration path from WinForms to something modern.
I love .NET but if you're taking on an older desktop app that is still using VB.NET and WinForms it feels like Microsoft have decided to let you circle the drain with no supported way forward into MAUI or whatever stupid XAML UI they decided is the solution these days.
On a server, .NET is fantastic and it's entirely possible to build and debug your system on Linux with no loss of productivity, but the desktop stuff is bad and getting worse.
I've tried each iteration of UI paradigm they've tried since WinRT and never really had any significant problems with any of them. WinRT, UWP, WinUI, MAUI...
But then they aren't even willing to invest the time to dogfood their own products and fully replace the windows UI. Really doesn't inspire confidence.
I suspect they also made a bad bet by going so hard on blazor without putting more support behind WASM itself. Now that's stalled out with WASM's own failure to reach critical mass.
Microsoft has zero vision in the UI space. It’s crazy that there isn’t there a single, obvious solution for developing Windows applications in 2025.
I agree that it seems they’ve made some bad bets and now are bogged down supporting half a dozen different frameworks with different limitations and tradeoffs.
They keep trying to reinvent the wheel, but it doesn’t seem like they’ve ever really meaningfully improved on WPF.
At least there is Avalonia for an open source, cross platform WPF alternative. It seems like the sanest way of making desktop applications with C# currently.
That would be a first, not having significant problems.
As someone that was deeply invested into WinRT since Windows 8, and went back into distributed systems and Web after all the disappointment regarding how managemetn handled it.
Everyone on the Windows development ecosystem has had enough from the multiple reboots and tool changes, UWP never being as good as WPF, WinUI iterations even worse, the team now went radio silent, the last community call was a disaster,...
Sorry, to be clear I meant no significant problems with the tech.
Sure, it was opinionated tech, but that would’ve been ok if they had stuck with it like C# itself and fleshed it out more, which only would’ve happened had they implemented the entire OS in it. The fact that they couldn’t is in my mind the exact reason the tech failed.
I agree with your point of view, this was the second coming of Longhorn, WinRT was after all pushed by the same folks that killed the Longhorn effort, those on Windows team that sided with Steven Sinofsky, using COM in Vista as future foundation for .NET ideas in Longhorn.
The Hilo tutorial for Windows 7 remarks regarding C++ are quite telling of their point of view, on which programming language one should be using,
"The rich user experience of Windows 7 is best accessed through a powerful, flexible language, and that means C++: by using C++ you can access the raw power of the APIs for Windows 7."
Joe Duffy has some remarks on how even with Midori running Asia Bing infrastructure, and proving workloads in front of the Windows team, the reception to it was rather cold.
Eventually he left MSR and created Pulumin on top of Go.
Meanwhile Apple/NeXT and Google, decided to push languages like Objective-C, Swift, Java, Kotlin, over classical C and C++, proving the point that change is possible if management is willing to support the team, even if that is a very long run.
See Apple's Metal Swift bindings, versus Microsoft's Agility SDK for DirectX.
Assuming the web is not an option for whatever reason.
I did some Win32 interop recently and found it to be refreshing. It's definitely lower level and more difficult, but it will outlive all of these other paths.
Using tools like cswin32 makes this a lot more tolerable development experience from managed code.
My experience with Linux since the 1990s has been that bleeding edge hardware is never a great choice. I've had the best experience with slightly older laptops (typically bought 2nd hand).
It already lead to a reduction in quality of life.
AI has already poisoned the internet with slop, making successfully searching for information much harder.
More personally for hacker news folks, the early promise of AI making programming easier is an illusion. The combination of pressure from management to make AI hype work, vs the actual performance degradation most programmers working on legacy apps experience makes the job harder, not easier.
I've seen this adage floating around for a while now: if it's not worth writing then it's not worth reading. It sums up the current state of AI pretty succinctly for me.
I'll give you a concrete example of how it goes so very wrong.
I worked for a bank for a short period of time, where the development team had gone a bit far with a shotgun approach to moving their systems to Azure. It was pretty hard to find things and as their approach evolved, the older conversions weren't revisited. Most of that team quit. New team is brought in (including me) which had some excellent engineers with years of experience in system architecture, how to make Azure work better. So we tried to homogenise things around a more reasonable approach.
This caused operational problems to worsen (understandably) but it was a short term pain, long term gain thing we couldn't be allowed time to do. So the CIO decided to take all the sysadmin/devops type work and give it exclusively to the system administrators. Who weren't developers. They fixated on one particularly narrow solution for deployment. To make it easier for themselves, but one that didn't really address the bigger picture of how to make it easy to monitor and deploy etc.
Anyway it ended up a disaster. The development team in their newly narrowed roles struggled to make their systems fit in the rigidly defined holes. Operationally it was no better and sometimes worse, but there was absolutely no compromise on how things should work or any consultation with the devs at all, ever.
I no longer work there. If you're going to do devops you have to listen to your experienced engineers, not the snotty kids who think clickops is engineering.
This is a valid story, and I have no doubt it’s real. I’ve heard and seen many stories like this that have happened.
But… I’m going to say the dirty, quiet, and unlikable thing out loud.
That had nothing to do with DevOps or its philosophies, processes, or patterns. That was bad leadership from the top down plain and simple. It’s likely not even the individual engineers faults. It’s leaderships fault for not setting clear objectives, implementing them, ensuring that the engineers had a real plan before beginning, and making sure no individual was too in charge of things.
Leadership in your case was likely career management who knew very little about technical items. Managers who were technical were probably shot down for not playing politics properly, not producing the correct “metrics” and “kpis”. So they moved on.
That’s a company culture issue that has little to do with tech.
I think the comment you are replying to is pointing out the terrible ramifications of just taking a random sysadmin team and expecting them to work in a full blown devops role. I too have seen similar situations play out, and in slight reverse - in their scenario the devops guys were calling all of the shots, ive also seen (and have lived) the opposite where devs call any and every shot on devops stuff and the devops team is treated as little more than glorified IT tech support but for devs (understandable how a business could come to a conclusion about why that makes sense, given how they perceive the sys admin -> devops progression). This sounds like it’s what you may want but it has its own sorts of problems - devs dont always know the right thing or what to ask for or what not to ask for. Really good devops guys are experts at guiding these conversations collaboratively.
I have known and worked with some really great former sys admins gone devops. I am working on mentoring one right now, but I have to be kind of insulting about it and be like “forget everything you knew before it probably won’t help now” which sucks because sys admins do form pretty decent understanding of OS’s, databases, networking, etc. however, when it comes to the code part and more importantly taking all of these concepts and applying them to reasoning about infrastructure code and complex systems is very hard for most people and you have to take a “im a total newb” mentality a lot of people dont seem easily capable of doing.
Valid assessment. The CIO in question did not have a technical background as was far more interested in fostering cliques than good engineering practices. The culture of the place was toxic as a result, it rewarded surveillance and not performance. It promoted fantasy land project managers who ignored reality.
Still, it made me very wary of the idea that devops is separate to development.
Managing relationships with project management and the difficulty that entails with most devops orgs where ive been is a symptom of the same problem I feel is being circled around. Good devops managers manage around these realities really well, can think of some specific examples in my head - it’s very much a several way conversation that should punish silos. however in practice it seems to reward it. If devops worked with and closely with devs you do not need layers of semi competent project managers in between acting like glorified note takers.
I worked in finance on the other side of the pond - developers wanted to constantly bring in and use new services but also didn't want any of the responsibility or the work needed to make compliance happy (or even in that particular company shoulder the costs). When me and other folks where brought in it to fix the "cloud strategy" it was a complete shitshow and heads actually rolled when we wrote a tool to assign costs to applications. But we had to start almost from scratch and limit usable services as we developed strategies and blueprints for each...
The complete, unapologetic desire of devs and security teams (but also many infra teams) to not have any kind of ownership was horrifying to me.
In the end there's not a single solution or strategy, it really goes back to the organization and where your weaknesses and strength are as an org. If you have a gazillion consultants following the "best practice" of the day and exceptions on top of exceptions you are dead, devops or otherwise. You will still make billions if you are the right company though regardless of your software practices, so...
For a brief-ish period, Sun would happily sell you diskless Sun workstations that did everything an XTerminal did plus offered local computing.
Two of the universities in town had labs of them for students, all booted remotely, all the storage on a bigger Sun down in the server room, ugly coaxial ethernet everywhere and those funky blue/silver mouse pads and optical mice.
My boss at the time was pretty dark on Sun, because they sold her a lab full of Sun 3 workstations without telling her the Sparcstations would be released shortly afterwards.
Example: QAnon.
Because conspiracy theories and populism are like a sugar hit to people who don't want to think too deeply.