mrsmrtss

JavaScript is faster than C#

Are you joking? C# is in another leage, when we talk about performance.

That's not how TDD works. You test the whole chain and all the components with tests and you can move from top to bottom with TDD, it's actually how you should do it.

while if you wrote it exactly like Java, you'd probably end up with slower code.

That's not the case for some time already, at worst you get similar performance with Java and with a little effort you can get significantly better performance.

I don't get what the big problem is with function coloring. You basically only need async when doing IO, and you had better know when a function does it, or you may have a bad surprise at some point in the future.

Maybe startup time was a problem before AOT?

So you try to say that Java gets to be more semantically sound by making bad choices early on? That does not make sense. Those choices are very difficult fix today and many of them can't be fixed. Say what you want but semantically more sound Java won't be. And the boxing with C# unions can and will be addressed later, this was a deliberate choice by the team to bring unions earlier.

For almost 10 years now, we have not published anything .NET to the Windows platform. .NET is more performant on Linux today than Windows, and I would say development is also better there (using Rider). However, we do still have devs who prefer Windows. We have built many critical systems on .NET and they just work, so they may be boring to some of the folks who like to have more excitement from their systems.

As if C# is Windows only? Today C# runs also almost everywhere.

C# (.NET) would probably be the winner here. Go standard library is rather minimalistic compared to it.

Fun it is not.

    if err != nil

C# will have more advanced sum types this year, it's currently in preview.

Well, C# has more powerful pattern matching, only compiler exhaustiveness on types is missing today. In Java, sum types (sealed interfaces/classes) require all members to have the same parent, so they can be used only in very narrow cases.

Reified generics, value types, nullable reference types, LINQ are only some of the things that would give C# an edge in DevEx today.

If you work with old .NET Framework, then maybe I would agree. What kind of issues do you have in standard library or how they are only biting you? Nothing is perfect, but compared to other (popular) alternatives, C#/.NET is the best you can get today.

Exactly, we have had many interns with zero C# experience become fluent in a couple of months and those with prior TypeScript or Java experience get there even faster. A good IDE (like Rider) helps also.

Maybe this is why they retired Single Server PostgreSQL and are now offering only the new Azure Database for PostgreSQL (flexible server). Zero problem with the latter for us so far.

I see that it's fashionable to bash everything MS related in HN, but let's not pretend that the other major cloud providers don't have their own problems (e.g. https://www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f77... or https://blog.barrack.ai/google-gemini-api-key-vulnerability/). We have had a couple of critical services hosted on Azure over ten years already, call me lucky, but we haven't had any major incidents. That said, the AI Foundry side is broken garbage at the moment, but so is also AI stuff from other providers.

Fully agree with this! I think today .NET is probably the most batteries included platform you can get. This means that even if you use third-party libraries, these typically depend only on first-party dependencies, making it much less likely for something shady to sneak in.

Autoboxing is more a Java problem mainly because of type erasure with generics. C# has "proper" generics and no hidden boxing is occuring there.

I think that goes for any major cloud provider, not only AWS. But nothing is free, you pay a hefty premium to get this (compared to plain infra providers like Hetzner for example).

Add WarningsAsErrors for prject and you are done.

I had the exact same thoughts reading it.

True, it's in preview currently, but actually .NET is already very efficient with async today also - https://hez2010.github.io/async-runtimes-benchmarks-2024/ (.NET9 tested here).

In .NET 11 C# async management moved to the runtime, mostly eliminating heap allocations and also bringing clean stack traces. You really only need to think about ConfigureAwait(false) when building shared libraries or dealing with UI frameworks (even there you mostly don't need it).

No, it's not, it's a SQL builder.

I favor a more functional style of programming and C# ends up making everything 5 times more verbose than Kotlin.

As if you can't program C# functional style.

Care to elaborate what problems you have with .NET package manager (Nuget) and build process? I think having a single way of doing things a is in itself a big bonus compared to the situation in Java (Maven vs Gradle).

.NET, VueJS, and PostgreSQL are also my preferred stack today. For back-end development, C# .NET is a super productive and performant stack, and it would be foolish to disregard it.

The Benchmarks Game has some highly optimized implementations and is not a good representation of typical code. Some languages allow you to go a lot lower than others if needed, which adds verbosity, that does not mean typical code must be verbose. There are things possible in C# that you just can't do in Java, for example. That does not mean typical Java code is more concise than C#. On the contrary, typical C# would be probably considerably more "dense".

So giving a gun to someone mentally challanged is not dangerous for you too?