Reinventing how .NET builds and ships (again)

Original Article ↗ Hacker News Discussion ↗

Language & Framework Choices

  • Several commenters compare .NET to Python, Node, PHP, Rust, Java, and Kotlin:
    • Python is praised for simplicity and fast iteration, and for good AI/LLM support, but criticized as slow and hard to scale CPU-bound or high-traffic services.
    • .NET and Java are viewed as much faster and far easier for multicore utilization than Python/Node (GIL, worker model, state passing).
    • Some startups reportedly hit reliability/performance ceilings with Python/Rails/Node and had to refactor or add many servers.
    • Rust is valued for correctness and catching bugs at compile time, but seen as slower to develop with weaker web-framework ergonomics.
    • Kotlin is liked but seen as “sugary” with tooling/Gradle friction; modern Java considered a safe, rapidly-improving choice.
    • Modern PHP defended as much better and reasonably fast, but some wish earlier projects had chosen .NET.

Performance vs Productivity

  • For many backends, the DB is the bottleneck, making framework speed less critical; horizontal scaling and autoscaling can be cheap.
  • Others report concrete benchmarks where ASP.NET significantly outperforms Python frameworks.
  • Some argue .NET can be “nearly as fast as Rust” when written for performance, and far faster than Node/Python, but this claim is challenged and benchmark sources are requested.
  • ORMs:
    • Entity Framework (Core) splits opinions: some report slowness and complex queries, others find modern EF Core performant if configured (no tracking, projections, manual Includes) and good for most workloads.
    • Several patterns: EF for simple CRUD, Dapper or raw SQL for complex/high‑perf queries.

.NET Churn, Releases, and Enterprise Reality

  • One camp describes the last decade as chaotic: Framework vs Core vs Standard confusion, annual major versions, short support windows vs large, slow-moving enterprise codebases.
  • Others say the “chaos” was limited to the Framework→Core transition; from .NET Core 3 onward, upgrades are described as mostly one‑line csproj changes plus dependency bumps.
  • The LTS model (even versions, 3+ years; odd versions, now 24 months) is seen by some as “refreshingly sane” with long overlaps; critics argue even this is too fast for large, heavily customized systems with strict validation and locked-down tooling.
  • Tension is highlighted between HN-style greenfield/microservice shops and big-corp or government environments where IDE updates, CI/CD changes, and runtime upgrades require lengthy processes.

Ecosystem, Tooling, and Builds

  • NuGet is seen as more curated and stable than npm; Node’s supply-chain volatility is cited as motivation to seek more stable stacks.
  • Some describe entrenched Visual Studio/IIS developers struggling with moves to .NET Core, CLI, Docker, Git, and cloud CI/CD; others celebrate those shifts as life‑changing improvements.
  • The article’s build-system redesign is praised as an exemplary, deeply thought-out engineering effort, with monorepo-style consolidation and alignment to Linux distro source-build practices.
  • Commenters note multiple Linux distros now ship .NET SDKs built from source; this is seen as a win for openness, portability, and reducing dependence on Microsoft’s build infrastructure.
  • Azure DevOps queue times are debated:
    • One commenter suggests abandoning it for bare-metal build servers.
    • A .NET team response says DevOps isn’t the root cause; they deliberately spin clean VMs per job for compliance and robustness. Hot pools or ML-based pre‑warming could cut queue times but would significantly increase cost and complexity.

Legacy .NET Framework vs Modern .NET

  • Many legacy apps remain on .NET Framework 4.x (or even 3.5) due to:
    • WCF, Win32-heavy integrations, Excel interop, and Windows-only features that don’t map cleanly to .NET 8/10.
    • Massive, customer-specific codebases where migration and revalidation are non-trivial.
  • One developer intentionally starts new projects on .NET 3.5 for perceived stability and minimal change; multiple replies call this risky and unnecessary:
    • Modern .NET is said to be more secure, better supported, cross-platform, and you can still write “old-style” code without using new language features.
  • There’s acknowledgment that .NET Framework has effectively fossilized: no new features, limited modern format support (e.g., images), but very long-term support for some versions.

Perceptions of .NET and Microsoft

  • Many express strong respect for the .NET team: high-quality technical posts, relentless performance work (Kestrel, EF evolution), and a successful large-scale break from the old stack.
  • Some feel the broader Microsoft culture is “enshittified,” contrasting sharply with the perceived excellence and pragmatism of the developer division.
  • A minority criticize the .NET community as overly positive and defensive, claiming their real-world experience with .NET projects shows more friction and churn than fans admit.