[sshine]

I almost always pick Rust. Recently I wrote a plugin for something that was written in Go. I could have used Rust, but Go for one felt right because if the thing turned out well, others would surely find more value in having one toolchain.

The main reason is that you’re capable of reading it if you need to. And the recipient ecosystem expects a language. That’s why some data science communities pick R, MatLab, Julia, Python or Mojo not depending on what’s superior tech, but what their peers speak.

[josh-sematic]

What peers are speaking Mojo? I’m not aware of any place it’s penetrated enough to be a “lingua Franca”

[CharlieDigital]

C# feels kinda nice because it's a good balance.

Very good static typing, Roslyn analyzers, good tooling and decent hot reload (for a compiled language), really good ORM (EF Core) that implements UoW and reduces a lot of the need for transaction management (simplifying the code), flexible enough and fast enough for various kinds of use cases.

Source generators are underrated as well since they can make the code very terse and legible by generating a lot of standard boilerplate.

[alexjplant]

I've written this before, but C# is a great language held back by its culture. I'd say that 80% of C# shops I've seen used it because they were started in the late 00s by some IT guy with a surplus HP server and a dream whose whole world was Microsoft products. They were staffed by people with little knowledge of OSS products who self-identify as ".NET developers" instead of software engineers. Almost invariably they seem to have some gnarly legacy monolith that everybody is slowly chipping away at while old-timers continue deploying .NET services to IIS running on Azure VMs because it's a small evolution of what they've been doing for the better part of 20 years.

In the interest of fairness the San Francisco version of this is also a thing: a giant, untyped ball of Rails spaghetti from the same period running on Heroku that everybody has Stockholm Syndrome'd their way into loving because of Ruby's elegance and beauty. The burden is merely shifted from a large Microsoft to a series of small SaaS companies :-)

Exceptions to this rule exist (hence my "80%") and modern .NET is lovely but it seems that the non-Java/Python mindshare is now taken up by the Golangs and Rusts of the world. It's a true shame since I do love C# for basically being a better Java.

[DeathArrow]

Hmm, I am working on C# microservices based apps since 6 years ago. And I always deployed on cloud using Linux, usually in Kubernetes. I used Google Cloud and AWS beside Azure.

The whole stack is open source, Kubernetes, Docker, Hashicorp tools, Postgres, Redis, MongoDB, RabbitMQ, NATS, Kafka, Prometheus, Elastic Search, Kibana, Grafana and so on and so forth.

[DeathArrow]

>C# feels kinda nice because it's a good balance.

From my experience it's awesome to write C# with AI. But both Opus and GLM usually one shot the modification to the file so I didn't experienced cases lately where AI had to fix compile errors. True, I gave the AI agents the lsp for C#, so maybe that helps.

[pier25]

Yeah C# is fantastic. I also love EF.

I stopped using it because overall it feels like Microsoft has lost the plot with .NET.

[stephbook]

What I hate about .NET is the atrocious naming.

Net Core, Net Framework, Net Common Core, .NET..

And God forbid any of these frameworks ever expose what they are in a config file. You start a project, hand it to a colleague and he can't figure out whether it's Framework or Core by looking at the files. You Google and are immediately bombarded by 15 year old threads.

[Kwpolska]

If you start a project with .NET Framework in 2026, you're doing it wrong, plain and simple.

And the .csproj files do tell you which .NET they are.

<TargetFrameworkVersion>v4.</TargetFrameworkVersion> or <TargetFramework>net4</TargetFramework> is the old framework. Also, if the file is an unreadable mess listing all .cs files, it's generally .NET Framework.

<TargetFramework>netstandard2.0</TargetFramework> is .NET Standard 2.0, which means this library can be consumed from either Framework or modern .NET.

And finally, <TargetFramework>netX.0</TargetFramework> (X >= 5) is the modern .NET.

[CharlieDigital]

Forget about the old stuff; just use .NET 10.

It's really, really good now. DX is fantastic. Yes, the hot-reload will probably never match that of interpreted languages, but for a compiled language, it is good.

File-based apps are easy to get started with: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...

EF is solid and proven. Easy, low-lift type safety end-to-end from DB up with very good perf.

Tooling is dead simple and consistent; `dotnet build`, `dotnet test`, `dotnet run`, `dotnet ef database update`, `dotnet ef migrations add`, `dotnet tool restore`. No mix of build tools and toolchains.

[pier25]

Never tried .NET 10 but hot-reload was garbage with .NET 9 and 8.

It failed very often and you had to manually restart the dev process. Even when it worked, it was no where as fast as eg using Bun with TS.

Also Minimal APIs didn't have feature parity vs MVC even 4 years after release which is quite frankly insane. I hear in .NET 10 they've finally added some validation. Not sure how it compares to something like FluentValidation which still is one of the most downloaded nuget packages.

[CharlieDigital]

    > It failed very often and you had to manually restart the dev process. Even when it worked, it was no where as fast as eg using Bun with TS

Really depends on what you're doing. For run of the mill APIs, it works pretty flawlessly with `--non-interactive` and just auto-restarts when it needs to, hot reloads when it can (again, I'm not comparing this to interpreted languages and runtimes; the constraints are just different).

I have a clip of this in action with .NET 9 generating OpenAPI contracts and TS bindings at the top of this README: https://github.com/CharlieDigital/dn9-openapi-codegen/blob/m...

    > Also Minimal APIs didn't have feature parity vs MVC even 4 years after release which is quite frankly insane

Why does it need to? That's like saying express should have feature parity with Nest.js; they have different use cases in my view :shrug:

[DeathArrow]

Most web projects use JSON files for configuration. There are also some XML files for project configuration. If anything, you can run into too much configuration files.