by mrcsharp on 1/31/25, 11:22 PM with 301 comments
by unsignedint on 2/1/25, 2:18 AM
With .NET, this issue is much less pronounced. While occasional adjustments are necessary, the environment is largely self-contained, minimizing the overhead required to get things running. As long as the .NET SDK is installed, running dotnet restore is usually all it takes—even when moving the codebase to an entirely new machine.
Some third-party libraries evolve more rapidly than others, but the core .NET libraries remain remarkably stable. More often than not, you can transition between major versions without needing to modify any code.
If I were starting a long-term project that required ongoing maintenance, C# would be my top choice. For quick scripting needs, I’d lean toward Python or PowerShell. In fact, PowerShell itself is another reason I appreciate .NET—it shares many concepts, and knowing .NET makes it easier to understand PowerShell. Plus, since PowerShell can directly leverage .NET libraries, it offers powerful scripting capabilities. I was thrilled when PowerShell became cross-platform, much like .NET itself.
by LeFantome on 2/1/25, 4:31 PM
Another benefit that is really stands out once you start using it is that you can write anything in it. It integrates to C well and you can get absolute control over the bits in memory and on disk if you want. You can avoid the garbage collector most entirely where you think you need to. You can also operate at a high level of abstraction. It has, if anything, way too many web and GUI frameworks (even just from Microsoft).
And that last part is the rub…
The downside of C# is that it is both old and rapidly evolving. That means multiple competing frameworks. That means that the complexity of the language keeps increasing. It is not quite C++ (and WAY better designed) but it has the same problem. The number of features and the breadth of syntax is non-trivial. There is also a bit of “magic” that has crept in that allows you to skip boiler-plate with the side-effect of basically have behaviour you cannot see in the code. All this is optional.
If you write everything green field with some coding standards, it is no problem. But if you want to read other people’s code, there is a fair bit of language to learn.
Like English, C# is incredibly useful and can be used anywhere. Like English, it is super easy to pick up and use. Like English, it feels like you can use it your whole life and still not know it all.
by ThinkBeat on 2/1/25, 8:26 AM
If you have a lot of experience in C# 2.0, later code may be quite incomprehensible. (Yes this goes for other versions vs the latest version as well)
Whereas I can pick up a C program today and have a decent understanding of what it is doing.
Then the codebase becomes legacy a lot faster than most other environments. It will compile and keep it, but programmers want to stick new features into the codebase.
F# to the limited extent I have followed it seems more stable in terms of added features. C# has certainly adopted a lot of features from F".
My second big gripe with Net is EF ORM.
If the developers using it are not reasonably aware of how a relational database works, you can get truly horrific code. A dev team at a client I was at, managed to spike the SQL Server instance to damn near 100% for at least 30 mins.
When someone discovered the what and where was causing it.
A pure SQL statement replicating what needed to be done ran in seconds.
by danielodievich on 2/1/25, 4:12 AM
by PeterStuer on 2/1/25, 8:27 AM
I guess everyone likes to be the underdog, but thruth is the B2B space is dominated by the duopoly of Java and .Net and shows no signs of changing.
The author is imho cosplaying as a contrarian while being solidly mainstream.
by noveltyaccount on 2/1/25, 3:00 PM
by sophiacamille on 2/1/25, 2:47 AM
by halfcat on 2/1/25, 1:58 AM
I remember making a big spreadsheet of languages and a bunch of potential areas of use. Building desktop apps, mobile apps, games, concurrency, performance, cloud native, web apps, data pipelines, and machine learning. C# is 3 out of 4 on all of those, except maybe 4/4 on games with Unity, and being cloud native with Azure, C# gives you a bunch of stuff automatically especially around observability.
by ngrilly on 2/1/25, 10:29 AM
- The absence of free-floating functions (everything is an object, and I must use static methods on static classes).
- When “using” a namespace, the convention is to make all the symbols in the “used” namespace available directly in the current namespace. That makes harder to know where symbols are coming from when reading code. And to avoid name collisions, people tend to use longer names. The convention in Go or Rust is to prefix most symbols with the package they are coming from. But perhaps I’m missing something and need to read/write more C#.
- The syntax for doc comments with tags such as <summary> is super verbose. I don’t see the point. Docs are working great without these tags in other languages. Reminds me of my J2EE days.
- I really prefer the name before type syntax (used in all new languages such as Go, TypeScript, Go, Swift, Kotlin, Zig, etc.) to the type before name syntax (used in C#, C, C++, Java, Dart).
by GiorgioG on 2/1/25, 3:47 AM
by EMM_386 on 2/1/25, 2:24 PM
My last greenfield product I was able to choose the stack (except the database, which I was stuck with).
Front-end? Angular, mostly because I felt it fit best with experienced .Net developers.
Back-end API layer? C#, obviosly.
So I've been working with C# for 24 years. No regrets.
by spicyusername on 2/1/25, 2:54 AM
With the exception of maybe Tagged Unions, it has all of the language features I could want, and the syntax is very clean and easy to read.
by idatum on 2/1/25, 5:05 PM
by rednafi on 2/1/25, 8:45 AM
Plus, many, like myself, just don’t want to write OO code, no matter what. I simply don’t want to spend my time working that way. This makes hiring difficult, especially when many young engineers who start their careers with non-OO languages instinctively shy away from Java-esque languages.
That said, I welcome language diversity in the backend and love that new startups no longer default to Node. I’d rather deal with OO than fiddle with a poorly designed language that was never meant for anything but throwaway frontend code.
by brainzap on 2/1/25, 3:46 PM
by skeeter2020 on 2/1/25, 1:29 PM
by begueradj on 2/1/25, 9:57 AM
by account-5 on 2/1/25, 8:43 AM
by MaxGripe on 2/1/25, 11:28 AM
by doorhammer on 2/1/25, 4:05 PM
LINQ + MoreLinq + Extension Methods makes it really easy and fast to make type safe internal DSLs that I wouldn't want anyone I care about to have to use but worked really well for personal power tooling. (you also _can_ definitely write more sane ones, but I didn't have to for personal stuff and it let me burn off the cleverness in my brain before working on code other people might have to work with)
by pjmlp on 2/1/25, 8:49 AM
by knallfrosch on 2/1/25, 11:11 AM
Finding outdated search results from 2012 is probably the biggest impediment for the ecosystem.
Or finding out, from the project XML, whether a project is .net48 and Windows only or .net6 I'd a non-trivial task. Why?
Other than that, I agree with the article. It's a mature ecosystem where the crucial bits have first-party support.
by ansgri on 2/2/25, 9:54 PM
by tester756 on 2/2/25, 1:29 PM
Wow, this language allows me to focus on writing programs (algorithms) instead of fighting with the language!
9 years passed by, now 'veI worked with C, C++ and C# for money and my opinion is still the same.
I've earned way, way more money in C/C++ world, but I was 5x times happier / saner in C# world.
by codr7 on 2/1/25, 2:23 AM
by coder543 on 2/1/25, 2:08 PM
If anyone wants to point me to some good C# opportunities, I’m interested. (Tracebit is looking for a founding engineer, so presumably they want someone who is already an expert at C#, and I doubt they want to sponsor the visa work needed to bring someone to the UK.)
by npodbielski on 2/1/25, 3:49 PM
by neonsunset on 2/1/25, 5:11 AM
by ilitirit on 2/1/25, 12:02 PM
But the reason C# is one of my favourite languages to code in professionally is simply because of how easy it is to setup the environment and just get to work. Admittedly on Windows, but I've learned over the last 5 years it's a pretty simliar experience on Linux too. No messing with environment variables or paths; no header file wrangling; no macro shenanigans; no messing with virtual memory settings etc etc etc.
Yeah, I get it. Choice is nice. But when it comes to my job what's most important is that I can just get to work.
by lordofgibbons on 2/1/25, 2:56 AM
by thdhhghgbhy on 2/1/25, 7:23 PM
by germandiago on 2/1/25, 3:41 PM
by arrty88 on 2/1/25, 4:44 PM
by jchw on 2/1/25, 3:59 AM
My only hangup is that I have had my confidence shaken by Microsoft's occasional showing of hand: with the foundation drama, the debugger nonsense, and with the weird CLI live reload removal, it seems there's still some shades of old Microsoft hanging around. I don't honestly believe they'd pull a complete bait-and-switch, and let's face it, Go is backed almost entirely by Google, a company that is at least as difficult to trust in the long run, but I wish they would, or perhaps could, do something to send a strong signal that they won't meddle with things anymore. What they have done with open sourcing .NET is highly mutually beneficial to Microsoft, and I won't lie that I think it was a greater service to us than them in some regards... but at the risk of sounding greedy here, I need to be able to trust that the people in charge are not going to pull any funny business if I'm going to invest my time, effort and possibly business into an ecosystem.
> There are some - debatable - arguments that static typing reduces bugs. [...] I think the key benefit for me is what it enables in terms of reading and maintaining code. I find that static types help me understand the intent and implementation of half-remembered or unfamiliar code much more quickly.
But, that's a large part of how it helps reduce bugs, in my opinion.
The other part is that static typing can legitimately disallow certain classes of runtime errors, but obviously that doesn't in and of itself guarantee that code is overall less buggy. In practice, though, at least as far as reducing runtime crashes, JS with TypeScript has been night-and-day better than without. Maybe static typing itself is not actually guaranteed to reduce bugs, but in practice any system that can replace bits of "Just Don't Make Mistakes" with diagnostics is going to improve reliability. The only case where I have ever questioned it was MyPy, and that's because I feel the MyPy type system is just not powerful enough to properly cover the vast majority of idiomatic Python (or it requires too much effort.) If MyPy was more sophisticated, though, there's just no doubt in my mind on that one.
All in all though I do think C# is a good choice for a productive environment to write code in. Modern .NET has a good ecosystem of tools, libraries, and frameworks, impressive language design going on in its most popular languages, and it's honestly pretty good in terms of performance and scalability.
While "right tool for the right job" is a little over-indexed on, I do think that Rust occupies a bit of a different space than C#/.NET. Rust remains king for very high performance, minimal overhead, and safe concurrency; it's got very few direct competitors. You certainly could use Rust for anything you could do in C#, but I think C# is ultimately more productive. This is not hate towards Rust, though, as I personally am the type of person that finds the value proposition of Rust very appealing and I certainly plan on investing more into Rust in the future. A better comparison for C# is Go: I think they occupy a surprisingly similar space for all of their differences. And in that realm, C# compares shockingly favorably, especially modern C# on modern .NET.
by sirjaz on 2/1/25, 8:42 PM
by romaniitedomum on 2/1/25, 5:07 AM
For instance, productivity is listed as the top reason, but his team only found C#/dotNET to be the most productive after using it. They didn't know it would be the most productive in advance. So it wasn't a reason for choosing that platform.
Other reasons listed are, 1 Open Source, 2. Cross Platform, 3. Popularity, 4. Memory Safety, 5. Garbage Collection, 6. Stability, 7. Statically-Typed, 8. Batteries Included, 9. Tooling, and 10. Performance. I think there are plenty of languages and platforms that are as good as C#/dotNET in all of these areas, but there's nothing here to suggest any of them were even considered.
by timeoperator on 2/1/25, 8:47 AM
(X) Doubt
by _pdp_ on 2/1/25, 10:22 AM
by yohbho on 2/1/25, 1:28 PM
by whoknowsidont on 2/1/25, 3:09 AM
They should have gone with Rust if they wanted to choose something new. C would have been respectable.
>Some fairly trivial CSS build steps using node have more dependencies than our entire C# product!
I don't know if I would really trust anything else written here. This is a security-focused product. Surely they understand that explicit, external dependencies are in fact safer than internal, implicit or "quiet" dependencies that make it hard to pinpoint attack vectors. It's really trivial to say, set up "canaries" around the former dependencies vs. the latter.
Red team 101.
Also .NET's runtime is _incredibly_ transparent, which is part of the reason why it's "reflection" capabilities are so powerful. And this can often be a great thing for developers, but I don't know about a security product that's supposed to be acting as a defense line. This is why even most obfuscation programs struggle with .NET because ultimately you can't really obfuscate much (pass some elementary things that have been obsolete since 2009 at least).
.NET programs can also "mutate" dramatically with no hope of detection except by outside sources that are constantly checking for the integrity of known programs. And I'm not talking about "compile-after-delivery" vectors either.
For example it's pretty well known in some circles that the CLR's dynamic assembly initialization and reflection capabilities allow you to even bypass AMSI. For _security-focused_ products and minimizing the blast radius on endpoints/systems, .NET (like other similar tech-stacks) really should be a no-go.
>Honestly, we’re not doing real-time/systems/embedded programming; we can afford a GC pause.
God this really hurts to read. You guys are really worried about the wrong thing(s).