from Hacker News

Why Tracebit is written in C#

by mrcsharp on 1/31/25, 11:22 PM with 301 comments

  • by unsignedint on 2/1/25, 2:18 AM

    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.

  • by LeFantome on 2/1/25, 4:31 PM

    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.

  • by ThinkBeat on 2/1/25, 8:26 AM

    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.

  • by danielodievich on 2/1/25, 4:12 AM

    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.
  • by PeterStuer on 2/1/25, 8:27 AM

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

  • by noveltyaccount on 2/1/25, 3:00 PM

    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.
  • by sophiacamille on 2/1/25, 2:47 AM

    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.
  • by halfcat on 2/1/25, 1:58 AM

    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.

  • by ngrilly on 2/1/25, 10:29 AM

    I recently inherited a C# code base at work. I agree that C# is a powerful, productive, and mature language, but as someone who has been programming mainly in Go, Python, and a bit of Zig over the past few years, there are a few things that feel like a regression in C#:

    - The absence of free-floating functions (everything is an object, and I must use static methods on static classes).

    - When “using” a namespace, the convention is to make all the symbols in the “used” namespace available directly in the current namespace. That makes harder to know where symbols are coming from when reading code. And to avoid name collisions, people tend to use longer names. The convention in Go or Rust is to prefix most symbols with the package they are coming from. But perhaps I’m missing something and need to read/write more C#.

    - The syntax for doc comments with tags such as <summary> is super verbose. I don’t see the point. Docs are working great without these tags in other languages. Reminds me of my J2EE days.

    - I really prefer the name before type syntax (used in all new languages such as Go, TypeScript, Go, Swift, Kotlin, Zig, etc.) to the type before name syntax (used in C#, C, C++, Java, Dart).

  • by GiorgioG on 2/1/25, 3:47 AM

    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#.
  • by EMM_386 on 2/1/25, 2:24 PM

    I've been working with C# since 2001, which is when it came out of beta stage and into production-ready.

    My last greenfield product I was able to choose the stack (except the database, which I was stuck with).

    Front-end? Angular, mostly because I felt it fit best with experienced .Net developers.

    Back-end API layer? C#, obviosly.

    So I've been working with C# for 24 years. No regrets.

  • by spicyusername on 2/1/25, 2:54 AM

    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.

  • by idatum on 2/1/25, 5:05 PM

    I was pleasantly surprised to see FreeBSD part of the list of available cross-platforms running .NET. I already had a FreeBSD instance for ZFS and was able to also host a website and some workloads written in C#, avoiding the need for a separate Linux instance.

    https://wiki.freebsd.org/.NET

  • by rednafi on 2/1/25, 8:45 AM

    C# is a nice language, but it has a huge surface area in terms of syntax. Also, Microsoft’s past behavior makes a lot of people avoid it entirely before even considering it.

    Plus, many, like myself, just don’t want to write OO code, no matter what. I simply don’t want to spend my time working that way. This makes hiring difficult, especially when many young engineers who start their careers with non-OO languages instinctively shy away from Java-esque languages.

    That said, I welcome language diversity in the backend and love that new startups no longer default to Node. I’d rather deal with OO than fiddle with a poorly designed language that was never meant for anything but throwaway frontend code.

  • by brainzap on 2/1/25, 3:46 PM

    The tooling argument is contradicting itself: You need a big fat IDE to work with c#. Profiling is not even part of the default tooling, Microsoft tutorials want you to upload profiles to external flamegraph tools etc.
  • by skeeter2020 on 2/1/25, 1:29 PM

    C# really benefited from the trail that Java broke, and has stumbled in similar areas, notably the UI space. I know people who love Blazor but it's not for me. MAUI just looks like MSFT's latest cover fire & delay strategy; not going to get me again. But if you're writing primarily backend code in modern .Net C# is very productive, refreshingly lightweight, pretty much complete and has great tooling and lots of taleneted developers in the ecosystem.
  • by begueradj on 2/1/25, 9:57 AM

    This article is very useful because the author shares his thought process as why he picked C# over languages he is familiar with (such as Python), or something trendy as Rust. I wish more articles like this one would pop up every now and then here and elsewhere.
  • by account-5 on 2/1/25, 8:43 AM

    My only experience of C#/.Net programming is by way of powershell. But the comments here make me think it would be a good idea to invest some time in learning c# beyond what it can provide over add-type in powershell. I've mostly avoided it because I thought it was windows only, I've learned dart and flutter for cross platform programming. Can c# run on mobiles?
  • by MaxGripe on 2/1/25, 11:28 AM

    In my opinion, one of the most underrated things by people programming in C# is the fact that they also have F# at their fingertips. They ignore it because they haven't dedicated enough time to appreciate how powerful and fantastic it is.
  • by doorhammer on 2/1/25, 4:05 PM

    Tangentially related: When I was doing C# on Windows full time I ended up using LINQPad a ton for almost all of my daily scripting.

    LINQ + MoreLinq + Extension Methods makes it really easy and fast to make type safe internal DSLs that I wouldn't want anyone I care about to have to use but worked really well for personal power tooling. (you also _can_ definitely write more sane ones, but I didn't have to for personal stuff and it let me burn off the cleverness in my brain before working on code other people might have to work with)

  • by pjmlp on 2/1/25, 8:49 AM

    Great post, instead of the usual rewrite X in Y, because reasons.
  • by knallfrosch on 2/1/25, 11:11 AM

    If Microsoft released a new version and called it something other than asp.net, .net, .net framework, .net core or anything like that, I'd be so happy.

    Finding outdated search results from 2012 is probably the biggest impediment for the ecosystem.

    Or finding out, from the project XML, whether a project is .net48 and Windows only or .net6 I'd a non-trivial task. Why?

    Other than that, I agree with the article. It's a mature ecosystem where the crucial bits have first-party support.

  • by ansgri on 2/2/25, 9:54 PM

    I didn't follow it close, but had an impression that C# and .Net still have a significant Windows ecosystem bias. But this article, and comments from happy C# users, may just convince me to re-learn modern C# and start using it in everyday work. I'm kinda tired of C++/Python ecosystem, and have fond memories of working with C# around 2.0-3.0.
  • by tester756 on 2/2/25, 1:29 PM

    I've started programming in C++ and when I encountered C# then my initial reaction was:

    Wow, this language allows me to focus on writing programs (algorithms) instead of fighting with the language!

    9 years passed by, now 'veI worked with C, C++ and C# for money and my opinion is still the same.

    I've earned way, way more money in C/C++ world, but I was 5x times happier / saner in C# world.

  • by codr7 on 2/1/25, 2:23 AM

    Makes sense, but Java's mostly portable library eco-system and its maturity would make a very strong contender to me.
  • by coder543 on 2/1/25, 2:08 PM

    I have never had a chance to use C# professionally, but it was one of the first languages I taught myself when I was first learning programming when I was a kid. I have a lot of fond memories of it, and I hear so many positive things about C# and .NET Core these days… but I just don’t see very many interesting tech jobs where I would have the chance to use C#. So, I’ve mostly used Go, Rust, and TypeScript through my career up to this point.

    If anyone wants to point me to some good C# opportunities, I’m interested. (Tracebit is looking for a founding engineer, so presumably they want someone who is already an expert at C#, and I doubt they want to sponsor the visa work needed to bring someone to the UK.)

  • by npodbielski on 2/1/25, 3:49 PM

    TPL seems fine in documentation but I found it very hard to be used in real world scenario. Wiring evrything to single input-output or using dozens Join blocks to achieve data structure you want for some blocks was not pleasant. Also finishing pipeline in the right time is also not that easy. Either blocks were not finishing at all or finishing too early. I end up writing my own flow library that is much easier to use for simpler pipelines, yes not so versatile and does not allow spanning multiple inputs across multiple blocks, but at least it does what it supposed too.
  • by neonsunset on 2/1/25, 5:11 AM

    Nice! C# is also a secret systems programming language in a way that competing GC-based languages are not. It’s actually very nice for high load environments. With the caveat that, much like in Rust, you have to actively vet your dependencies and sometimes write your own optimal implementations, which C# enables incredibly well with precise control over memory management, first-class structs, zero-cost abstractions, SIMD and a compiler that is slowly closing the gap with LLVM.
  • by ilitirit on 2/1/25, 12:02 PM

    I have used a myriad of programming languages in production in my nearly 25 years of professional programming. There are things I love (almost never "hate") about most languages.

    But the reason C# is one of my favourite languages to code in professionally is simply because of how easy it is to setup the environment and just get to work. Admittedly on Windows, but I've learned over the last 5 years it's a pretty simliar experience on Linux too. No messing with environment variables or paths; no header file wrangling; no macro shenanigans; no messing with virtual memory settings etc etc etc.

    Yeah, I get it. Choice is nice. But when it comes to my job what's most important is that I can just get to work.

  • by lordofgibbons on 2/1/25, 2:56 AM

    How does it compare with Kotlin for backend development, which inherits all of the JVM ecosystem?
  • by thdhhghgbhy on 2/1/25, 7:23 PM

    Haven't written C# for 8 years, but Visual Studio used to be dog slow. But that's the only criticism I can think of, love the language. I remember when ReactiveX came out, C# became close to unbeatable at that point.
  • by germandiago on 2/1/25, 3:41 PM

    How does C# compare to Clojure, at which I am looking lately a lot with a wish to use it for distributed applications productivity-wise, concurrency-wise and productivity-wise, including deployments in production?
  • by arrty88 on 2/1/25, 4:44 PM

    i love dotnet / c# and i would love to work with it again. i have been in the typescript/node world for the past 10 or so years, and while productive, it leaves much to be desired.
  • by jchw on 2/1/25, 3:59 AM

    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.

  • by sirjaz on 2/1/25, 8:42 PM

    I hate people always raging on Windows, but I love that they embraced .Net and C#. Windows outside of its cost has a more advanced kernel, note WSL1.
  • by romaniitedomum on 2/1/25, 5:07 AM

    Honestly, this reads more like someone who wanted to use C# from the outset and needed to come up with reasons to justify it, rather than an honest comparison of a number of languages and platforms with a view to selecting the best fit for the problem domain. None of the listed reasons for choosing C# are unique to C# or its ecosystem. And some of them seem to have been discovered to be applicable only after the fact.

    For instance, productivity is listed as the top reason, but his team only found C#/dotNET to be the most productive after using it. They didn't know it would be the most productive in advance. So it wasn't a reason for choosing that platform.

    Other reasons listed are, 1 Open Source, 2. Cross Platform, 3. Popularity, 4. Memory Safety, 5. Garbage Collection, 6. Stability, 7. Statically-Typed, 8. Batteries Included, 9. Tooling, and 10. Performance. I think there are plenty of languages and platforms that are as good as C#/dotNET in all of these areas, but there's nothing here to suggest any of them were even considered.

  • by timeoperator on 2/1/25, 8:47 AM

    "Performance is rarely the primary reason to choose a language, but it’s certainly a nice bonus."

    (X) Doubt

  • by _pdp_ on 2/1/25, 10:22 AM

    The developer knew how to program in C# - end of story.
  • by yohbho on 2/1/25, 1:28 PM

    Free as in beer? Is Mono free as in free beer, or .NET, which at any time can be commercialized?
  • by whoknowsidont on 2/1/25, 3:09 AM

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