4 ms·

I was a long time Windows .NET Framework dev and switched to TypeScript + Node for a while because that's what all the startups were using and thoroughly enjoye

I was a long time Windows .NET Framework dev and switched to TypeScript + Node for a while because that's what all the startups were using and thoroughly enjoyed it. One thing that stood out to me in particular was just how fluid it is working with types in TS and also how good the unit testing story is on Node. Then switched back to .NET 6 when I joined another (rare) startup using C#/.NET for the backend. .NET now is a fantastic backend platform and I've been very pleasantly surprised. Part of it is that the base framework now feels really complete and well put together -- it feels "batteries included", but with the Duracell branded batteries and not the cheap knockoffs. The Entity Framework ORM didn't seem as competent in the .NET Framework days, but now EF Core is really, really good; highly performant and ergonomic to use. Part of it is that the multi-platform capabilities matured a lot since the 4.8 Framework days; the team I'm on is all macOS and we deploy to a mix of AWS t4g Arm64 instances. Part of it is that there's no longer a hard dependency on Visual Studio for most workloads; the team is a mix of VS Code and Rider. What really stood out to me after that stint with TS is how close TS and C# have become[0] and even more so with the more recent releases of C# 12. I think it's probably easier for teams that are working with TS + Node to add C#/.NET workloads than any other language/runtime like Go or Rust when there is a benefit to add multi-threading or get higher throughput from some backend system. [0] https://github.com/CharlieDigital/js-ts-csharp https://github.com/CharlieDigital/js-ts-csharp

can16358p 2y ago
Maybe a bit going off topic, but I'm down the exact same route: used .NET Standard + EF as a Windows guy up until around 4.8, then I started TS development (not for backend but because of switching focus on frontend, also simultaneously switching to Apple ecosystem/iOS dev etc. but still) and still love it. If I were to start a new backend project today, I'd be going with node.js/TS but because that's what I'm used to as language/framework, not because it's necessarily better. But I loved C#/.NET/VS/EF/Azure stack just as it too back in the days. Would you recommend going in with .NET Core/Vscode/EF Core on macOS today, if you were to start a fresh backend project?
- CharlieDigital 2y ago
  > Would you recommend going in with .NET Core/Vscode/EF Core on macOS today, if you were to start a fresh backend project? "It depends". I also do a lot of work with Firebase and there, I prefer doing backend using TypeScript and Node on Cloud Functions. The front-end integration is really tight and Firebase is designed to work that way as a stack. That said, I'll still develop pure back-end workloads (e.g. async jobs) alongside my Firebase stack using C# and deploy into Cloud Run Jobs. If you're building a pure backend, I'd choose .NET 8 with confidence because the overall DX feels better than Node to me. EF Core is really, really good; I prefer it to Prisma and the handful of alternatives on Node for relational DBs. I think .NET gives senior devs more "reach" (while still being approachable for junior devs) because it is multi-threaded[0], has source generators[1], interops with C++ easily, has deep optimization options for performance, and is generally a deeper platform than Node. Deployment into the serverless container runtimes is a breeze[2]. I also find myself patching CVEs and updating packages less in .NET land than in Node land (felt like it was a monthly and sometimes weekly chore in Node to be upgrading deps because of a security advisory). Things I miss from Node are the aforementioned unit testing, JS has better hot reload than .NET (serviceable, but not as good), discriminated unions (though its possible to patch that on with libraries like OneOf[3]), and Node has more package variety (while I think .NET has better package quality). [0] https://chrlschn.dev/blog/2024/05/need-for-speed-llms-beyond-openai-w-dotnet-sse-channels-llama3-fireworks-ai/ https://chrlschn.dev/blog/2024/05/need-for-speed-llms-beyond... [1] https://chrlschn.dev/blog/2023/08/dotnet-source-generators-dotnet-7/ https://chrlschn.dev/blog/2023/08/dotnet-source-generators-d... [2] https://www.youtube.com/watch?v=GlnEm7JyvyY https://www.youtube.com/watch?v=GlnEm7JyvyY [3] https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf
  - mst 2y ago
    I really should take EF Core apart and see how it all works before I next work on db layer code, I've stolen ideas from older versions before now but I suspect it deserves a deep dive on the current version. (JS db layer code always makes me sad and I always end up missing https://p3rl.org/DBIx::Class https://p3rl.org/DBIx::Class)

can16358p 2y ago

Maybe a bit going off topic, but I'm down the exact same route: used .NET Standard + EF as a Windows guy up until around 4.8, then I started TS development (not for backend but because of switching focus on frontend, also simultaneously switching to Apple ecosystem/iOS dev etc. but still) and still love it. If I were to start a new backend project today, I'd be going with node.js/TS but because that's what I'm used to as language/framework, not because it's necessarily better. But I loved C#/.NET/VS/EF/Azure stack just as it too back in the days. Would you recommend going in with .NET Core/Vscode/EF Core on macOS today, if you were to start a fresh backend project?

CharlieDigital 2y ago
> Would you recommend going in with .NET Core/Vscode/EF Core on macOS today, if you were to start a fresh backend project? "It depends". I also do a lot of work with Firebase and there, I prefer doing backend using TypeScript and Node on Cloud Functions. The front-end integration is really tight and Firebase is designed to work that way as a stack. That said, I'll still develop pure back-end workloads (e.g. async jobs) alongside my Firebase stack using C# and deploy into Cloud Run Jobs. If you're building a pure backend, I'd choose .NET 8 with confidence because the overall DX feels better than Node to me. EF Core is really, really good; I prefer it to Prisma and the handful of alternatives on Node for relational DBs. I think .NET gives senior devs more "reach" (while still being approachable for junior devs) because it is multi-threaded[0], has source generators[1], interops with C++ easily, has deep optimization options for performance, and is generally a deeper platform than Node. Deployment into the serverless container runtimes is a breeze[2]. I also find myself patching CVEs and updating packages less in .NET land than in Node land (felt like it was a monthly and sometimes weekly chore in Node to be upgrading deps because of a security advisory). Things I miss from Node are the aforementioned unit testing, JS has better hot reload than .NET (serviceable, but not as good), discriminated unions (though its possible to patch that on with libraries like OneOf[3]), and Node has more package variety (while I think .NET has better package quality). [0] https://chrlschn.dev/blog/2024/05/need-for-speed-llms-beyond-openai-w-dotnet-sse-channels-llama3-fireworks-ai/ https://chrlschn.dev/blog/2024/05/need-for-speed-llms-beyond... [1] https://chrlschn.dev/blog/2023/08/dotnet-source-generators-dotnet-7/ https://chrlschn.dev/blog/2023/08/dotnet-source-generators-d... [2] https://www.youtube.com/watch?v=GlnEm7JyvyY https://www.youtube.com/watch?v=GlnEm7JyvyY [3] https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf
- mst 2y ago
  I really should take EF Core apart and see how it all works before I next work on db layer code, I've stolen ideas from older versions before now but I suspect it deserves a deep dive on the current version. (JS db layer code always makes me sad and I always end up missing https://p3rl.org/DBIx::Class https://p3rl.org/DBIx::Class)