One thing I appreciate about C# and .NET is how well they resist codebase rot. In some other languages, I often encounter situations where the development environment needs to be completely recreated—sometimes due to an updated interpreter version or other breaking changes. If you've been away from the codebase for a while, chances are you'll need to make modifications just to get it running in a more recent environment.
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.
This is going to sound really unfair, but compared to some of the more hip languages, the .NET/JVM ecosystems feel a bit more like they have adults at the helm who at least try to maintain backward compat. They’re also stodgy as hell sometimes, but I’ll take that. There’s a real difference in culture that manifests in both what is made and what is held up as good engineering. And that has an effect of raising the bar on what is acceptable from an ecosystem POV.
Yes, it’s possible you’ll have to deal with Enterprise-y code sometimes. But, it’s usually your team’s choice as to what is written. Also, people don’t seem to complain quite as much about it when they encounter it at a FAANG elsewhere that tries to do “good” engineering, but that’s another discussion. :)
Compared to JS, Go, Java, etc. I feel like C# evolves significantly faster and the team is faster to validate, implement, and deliver improvements to the language.
I think this is also why some folks who tried C# say 5-6 years ago have no idea how fast the language has evolved for the better.
That's not unfair at all, I think it's a fair assessment. Industrial tools should have adults at the helm. People who care about longevity and robustness foremost. About delivering quality and stability where the main value points of a language are.
Yes, they place a strong emphasis on backward compatibility, particularly with language features. This allows new C# language features to be gradually introduced into a codebase without disruption, which is especially valuable in enterprise environments. It may feel stodgy, as you say, but they continue to add interesting features with each C# release, striking a good balance between stability and innovation.
Upgrades between modern .NET (Core) versions are simple and painless. It’s just a single-character change in the .csproj file, plus maybe upgrading some dependencies (but old versions will usually work).
Upgrading from the classic .NET Framework to the modern .NET is usually a long process. Simple console apps, desktop apps, and libraries might be doable with an automated csproj upgrade. But Web apps require a rewrite from scratch, because the old ASP.NET is incompatible with the modern ASP.NET Core.
This hasn't been the case for me at all, the jumps between lts releases have burnt a lot of my time figuring out how to fix broken things. Though c# is definitely my favourite language to work in :)
What I really like is the fact that you can basically build anything in this language. From command line tools over Apps or small GUIs up to full fledged Server Backends or Webservices, even WASM... everything is possible.
The NativeAOT approach is also very interesting making it possible to build native binaries similar in size and performance to languages like Rust and Go (not quite actually, but close).
It's also possible to build "single binary" tools by using <PublishSingleFile> which comes in handy when building small helper tools for the command line.
Yup! I recently took a pretty substantial project I wrote in 2006 in Java that was sitting in a tar file, unpacked it, and it ran just fine with a current JVM. Even better, I was able to compile it again with no problems: again, with a modern JDK. I wish I could say the same for years of projects written in Rust and Haskell: the Haskell ones are almost all bit rotten since I haven’t kept them up to date with GHC, and Rust is similar. Those two are even worse since with Java I had a rich standard library, so I didn’t have any 3rd party dependencies in my 19 year old project. The Haskell and Rust ones rely on Hackage and crates, and keeping things working for that long would require me to do bonus work beyond my actual project code. I’ve had similar but less painful problems in Python land: the library APIs are mostly stable: the biggest headache there are projects that predate python3 so there’s some work to bring them up to date. That’s at least a one time investment.
Java: no bonus work induced by third parties to keep projects alive, keeps working for a long time. Would recommend.
this is definitly not true anymore, when the java libs used jaxb/xml/javaee stuff. most often because of java 9. its possible to make them running but its definitly not without issues.
I did run so many 10 years old java binaries it was NEVER without issues.
From what I gather, the only time this occurred was very early in the C#/.NET ecosystem (.NET2) when generics were added in November 2005. So it should be at 20 years this year.
Both languages are very impressive and benefit from the competition.
The number of times I’ve had to install an older version of Java just to compile some code is not even remotely funny to me. I really hate this idea that you can have code that just won’t compile if you are using a modern environment.
This is because Windows comes with some form of .NET, but also other programs end up needing to install multiple versions of the .NET runtime. Eventually, you just have them on your machine. It's the equivalent to installing every version of Python and just letting the problem sort itself out.
It's not different than other tech-stacks, you're just eating the costs up front instead of running into them in a more obvious manner.
.NET (in its entirety) has lots of breaking changes that won't work from one version to another. More recently MS has been better about documenting these, especially as .NET's footprint increases inside outside of the control of MS (non-Windows environments): https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
>In fact, PowerShell itself is another reason I appreciate .NET it shares many concepts
PowerShell is built on .NET (in whatever form .NET Framework and .NET/core) lol. It doesn't "share" anything, it _IS_ shell for .NET.
I was excited about PowerShell at first but after doing a mid size project it, I don't like it anymore. It's such an odd language with too many quirks once you get serious. I think they would have been better off using C# syntax.
A few years ago an option to make self-contained builds was introduced, meaning you don't need any .NET runtime on your machine to run the self-contained app.
Yes, but in the case of Python, I feel it's a bit more nuanced. Simply having Python installed isn't enough—you also have to manage virtual environments (venv, Poetry, or whatever is popular at the moment). Personally, I find this to be more of an ongoing maintenance burden.
I do acknowledge that .NET has its share of breaking changes from time to time, but in my experience, the friction is significantly lower compared to other environments I’ve worked with.
> PowerShell is built on .NET (in whatever form .NET Framework and .NET/core) lol. It doesn't "share" anything, it _IS_ shell for .NET.
I never said it wasn’t! I was simply speaking from the perspective of the frontend experience. While PowerShell is built on .NET, my point was about how its functionality and design make it feel familiar to those already accustomed to .NET development.
> One thing I appreciate about C# and .NET is how well they resist codebase rot.
During the time I was working with .net from 2005-2020, I saw the transition from Webforms to ASP.NET MVC to the MVC/WebAPI split. I also saw the transition from Linq2SQL to Entity Framework.
There was also the weird time when you could run ASP.Net Core and EF Core on top of .Net Framework.
Then the entire .Net Framework to .Net Core was a major upheaval.
C# is one of my favourite languages and .NET is an awesome stack top to bottom. The interoperability between F# (a fantastic functional) language and C# is a real bonus that was just touched on in this article. Writing a compiler for .NET is easy and fun as you can target CIL (Common Intermediate Language) either as binary or text (.NET assembly basically). Something that builds in .NET today will probably run 20 years from now but faster.
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.
One of the problems with C# is the constant expansion of the language.
Microsoft wants it to be everything for everybody, instead of sharpening
it in one direction.
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.
> If you have a lot of experience in C# 2.0, later code may be quite incomprehensible.
I did a lot of programming in .Net 1.1 and quit just after 2.0 was released. I've then spent all my time in other programming languages. Past year at work we've been starting our transition to .Net. I must say I found exactly the opposite.
All the things I knew I could still do, and I found the new stuff quite readable. Sure I had to do a couple of searches to read up on some of the changes, but overall I've been productive in .Net 8.0 from the moment we started. I have had no issue reading library code, as one does to figure out what's really going on.
Also, Visual Studio guided me to rewrite my outdated code in better form, which also helped to understand the changes.
This is entirely unlike C++ which I also used a lot before and quit just shy of C++11 getting released. These days when I read some modern C++ code I frequently have absolutely no idea of what's going on.
As for EF I don't know, as the database we still have to support doesn't support it so haven't had a chance to use it yet. If we do, we will be writing our own SELECT statements for anything beyond a trivial primary key lookup though.
C# 2.0 was twenty years ago - in 20 years any language that is actively maintained is going change, especially as people adopt new syntactic sugar to write more concise code. However the .net team rarely ever breaks backwards compat with new features, and the only thing in recent memory was them adding a new keyword for implicit backing property fields (and I also felt their solve was elegant).
I think because the toolchain is unified, people tend to adopt newer C# features faster than other languages. You aren’t waiting on your permutation of msvc/clang/gcc to update, so when a new version releases, people update and start using new stuff. That said you can also write C# still like it’s 2005, but you’d be wasting time.
C# (to steal Jon Skeet’s language) has developed in the direction of removing “ceremony” in writing code. What in C# 2 would have taken like 20 lines to create a class in a CLI program and print a value can now be done in like 2 lines without sacrificing readability, and if anything is easier to read because you’re only looking at load-bearing statements instead of lots of flaff to scaffold simple behavior.
I 100% agree with the first point, but the second one isn't C#/.NET related at all.
ORMs pose the same problem regardless of the language/framework or implementation. I've seen the same issues with Java's hibernate, too, no difference there.
Except that EF Core is way more modern, thin and with sane defaults (more like Dapper.NET Micro ORM) than traditional EF - which is a fat, untamable beast just as Hibernate (and NHibernate was). Plus, no one forces you to use ORMs. Just use plain SQL as with any other language if that suits your needs.
.NET 's initial appeal was that it felt like Java before the architecture astronauts and the bloat with a saner GUI approach to boot. These days they not only caught up but are trying to surpass in those areas.
It seems to be the doomcycle of life in development stacks. Fresh system cuts through the accumulated cruft of the old, only to gather more and more niche cruft until it collapses on a beach of arcanary while the next wave of simplicity rises behind it.
Java has been doing great recently and I feel there is a bit of a renaissance going on. There is a very mature leadership at the helm and it shows.
With .NET, it seems that they've added features too quickly without giving it enough thought up front. If you are a small team or working on a short lived project, this might not matter. But for long lived projects by large teams, I'd rather take the more conservative approach.
C# is one of my favorite languages and I generally think the features they add are high quality and provide a lot of real value, but I also agree that the flip side of that coin is a pretty large language. I think you have to be pretty good at establishing and maintaining style standards that are a bit picky about which features you're going to use, which is a non-trivial thing to do socially in a lot of orgs.
Obviously in a greenfield startup like the article (I'm assuming) it's maybe a bit less of an issue--at least to start? Definitely a challenge, though, especially compared to something like Go or C.
Imo ORMs are useful as a way of making common actions easy and quick but that thinking they shield you from knowing what they're doing and how SQL works can quickly cause a ton of problems.
There are a lot of EF queries that don't even need to into raw SQL to radically improve (though 100% that's the case often enough). Some `n+1`'s and `ToList`'ing million record queries into memory when you need the top 5 being examples that come to mind.
But you can still write C# 1.0 compatible code and it will run ok. Just don't look at the new features. They added quite a bit of low-level performance related features recently, like span, ref, template math, readonly struct, vectors etc, which are quite useful for the performance minded, but can be safely ignored by the CRUD crowd.
Agreed. Early on before .Net Core the language features were stable. The update to the 3.5 Framework around 2007 was a big deal at the time. Now it seems that new language features are cranked out at a much greater frequency with .Net Core. That said, C# when combined with the JetBrains Rider IDE offers the best developer experience over any other language/IDE combination I’ve worked with.
You can set an old language version for a modern C# project. The compiler will behave exactly like 10 years ago, but it outputs a modern assembly.
If you think this is the way to go in your organization, just do that.
But I seriously don't get why it's so impossible to just read the changelog every year. Takes literally 2 hours per year. Most of the changes are quite self-explaining anyway.
Honestly, I think the appeal to ancient simplicity is a bad take.
Spend the trivial bit of time it takes to learn modern C# syntax and you'll be able read any C# fine. You'll get to use modern tooling built on a language designed along with the tools, as long as you embrace it.
On the other hand, you can spend the time it takes to learn the idiosyncrasies of every different C codebase you encounter and how they handle all the little problems differently for trivial things that would be well documented and baked into C#.
> One of the problems with C# is the constant expansion of the language.
And to make matters worse, it seems there's no resource that fully explains all of its relevant aspects, like the Rust book does for Rust for example.
There are tutorials intended for people who can't program at all, there are dry reference documents, there are resources explaining specific features, but nothing that a reasonably competent non-C# programmer could read start-to-finish to fully grasp the language.
There's the Microsoft Docs site, but it seems to contain the same or very similar information scattered through different sections.
I've put several developers at work through reading this and they've gotten up to speed in the language very quickly. It's comprehensive and, at least according to what I think is important having been doing C# for 20 years, very well organized.
How can you not consider venerable Jon Skeets "C# in Depth". The fourth edition is from 2019, so not that many latest features will be in there. But the fundamentals of the language, runtime etc. are still the same.
How would you compare that to the languages the author mentioned as alternatives, JavaScript and Python? Is 2007 style JavaScript and Python codebases not legacy today? What about their frameworks from that era?
This so much. We have 7 repos and like 5 different coding styles/structures. Each developer writes C# different and uses different libraries, which creates a big maintainance overhead.
For individual developers this may be great: "I learn new things" "I found a faster way" "this abstraction allows me to do X"
But for a company with more than X developers this becomes a risk.
All you have to do is setup a single StyleCop config and enforce it across all projects, which would be the same if you used Prettier, go fmt or anything else. I don't get the 'different libraries' part, it can be literally a case in every single language. Let people use what does the job or force them to teach what you want them to use. It sounds more like your technical management issue rather than language/ecosystem problem. Since I started working with Node/TS I miss how similar and easy to read every C# codebase was.
A comment like this comes up in every thread on C#. And I get it, you want to come to your job and go home at the end of the day and not think about programming again. But I don't know what to say to that mentality because I've never felt it myself. The exact opposite is why I've stayed away from languages like C and C++ where things evolve at a glacier's pace (though I will admit C++ has gotten relatively better in recent years, though it still has a very long way to go on the tooling front).
Maybe you just need to git gud? IDK. I appreciate the new features in C#, every time. They solve real problems I've had.
EF is a different issue. You don't have to use EF. You can use ADO.NET still if you want. It still works completely fine. NHibernate is still a going concern. I appreciate EF because I have been able to use it to treat databases more like libraries than remote services. Being able to do that makes it so I can iterate in development much more rapidly. I do miss writing a tight SQL query, but honestly, it's not necessary for 99% of cases and the other 1% has an escape hatch that isn't hard to use. So... again, I guess just git gud?
I don't know what else to say. If you don't bother to learn the language or libraries you're using, you're going to have a bad time, regardless of which.
I went skiing at Big Sky with bunch of Microsofties as part of Microsoft ski club back in 1999. One of them was a pretty big guy who on the first day of skiing took a bad tumble and threw out his knee. He had to stay at the chalet for most of the rest of the trip, missing out on some glorious snow. I remember asking him what he did while recuperating and he showed me what became .NET. He said it was going to be awesome and transformational, with many other nice adjectives. I didn't really get that from his demo, it was pretty rough, but yeah, he was right. I've been Csharping almost every workday since it came out as 1.0 and its an excellent framework, especially these days where it runs everywhere.
"Tracebit is a B2B SaaS Security Product. If you did a straw poll of Engineers - especially readers of a certain orange website - about the ‘best’ language for such a system, I think the common responses would include Python, TypeScript, Golang, Rust, something JVM-y, maybe Elixir"
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.
I think C# has the highest ratio of (happy) programmers to internet discussions, at least among mainstream languages. This makes it look a lot less popular and cool for people outside the ecosystem.
I think that it's also much more common with companies that aren't primarily tech-focused, as those companies usually have cosy relationships with Microsoft. Pure tech companies, startups and FAANGs don't seem to use it much.
This also ties into geography. In the US, far more people work for startups, FAANGs and pure tech companies than in Europe, where traditional businesses and "software houses" are far more prevalent, which means there's far more C# there.
Which is a shame, because C# is usually better at the problems many startups try to make Go work at. It is a significantly stronger offering if you treat it as a middle ground between C++ and Rust family and Go/Java family.
It is the cool and modern language in today's landscape. But it is popular among the companies which use it the opposite way. Now, we shouldn't complain too much. Because this is what made .NET survive in the first place. But I wish more people looked at projects like Garnet, Ryujinx, various greenfield HPC and highload libraries in the ecosystem over yet another CRUD template. Business domain modeling is much better done in F# anyway!
The author is most likely too young to have experienced this trend and has now rediscovered the joy of stability. Choosing Java, C#, or even Go offers a huge advantage in terms of stability, which takes years of experience to truly appreciate.
I’m loving the fact that the industry is getting tired of Node in the backend and the tech debt it incurs after a few years. Rediscovering old values and getting excited about them is perfectly okay. Nobody remembers all of history—reinvention is part of the process.
As the author points out, Batteries Included is a big reason I choose C# over and over again. Every time I have to go to NPM or Crates.io and look over five or more packages to solve some seemingly basic problem I get exhausted and frustrated that I'm not actually solving the problem I need to. C# has so much built in, and while there are third party options, the Microsoft way is almost always good enough.
FYI, You are comparing the modern version of DotNet (the first link) with the old legacy version (the second link).
The modern version of DotNet, "Net Core" is effectively a reboot of DotNet, with a very cross platform focus and redesigned API's based on decades of experience.
These limitations come from cryptographic implementations provided by specific platforms, not from .NET. Can you list specific algorithms you need that are not supported?
The second article uses the wrong link too (it's for Framework, not for .NET).
I share the sentiment. I haven’t used it in a while (at work use different languages and in the last few years my personal coding is only Python script/Jupyter notebook bite-sized), but anytime I hop into it, it immediately "clicks" and gives a comfortable feeling, despite changing over years.
A perfect language for medium sized relatively clean and mature personal or small team projects.
Frictionless, pleasant, not thinking too much how to express things (and still managing to write them reasonably idiomatic), tends to support clean encapsulated code, quite rich environment/libraries, great tools (debuggers, profilers), safe, relatively fast, not many foot guns, zero build setup, on small project zero build times, trivial to create good functional simple UI, can get fancy dynamic with reflection when I need "magic".
Basically not many pain points that would make me rage quit and almost everything I'd want is simple to achieve.
Each new C# release seems to borrow yet another F# feature, to its benefit. I prefer F# too, but at least I can convince the team to use C# - F# seems to be a bit too intimidating (in its awesomeness, I assume) for most devs to learn.
Same. I think it’s because it’s easy to read and write, and its worst design warts are at least not ridiculous like they are in say JS or Go, where there are massive cons to weigh against the pros. C# just feels like it’s pretty decent across the board instead.
C# is solid. It’s not necessarily the best at anything (is it?), but its floor is like a 3 out of 4 across the board.
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.
I am a huge C# advocate, and with the AOT stuff since .NET 7, they are really working overtime to add features for safe low-level operations.
Some of the niceties over the last several versions include immutable record types, stack allocated structs (ref structs), lambdas (and a host of enhancements thereof since), async/await (of course), generic math ops, platform intrinsics, pattern matching, AOT, nullable types, robust generics, reflection, dynamic types, etc. The big thing I expect next is algebraic data types.
The language has really grown by leaps and bounds, but it doesn't ever feel overwhelming, and it has really kept its verbosity to a minimum without turning into a soup of hieroglyphics.
That being said, I have found the Android/iOS solutions to be underwhelming. I understand the iOS side a bit, but I thought Android would be better. That's not to say you can't make great applications using C# on these platforms, just that it requires more effort.
I'm also not a huge fan of ASP.Net. I've never really cared for it, and I think that stems from a project I had early in my career duct-taping together another developer's classic ASP applicat^HHH monstrosity and mucking about with IIS and FoxPro (!!). I know it's not classic ASP, but once bitten, lol. I will say that it is modern and performant, but very rigid. I'd defer to others' opinions here because I have mostly avoided it.
But in general, the tooling is great, and I don't encounter much that ties you to a Windows box anymore. I know there are some differences in platform support, but most of the rough edges were handled in the early days of .NET Core 2 & 3. Now that we're way past that (the "traditional" .NET merged with .NET Core in a combined version 5 release). Now that it's on version 9, the language features and low-level hits keep coming. I can, today, write code that is 99% of what you can get from C++ (and in some edge cases can exceed it), compiled to native code, that will run on Windows & Linux (x64 & arm64), BSD & MacOS without too much trouble.
And as a fellow HNer pointed out the other day on an unrelated thread, the native interop is painless. You can load .dll, .so, .dylib files with ease. No frankenstein FFI (ala Go or Java).
The language is safe. GC can be avoided (or controlled), and it offers raw pointers, manual memory manipulation with spans, and more low-level features through the unsafe subset of functions.
I know people like to say this started as a rip-off of Java, and there is some truth to that, but I have too much respect for Anders to believe he set out to rip off Java part and parcel. There was a method to his madness, and from my perspective, C# has always been a step ahead in programmer ergonomics (but definitely not performance). Maybe that's due to the sheer intertia of the Java ecosystem, or to Sun and then Oracle being more conservative, I don't know. Hell, it probably had more to do with Microsoft's reputation.
I value programmer ergonomics and tooling, almost above all else, and I am a happy camper. You can write C# from several different angles as you see fit, and in most cases it checks all the boxes for a large subset of projects.
> I'm also not a huge fan of ASP.Net. I've never really cared for it, and I think that stems from a project I had early in my career duct-taping together another developer's classic ASP applicat^HHH monstrosity and mucking about with IIS and FoxPro (!!). I know it's not classic ASP, but once bitten, lol. I will say that it is modern and performant, but very rigid. I'd defer to others' opinions here because I have mostly avoided it.
Indeed, it's a completely different product nowadays.
> That being said, I have found the Android/iOS solutions to be underwhelming. I understand the iOS side a bit, but I thought Android would be better.
And Mac OS.
With the discontinuation of VS Code for Mac, I'm pretty concerned whether Microsoft is going to keep supporting those platforms.
I've only looked at .NET briefly, but it seems that they're not even adding new Mac APIs to the C# bindings any more, and most of the documentation mentions old Mac OS releases like Catalina.
I don't think they'll ever drop Mac support completely, as plenty of people develop ASP.NET applications on their Macbooks, but I'm very hesitant to use .NET for desktop applications where native integration is key. Especially now, when Microsoft seems to be going all-in on Catalyst.
They don't seem to care much about Xamarin either, favoring other technologies like React Native.
Java the language is conservative by design. They always are the last mover for language changes on purpose. They feel that it allows them to make better decisions and they don’t have to adopt bad ideas until other languages try them out.
Readit News
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.
Yes, it’s possible you’ll have to deal with Enterprise-y code sometimes. But, it’s usually your team’s choice as to what is written. Also, people don’t seem to complain quite as much about it when they encounter it at a FAANG elsewhere that tries to do “good” engineering, but that’s another discussion. :)
I feel like the C# team really focuses on DX when evaluating language features.
Best place to get a feel for how rapidly the language evolves for the better is the version release docs for C#:
C# 13: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
C# 12: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
C# 11: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...
etc.
Compared to JS, Go, Java, etc. I feel like C# evolves significantly faster and the team is faster to validate, implement, and deliver improvements to the language.
I think this is also why some folks who tried C# say 5-6 years ago have no idea how fast the language has evolved for the better.
That's not unfair at all, I think it's a fair assessment. Industrial tools should have adults at the helm. People who care about longevity and robustness foremost. About delivering quality and stability where the main value points of a language are.
Upgrading from the classic .NET Framework to the modern .NET is usually a long process. Simple console apps, desktop apps, and libraries might be doable with an automated csproj upgrade. But Web apps require a rewrite from scratch, because the old ASP.NET is incompatible with the modern ASP.NET Core.
When .NET 10 comes out, it will be 2 characters, double the work of the previous process. Unacceptable!
/s
The NativeAOT approach is also very interesting making it possible to build native binaries similar in size and performance to languages like Rust and Go (not quite actually, but close).
It's also possible to build "single binary" tools by using <PublishSingleFile> which comes in handy when building small helper tools for the command line.
It's common to find Java binaries build 20 Years+ to run on present day systems without issue.
Java: no bonus work induced by third parties to keep projects alive, keeps working for a long time. Would recommend.
Both languages are very impressive and benefit from the competition.
This is because Windows comes with some form of .NET, but also other programs end up needing to install multiple versions of the .NET runtime. Eventually, you just have them on your machine. It's the equivalent to installing every version of Python and just letting the problem sort itself out.
It's not different than other tech-stacks, you're just eating the costs up front instead of running into them in a more obvious manner.
.NET (in its entirety) has lots of breaking changes that won't work from one version to another. More recently MS has been better about documenting these, especially as .NET's footprint increases inside outside of the control of MS (non-Windows environments): https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
>In fact, PowerShell itself is another reason I appreciate .NET it shares many concepts
PowerShell is built on .NET (in whatever form .NET Framework and .NET/core) lol. It doesn't "share" anything, it _IS_ shell for .NET.
I do acknowledge that .NET has its share of breaking changes from time to time, but in my experience, the friction is significantly lower compared to other environments I’ve worked with.
> PowerShell is built on .NET (in whatever form .NET Framework and .NET/core) lol. It doesn't "share" anything, it _IS_ shell for .NET.
I never said it wasn’t! I was simply speaking from the perspective of the frontend experience. While PowerShell is built on .NET, my point was about how its functionality and design make it feel familiar to those already accustomed to .NET development.
During the time I was working with .net from 2005-2020, I saw the transition from Webforms to ASP.NET MVC to the MVC/WebAPI split. I also saw the transition from Linq2SQL to Entity Framework.
There was also the weird time when you could run ASP.Net Core and EF Core on top of .Net Framework.
Then the entire .Net Framework to .Net Core was a major upheaval.
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.
Um. Have you tried learning English? This is definitely not the case.
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.
I did a lot of programming in .Net 1.1 and quit just after 2.0 was released. I've then spent all my time in other programming languages. Past year at work we've been starting our transition to .Net. I must say I found exactly the opposite.
All the things I knew I could still do, and I found the new stuff quite readable. Sure I had to do a couple of searches to read up on some of the changes, but overall I've been productive in .Net 8.0 from the moment we started. I have had no issue reading library code, as one does to figure out what's really going on.
Also, Visual Studio guided me to rewrite my outdated code in better form, which also helped to understand the changes.
This is entirely unlike C++ which I also used a lot before and quit just shy of C++11 getting released. These days when I read some modern C++ code I frequently have absolutely no idea of what's going on.
As for EF I don't know, as the database we still have to support doesn't support it so haven't had a chance to use it yet. If we do, we will be writing our own SELECT statements for anything beyond a trivial primary key lookup though.
YMMV.
C has this same “problem” but I expect it’s less prevalent because most people still write in C99 and ignore newer C features (similar to C++). https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.h...
I think because the toolchain is unified, people tend to adopt newer C# features faster than other languages. You aren’t waiting on your permutation of msvc/clang/gcc to update, so when a new version releases, people update and start using new stuff. That said you can also write C# still like it’s 2005, but you’d be wasting time.
C# (to steal Jon Skeet’s language) has developed in the direction of removing “ceremony” in writing code. What in C# 2 would have taken like 20 lines to create a class in a CLI program and print a value can now be done in like 2 lines without sacrificing readability, and if anything is easier to read because you’re only looking at load-bearing statements instead of lots of flaff to scaffold simple behavior.
ORMs pose the same problem regardless of the language/framework or implementation. I've seen the same issues with Java's hibernate, too, no difference there.
It seems to be the doomcycle of life in development stacks. Fresh system cuts through the accumulated cruft of the old, only to gather more and more niche cruft until it collapses on a beach of arcanary while the next wave of simplicity rises behind it.
I have been part of both ecosystem for their whole lifetime.
Obviously in a greenfield startup like the article (I'm assuming) it's maybe a bit less of an issue--at least to start? Definitely a challenge, though, especially compared to something like Go or C.
Imo ORMs are useful as a way of making common actions easy and quick but that thinking they shield you from knowing what they're doing and how SQL works can quickly cause a ton of problems.
There are a lot of EF queries that don't even need to into raw SQL to radically improve (though 100% that's the case often enough). Some `n+1`'s and `ToList`'ing million record queries into memory when you need the top 5 being examples that come to mind.
If you think this is the way to go in your organization, just do that.
But I seriously don't get why it's so impossible to just read the changelog every year. Takes literally 2 hours per year. Most of the changes are quite self-explaining anyway.
Spend the trivial bit of time it takes to learn modern C# syntax and you'll be able read any C# fine. You'll get to use modern tooling built on a language designed along with the tools, as long as you embrace it.
On the other hand, you can spend the time it takes to learn the idiosyncrasies of every different C codebase you encounter and how they handle all the little problems differently for trivial things that would be well documented and baked into C#.
And to make matters worse, it seems there's no resource that fully explains all of its relevant aspects, like the Rust book does for Rust for example.
There are tutorials intended for people who can't program at all, there are dry reference documents, there are resources explaining specific features, but nothing that a reasonably competent non-C# programmer could read start-to-finish to fully grasp the language.
There's the Microsoft Docs site, but it seems to contain the same or very similar information scattered through different sections.
First result when searching "C# guide" or "C# language documentation".
Or if you want a more detailed view up front, it's https://learn.microsoft.com/en-us/dotnet/csharp/tour-of-csha..., which you'll end up inside of the menu structure somewhere by clicking any of the links in the first page.
I've put several developers at work through reading this and they've gotten up to speed in the language very quickly. It's comprehensive and, at least according to what I think is important having been doing C# for 20 years, very well organized.
For individual developers this may be great: "I learn new things" "I found a faster way" "this abstraction allows me to do X"
But for a company with more than X developers this becomes a risk.
C# 2.0 was 20 years ago!
Maybe you just need to git gud? IDK. I appreciate the new features in C#, every time. They solve real problems I've had.
EF is a different issue. You don't have to use EF. You can use ADO.NET still if you want. It still works completely fine. NHibernate is still a going concern. I appreciate EF because I have been able to use it to treat databases more like libraries than remote services. Being able to do that makes it so I can iterate in development much more rapidly. I do miss writing a tight SQL query, but honestly, it's not necessary for 99% of cases and the other 1% has an escape hatch that isn't hard to use. So... again, I guess just git gud?
I don't know what else to say. If you don't bother to learn the language or libraries you're using, you're going to have a bad time, regardless of which.
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.
I think that it's also much more common with companies that aren't primarily tech-focused, as those companies usually have cosy relationships with Microsoft. Pure tech companies, startups and FAANGs don't seem to use it much.
This also ties into geography. In the US, far more people work for startups, FAANGs and pure tech companies than in Europe, where traditional businesses and "software houses" are far more prevalent, which means there's far more C# there.
It is the cool and modern language in today's landscape. But it is popular among the companies which use it the opposite way. Now, we shouldn't complain too much. Because this is what made .NET survive in the first place. But I wish more people looked at projects like Garnet, Ryujinx, various greenfield HPC and highload libraries in the ecosystem over yet another CRUD template. Business domain modeling is much better done in F# anyway!
I’m loving the fact that the industry is getting tired of Node in the backend and the tech debt it incurs after a few years. Rediscovering old values and getting excited about them is perfectly okay. Nobody remembers all of history—reinvention is part of the process.
Thus, anything that gets in the way of that is not worth it.
Dead Comment
Just look at https://learn.microsoft.com/en-us/dotnet/standard/security/c... and https://learn.microsoft.com/en-us/dotnet/framework/network-p... for a sneak peek into this madness.
The modern version of DotNet, "Net Core" is effectively a reboot of DotNet, with a very cross platform focus and redesigned API's based on decades of experience.
The second article uses the wrong link too (it's for Framework, not for .NET).
Frictionless, pleasant, not thinking too much how to express things (and still managing to write them reasonably idiomatic), tends to support clean encapsulated code, quite rich environment/libraries, great tools (debuggers, profilers), safe, relatively fast, not many foot guns, zero build setup, on small project zero build times, trivial to create good functional simple UI, can get fancy dynamic with reflection when I need "magic".
Basically not many pain points that would make me rage quit and almost everything I'd want is simple to achieve.
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.
Some of the niceties over the last several versions include immutable record types, stack allocated structs (ref structs), lambdas (and a host of enhancements thereof since), async/await (of course), generic math ops, platform intrinsics, pattern matching, AOT, nullable types, robust generics, reflection, dynamic types, etc. The big thing I expect next is algebraic data types.
The language has really grown by leaps and bounds, but it doesn't ever feel overwhelming, and it has really kept its verbosity to a minimum without turning into a soup of hieroglyphics.
That being said, I have found the Android/iOS solutions to be underwhelming. I understand the iOS side a bit, but I thought Android would be better. That's not to say you can't make great applications using C# on these platforms, just that it requires more effort.
I'm also not a huge fan of ASP.Net. I've never really cared for it, and I think that stems from a project I had early in my career duct-taping together another developer's classic ASP applicat^HHH monstrosity and mucking about with IIS and FoxPro (!!). I know it's not classic ASP, but once bitten, lol. I will say that it is modern and performant, but very rigid. I'd defer to others' opinions here because I have mostly avoided it.
But in general, the tooling is great, and I don't encounter much that ties you to a Windows box anymore. I know there are some differences in platform support, but most of the rough edges were handled in the early days of .NET Core 2 & 3. Now that we're way past that (the "traditional" .NET merged with .NET Core in a combined version 5 release). Now that it's on version 9, the language features and low-level hits keep coming. I can, today, write code that is 99% of what you can get from C++ (and in some edge cases can exceed it), compiled to native code, that will run on Windows & Linux (x64 & arm64), BSD & MacOS without too much trouble.
And as a fellow HNer pointed out the other day on an unrelated thread, the native interop is painless. You can load .dll, .so, .dylib files with ease. No frankenstein FFI (ala Go or Java).
The language is safe. GC can be avoided (or controlled), and it offers raw pointers, manual memory manipulation with spans, and more low-level features through the unsafe subset of functions.
I know people like to say this started as a rip-off of Java, and there is some truth to that, but I have too much respect for Anders to believe he set out to rip off Java part and parcel. There was a method to his madness, and from my perspective, C# has always been a step ahead in programmer ergonomics (but definitely not performance). Maybe that's due to the sheer intertia of the Java ecosystem, or to Sun and then Oracle being more conservative, I don't know. Hell, it probably had more to do with Microsoft's reputation.
I value programmer ergonomics and tooling, almost above all else, and I am a happy camper. You can write C# from several different angles as you see fit, and in most cases it checks all the boxes for a large subset of projects.
Indeed, it's a completely different product nowadays.
Take a look at this! https://learn.microsoft.com/en-us/aspnet/core/fundamentals/m...
And Mac OS.
With the discontinuation of VS Code for Mac, I'm pretty concerned whether Microsoft is going to keep supporting those platforms.
I've only looked at .NET briefly, but it seems that they're not even adding new Mac APIs to the C# bindings any more, and most of the documentation mentions old Mac OS releases like Catalina.
I don't think they'll ever drop Mac support completely, as plenty of people develop ASP.NET applications on their Macbooks, but I'm very hesitant to use .NET for desktop applications where native integration is key. Especially now, when Microsoft seems to be going all-in on Catalyst.
They don't seem to care much about Xamarin either, favoring other technologies like React Native.