8 ms·
I'm a chronic framework/language jumper who recently switched some projects to dotnet in production, but without a previous Microsoft-flavored background. I oft
by throwaway13337 3y ago
I'm a chronic framework/language jumper who recently switched some projects to dotnet in production, but without a previous Microsoft-flavored background. I often read hn comments to figure out what I'm missing and what to look out for here. I'm sure this thread will be searched for by people like me in the future.
In that spirit, here's my take.
Pros:
* Best performance of any language without memory management. This is true on Linux, and its memory footprint isn't bad either - especially with AoT.
* Best standard library with great docs covering 90% of what you want in most modern apps.
* Development tooling that is just awesome with rider. Easily navigate and understand the source code of imported libs.
* A reasonable syntax that doesn't make weird decisions because of deep dogma. It beats Go, for me, for instance, because it uses exceptions, generics, and LINQ. This makes the code readable and reasonable to write. I know this is controversial.
* Ridiculously simple deployment. No Redis - jobs and cache are practical in-process. Due to its performance, I don't even front it with nginx. Upload a binary on a fresh VM, supervisor and go. A tiny shell script.
Cons:
* Its object-oriented design. The way files are organized in Go makes a ton more sense and doesn't feel as heavyweight. Also, the addition of records instead of real, validatable value types was a huge missed opportunity.
* Went heavily into async/await - indeed, it was the pioneer. Thread-per-connection, co/goroutines, or green threads are actually better models for most projects. I understand the issue with overhead. But the weird call stacks, and footguns inherent are definitely not worth it.
* Compile time sucks. This is the biggest for me. Having a subsecond reload time is essential to a pleasant code flow for me. Hot reloading has too many holes to be practical and this seems like a blindspot. No one seems to mind but golang, node, and python are all much better here.
My background: I wrote some successful SaaS web apps in Django and transitioned some to dotnet for maintainability. I'd previously used C# also as a game developer with Unity. But I bounce around a lot of tech.
I'm in a unique situation as a solo project dev with a long time horizon. I can care about longevity, speed, and ease uniquely. I don't have to worry about employment opportunity of a stack, for example.
Right now, I'm trying to decide between TypeScript/node and continuing with dotnet for my next project's backend.
The backend I wrote in dotnet remains my most stable. It's beautifully simple to manage in production. If only they could make hot reload not feel so bad.
- neonsunset 3y agoOn certain way of structuring classes and structs - there was and still is dogma among many developers for single file == single class, mainly coming from Java. However, you will see a lot of projects, especially OSS ones which are structured in more C or Rust like style with e.g. Types.cs if API surface is small - no need for a file per class or struct if declaring it takes 1-10 lines (especially with records and primary constructors).
- pensatoio 2y agoSo funny. I always felt the lack of exceptions in Go was one of its strongest selling points.