This makes more sense. I dread the 20yr old codebase at work but I still love C#. If not for the amazing tooling there’s no way this codebase could’ve survived this long.

I’ve worked with C# for 15ish years and it’s easily the language I hate working with the most. I understand the love it gets, I really do, but as soon as you step out of its basics and need to do something extra it becomes such a shit show of wasted hours. I still have nightmares from the 1-2 version where you basically had to build your own ASP to do anything reasonably with it, but those days have been gone for at least a decade and it’s not fair to compare with that. Even after 4.5 hit, however, you’d have to extend things to make them work the way you want, and as soon as you did that, some of the magic sometimes break.

I did some extensive AD work with it back before Runbooks and Powershell became the obvious way to do that, and while it was easy to do simple things, setting up something to admin a bunch of school devices meant rewriting a lot of the basic library because Microsoft only ever include the minimum. Which is where things got odd, because you’d expect something like filtering to work the same regardless of which AD attribute you were filtering, right? Well yeah, that’s not how the extra extended attributes work. Maybe Microsoft of the day never imagined you’d need more than the standard extended attributes, but there was just no foundation to get anything of the official AD packages to work with them back then.

In more modern days things are basically the same. We currently have an API that uses OData, and since that’s mainly a Microsoft thing on the server side as most other people went with GraphQL or are still doing special Rest endpoints, we like it on the client side. The server side has been an actual shot show though. Because despite the EntityFramework and OData libraries both being official Microsoft libraries (they even worked together better than they do now at one point) they just won’t play nice. In OData you have a “patch” functionality which basically lets you update changes in objects without doing anything yourself but since the EF and OData model builders don’t work the same way, not even for the exact same annotations, well, it doesn’t work until you rewrite half of it. And the “fun” doesn’t stop there because while .Net has UUIDv4 GUIDs they aren’t actually following the specification for UUIDv4, meaning that any GUID you generate won’t pass any non-Microsoft checks. And to make things even better, if you ever need to extend objects in your JSON in a way that improves on the OData efficiency then they will no longer be forwarded as camelCase JSON but instead as PascalCase for a reason we still have been able to figure out despite working with actual Microsoft developers on the issue…

Like I said. C# is really great for things that GPT can basically generate for you, but I’ve probably wasted at least a year of my life trying to figure out why some part of it wasn’t working the way it was supposed to in some obscure edge case. I’ve worked with a lot of languages and C# is the only one that has this “feature”.

I totally don’t understand rant about integration with AD from C# standpoint. Seems like you meant .NET Framework.

I also don’t see how any other language would do any better in manipulating Active Directory settings.

Same for ASP stuff, that is like a web framework - like for example Ruby on its own does not have anything to do with Rails as RoR is web framework for Ruby so, also really weird rant if we talk about language itself.

> I totally don’t understand rant about integration with AD from C# standpoint. Seems like you meant .NET Framework.

The C# libraries for AD integration weren't very extensive back in the day, but where the "magic" broke was when you extended the extra properties on your AD objects and then none of the AD library functions worked. This despite the fact that AD has extension attributes where it worked, it was only if you extended it.

> I also don’t see how any other language would do any better in manipulating Active Directory settings.

Back then I think it's probably debatable, and you could be right. I can't say because I'm not sure how PowerShell was back then, but I believe it wasn't as included in .NET back then, so maybe. Today I think C# is terrible for AD work. You're going to want all your AD automation and API's to be handled through orchestrated runbooks, and they only support PowerShell and Python. This is sort of by design by Microsoft though so I don't really fault them for not having good C# tooling available for AD anymore.

> Same for ASP stuff, that is like a web framework - like for example Ruby on its own does not have anything to do with Rails as RoR is web framework for Ruby so, also really weird rant if we talk about language itself.

I guess that is a fair point, but throughout my decades in the industry I've never seen anyone use C# for anything without it's frameworks. So while it's true that our problems are mainly with two frameworks, it's not like we would have ever chosen to work with C# if we didn't need it's OData framework.

I think you may be missing the point I'm trying to make though. It's not that C# is terrible, as such. While I certainly think it is a horrible language to work with, I think this because a lot of the "automation magic" the different frameworks do for you break down once you stop doing basic CRUD functionality with them. As long as things work as intended, however, it's a very likeable language and the reason I hate working with it is simply that it wastes too much of my time when it stops working. You're certainly free to write me off as you like, because you're right, all my criticism here is with the frameworks. I think the only thing I really dislike about the language itself is how "var" became the standard way to define things instead of giving them types.

Yes I am quite hard on C# language and .NET framework distinction.

I feel for you it’s more like one package.

I don’t write you off one way or the other.

My main point is that writing off C# as really bad language based on your arguments is at lest uncharitable.

I agree that dev tooling improvement has been a huge theme of the past decade, but the premise that it’s exclusive to new languages is flawed. I’m a a C++ developer and it has fantastic tooling these days: clang-format, the static analyzer, VSCode & VisualStudio, gdb & lldb, conan, godbolt, etc.

Being stuck in an old legacy codebase may be hell, and may not be — that seems independent of language, though. But writing C++ with new standards, libraries, and tools is a joy.

I'm a C++ dev also, and I don't agree with you! I use clangd, gdb, dynamic analysis tools, no static analysis tools (other than compiler warnings). The help I've gotten from Rust analyzer compared to clangd is pretty large, imho. Rust restraining itself means that our tooling gets to be more free.

Also, gdb is... Not that great. Yes, it definitely does debug my app and in that sense it is great. It is however pretty unstable and gets into weird state I cannot get out of, gdb/mi is a mess, and the text interface (TUI) is not performant enough. I'm still very happy that I have it, but when I look at RemedyBG I get jealous. I'd pay for an equivalent to RemedyBG on Linux, if it was FOSS.

It is true that writing modern C++ is much more fun than writing old C++ in the old days. The code also _looks_ better than in the old days, too, but still far from pretty.