Why Tracebit is written in C#

Overall sentiment about C# / .NET

• Many commenters describe C# as a “solid 3–4/4 at everything”: productive, ergonomic, safe enough, and with good performance; not always “best” but extremely well-rounded.
• Several say it’s the language they keep coming back to for backend work; words like “cozy”, “comfortable jumper”, “hard to rage-quit” recur.
• Others think the article reads more like post‑hoc justification for a language the team already liked; all listed advantages could apply to other ecosystems too.

Language evolution and features

• Strong praise for how much C# has evolved (records, pattern matching, async/await, spans, NativeAOT, intrinsics, nullable ref types, generic math, improved lambdas).
• Comparisons to TypeScript are frequent; both share a designer and many constructs. Some note bidirectional influence between C# and JS/TS.
• Some worry about “constant expansion”: large syntax surface, many ways to do the same thing, and new code looking alien to C# 2.0-era developers.
• Others counter that most changes are syntactic sugar, backward compatible, and quickly pay off in reduced boilerplate if teams agree on style.

Productivity, tooling, and “batteries included”

• .NET is repeatedly praised for smooth setup and “batteries included” APIs: fewer third‑party dependencies than Node, Rust, or Python for common tasks.
• Visual Studio / Rider are seen as exceptionally powerful; VS Code + language server is considered sufficient by many. Some reject the claim that a “big fat IDE” is required.
• ORM experiences are mixed: Entity Framework Core is praised as productive and much improved, but misused ORMs (EF or Hibernate) can cause severe performance problems.

Performance and “systems” angle

• Several argue .NET now has a very high performance ceiling, close to C/C++/Rust/Zig in hot paths when using structs, stackalloc, spans, intrinsics, and NativeAOT.
• Debate over whether .NET’s control over memory is truly comparable to C; proponents demonstrate fixed-size buffers and stack allocation, critics highlight GC and lack of whole‑program manual allocation.
• Comparisons with JVM: some claim CIL + reified generics give the CLR more low‑level optimization potential than JVM bytecode; others say real‑world gaps depend heavily on workload.
• Versus Go: disagreements about goroutines vs async/await. Some prefer Go’s debugging and model, others note .NET tasks have lower overhead and more expressive composition.

Stability, codebase rot, and upgrades

• Multiple people praise .NET projects for resisting “bit rot”: old code often builds and runs with modern SDKs; dotnet restore plus the right SDK usually suffices.
• Counterpoint: ecosystem history includes many breaking platform shifts (.NET Framework ↔ Core, WebForms → MVC → ASP.NET Core, Silverlight, UWP, etc.).
• Upgrading between recent .NET Core LTS versions is described as mostly easy, though third‑party dependency mismatches can still cause work. Migrating old ASP.NET Framework web apps to ASP.NET Core usually means a rewrite.

Web, desktop, and mobile

• Modern ASP.NET Core (especially minimal APIs) is considered fast and productive by many, but one recurring complaint is naming chaos: many different “ASP.NET X” products over the years confuse newcomers and job seekers.
• Microsoft’s GUI story is widely viewed as messy (WinForms, WPF, UWP, MAUI, Blazor variants). Third‑party Avalonia and MonoGame are frequently recommended for cross‑platform desktop/game UI.
• Mobile/iOS/Android support (Xamarin/MAUI) is seen by some as underwhelming or uncertain, especially on macOS; others note .NET plus MonoGame/Avalonia can target many consoles and OSes.

Ecosystem, culture, and comparison with others

• Several frame .NET and JVM as “adult-run” ecosystems: strong backward compatibility culture, large first‑party libraries, and better fit for long‑lived business systems than trendier stacks.
• Others find Java’s library ecosystem more portable and mature; defenders say .NET’s library portability is similar and its FFI is much easier than JNI.
• Go is favored by some for simple, data‑oriented code and infra-tool integration; critics argue Go’s limitations force awkward workarounds and that C# can be written in a similarly data‑oriented style.
• Rust is acknowledged as better for tight resource control and safe concurrency; many still pick C# for faster feature delivery in typical SaaS backends.

OO vs data‑oriented / functional styles

• A noticeable group dislikes GoF-style OO and sees Java/C# ecosystems as culturally attached to it, making such codebases unattractive to modern devs.
• Others stress that modern C# is multiparadigm: you can use records, tuples, static modules, extension methods, and fairly functional patterns; F# is recommended for more “pure” functional/data‑oriented work.
• F# itself is praised but seen as under-resourced and with weaker tooling/integration than C#, which hinders adoption despite strong language merits.

Security and trust concerns

• One commenter questions C# for a security product: worries about GC pauses, powerful reflection/dynamic code, AMSI bypass techniques, and opaque runtime mutation.
• Others respond that .NET’s ecosystem scores well on supply‑chain security metrics, NuGet has relatively few advisories, and Microsoft invests heavily in patching CVEs in first‑party libs.
• Separate unease exists around Microsoft’s stewardship: past foundation drama, tooling regressions (debugger, live reload), and fear that competing OSS libraries get “crushed” when Microsoft ships alternatives or when maintainers change licenses under pressure. Some argue Azure incentives and “developers first” culture make a long‑term bait‑and‑switch unlikely.

Market perception and adoption

• Several note that in B2B, Java and .NET quietly dominate; claiming C# for SaaS is more mainstream than contrarian.
• At the same time, C# is underrepresented in “cool startup / FAANG” discourse, leading outsiders to underestimate its prevalence and the satisfaction of its user base.