Hacker News Reader

> 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.

YMMV.

Modern EF Core can generate SQL very close to handwritten and will aggressively warn you if you do something dumb. I wouldn't worry about it.

Good to know, though we have mostly either trivial (ie by indexed key) or complex queries, with very few "medium complexity" queries.

For the complex ones we like to have full control as it almost always turns into a major ops issue if the queries are not performing well.

Though perhaps if we can catch changes of the generated queries in our test suite we could let EF generate them. Trust but verify kinda deal.

My example was 9 months old. At least in this instance EF did not warn, and caused great problems.

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).

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.

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.

Java has been playing catch-up for a while after the ecosystem stagnated on Java 8. The language seems to be very willing to incorporate new changes, but most interesting improvements seem to be stuck behind "nth preview" developments (basically useless), or the release was as badly thought through as any C# feature.

For instance, Loom took ages to make it into Java itself, finally reaching an LTS version in Java 21, but it took until Java 24 for Loom to be able to deal well with any code hsi g synchronized {} blocks. They also went back on their previous advice ("change synchronized blocks to reentrant locks to fix compatibility") which must be fun news for the projects that did follow their earlier advice.

And while introducing modules and breaking the compile for any old Java project seems to have gone through without much trouble (throwing compiler warnings everyone ignores for several releases before breaking code, of course), the language seems to dread minor backwards incompatibilities when it comes to language level improvements like nullable types, introducing a tri-state nullability definition while also refusing to implement some stricter null checking to ensure the language feature is entirely opt-in.

Java feels like the backend is picking up features as fast as Javascript or Rust or C#, but the frontend is managed like C. A weird mix between "change is scary" and "stagnation is decline". It's the language at the forefront of high-performance dynamic programming while also having had an unimplemented "const" keyword for 25 years.

The architecture astronauts feel just like at home in .NET as well.

I have been part of both ecosystem for their whole lifetime.

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.

It's here: https://learn.microsoft.com/en-us/dotnet/csharp

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.

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.

Using different libraries across projects is an organizational issue, not the fault of the programming language.

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.

You can decompile any modern .NET assembly to C# 1.0 in ILSpy. It can be quite useful when learning the language new syntax.

>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)

C# 2.0 was 20 years ago!

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.