Why Tracebit is written in C#

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

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.

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.

The same is even better with Java.

It's common to find Java binaries build 20 Years+ to run on present day systems without issue.

>With .NET, this issue is much less pronounced.

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.

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

Microsoft is king of backward compatibility.

to only downside, If you support everything, everything will be used. Deprecating aggressive hurts shortterm but pays off long term.

>Like English, it is super easy to pick up and use.

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.

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

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

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.

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.

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.

[flagged]

Recently I've got bitten by the comically poor cross-platform cryptography support in .NET

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.

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.

C# is my second favourite language, despite it being OOP first. My personal fav is F#.

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.

There's no programming-language cozy like Lisp cozy, but I can see myself working quite happily in C#.

C# has changed a ton in the last few years, it’s definitely 4/4 for me…

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.

C# started as a language tightly aligned with C++/Java, but has since moved to be something else entirely that is highly capable.

I assume that free-floating functions are global functions. You can achieve something similar by "global using". Put this in a file and tug it away somewhere:

"global using static YourStaticClass;"

Now you can call all the static methods on the class everywhere.

As for the using vs. naming convention, most people use the IDE and hover the mouse over the type to see its identity. Once you get proficient with the IDE, you can do it using shortcuts. However, if you really want to prefix all types with a shorthand of the package it came from, you can do it with aliases in C#.

Speaking as an old C# hand: 1) I don’t think static methods/classes are that big a deal. There’s a free-floating syntax for short scripts but I don’t regard this as much of a problem. There’s also the rarely used using static syntax. 2) The common convention assumes you’re using VS or Rider and can just mouse over to find where things come from. So you’re not missing anything except possibly an IDE. 3) Yeah, it is. But again, the IDE integration is great. 4) can’t argue with you there. The C-style syntax was a mistake that’s been replicated in way too many places.

The wider problem is that to do a thing you have to start thinking about the design of IDoAThing and a implementation ThingDoer before you've even worked out exactly what to do yet.

Honestly, every point you mention in my opinion is positive. - if you feel like using static classes and methods, you should spend more time thinking about architecture - namespaces are just what they are - in modern IDEs just write /// before a member declaration, it will insert the whole comment block for you

What do you miss in F#?

I’m in the same boat. I worked on a project with Microsoft Consulting Services when the .Net Beta 1.0 was released in 2001. I felt very lucky to be employed at the time (post 9/11, .com bubble bust) and also getting paid to work in the latest stack. Like you I have no regrets.

And they're working on Unions, although last I heard they won't make it into dotnet 10/c# whatever version is coming with it.