Why Tracebit is written in C#

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.

I have tried quite a few languages over the years. C# is my favourite. I don't really know why, it just feels like a cosy, warm jumper.

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.

I recently waded into using C# to tinker with video game development using MonoGame, and I have been so surprised by how nice of a language it is to use.

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.

Every time I futz around with another language I go back to C# for backend work. Part of it is likely due to familiarity (I’ve been using it since 2002). I wish MS would put some additional resources into F#.

Makes sense, but Java's mostly portable library eco-system and its maturity would make a very strong contender to me.

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 certified Go zealot; pretty much anyone who's trolled through enough threads here can attest to that. However, I am increasingly interested in .NET these days. I think Microsoft and the .NET community have built something truly compelling, and the language design of C# is superb (and I'm not saying it's perfect by any means, but I'm routinely impressed with what they accomplish version over version.)

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.

How does it compare with Kotlin for backend development, which inherits all of the JVM ecosystem?

I'm kind of shocked that one of the qualifiers for choosing a tech-stack wasn't security, on a product that's specifically in the cyber-sec domain?

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