Live data from Hacker News

The Case for C# and .NET

chrlschn.medium.com

291–300 of 376 posts

Re: The Case for C# and .NET

#291
post #277
post #237

Earlier quoted context omitted.

Unfortunely not with same tooling level as C# and VB enjoy.

Rider has pretty decent F# support. Maybe not that many refactorings available, but it's IMHO worth it for the better language ;)

Only if we consider the language in itself, without the .NET ecosystem for GUI, databases, code generators,...

Where it is pretty much DYI.

Re: The Case for C# and .NET

#292

Earlier quoted context omitted.

And...how do both companies compare in what telemetry they're sucking out of devs?

Fair question, devs who do not want to share telemetry for the dotnet core SDK simply need to set an environment variable. VSCode has a similar setting in the options. Not sure about Visual Studio as I haven’t used it in a while. https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry

Opt out is ridiculous for a programming language. Do you really want to play security whack-a-mole with your development environment?

There are countless, better privacy respecting tools.

Re: The Case for C# and .NET

#293

Earlier quoted context omitted.

The difference between the shootout microbenchmarks and the TechEmpower benchmarks is that the former test computation-intensive tasks and the latter test an end-to-end web backend example. It tests how good the compiler is, how good the DB drivers are, how good the HTTP stack is. What's so good about MS ranking in the TechEmpower benchmarks is that it's the fastest full-featured "enterprise" framework. Frameworks li…

> The difference between the shootout microbenchmarks and the TechEmpower benchmarks is that the former test computation-intensive tasks and the latter test an end-to-end web backend example. That proves my point even further, because I don't develop anything remotely web-related, hence that performance scenario is completely moot for me. > What's so good about MS ranking in the TechEmpower benchmarks is that it's th…

> That proves my point even further, because I don't develop anything remotely web-related, hence that performance scenario is completely moot for me.

I hope you realize non-web development is a niche nowadays. So it's perfectly reasonable to prioritize .NET benchmarks that target ASP.NET Core web apps/APIs.

Re: The Case for C# and .NET

#294
post #167

Earlier quoted context omitted.

I'm not entitled to a best-in-class IDE experience, I'm just happy using one of the dozens of equivalent languages that do have them with an open community.

No language has been tied to an IDE since at least early 2000s. Microsofts own compilers are free to use. So no idea what you're talking about when you talk about "a language that doesn't rely on paying for an IDE". And the tools for most of the languages supported by the open community? The top, best-of-breed of these tools can barely do the bare minimum of refactoring and maybe symbol lookups. Even to this day you…

On the other hand, I have no idea what you're arguing about any more. The context is about using VS Code (or something else) with OmniSharp instead of VS and Rider; what does the bare minimum of being able to compile code have to do with it? It's almost like you're making my point: if you want to be productive with C#, you have to use proprietary tools; otherwise, all you can do is just compile your code!

> And, surprisingly, Jetbrains' IDEs are not expensive at all. And are several orders of magnitude more powerful than anything the "open community" has come up with.

This says more about the languages and ecosystems you're used to. Try out rust-analyzer and say that again!

Re: The Case for C# and .NET

#295
post #293

Earlier quoted context omitted.

> The difference between the shootout microbenchmarks and the TechEmpower benchmarks is that the former test computation-intensive tasks and the latter test an end-to-end web backend example. That proves my point even further, because I don't develop anything remotely web-related, hence that performance scenario is completely moot for me. > What's so good about MS ranking in the TechEmpower benchmarks is that it's th…

> That proves my point even further, because I don't develop anything remotely web-related, hence that performance scenario is completely moot for me. I hope you realize non-web development is a niche nowadays. So it's perfectly reasonable to prioritize .NET benchmarks that target ASP.NET Core web apps/APIs.

I hope you realize that web-development in my discipline is a niche nowadays. So, it's perfectly reasonable to prioritize bare metal and micro performance benchmarks that target naked performance, OS and GPU apps/APIs.

Our vantage points are different, and these different vantage points need not to see the complete ecosystem as a whole. It's too big to generalize from a single vantage point, and just because our view reveal us a little of something doesn't mean it is, in fact, little.

There's a whole invisible world out there, from DBs themselves to OS kernels to embedded platforms, and everything in between.

IOW, horses for courses.

Re: The Case for C# and .NET

#296

Earlier quoted context omitted.

I tried writing a simple crud api with asp.net, which should parse and respond json. It was the worst development experience I ever had while writing json apis. Validation? Not existent. OpenAPI/swagger documentation generation? Not existent. Then it also tried to force me into using MVC, while acting that it is express with its middlewares. I switched back to node.js with fastify and wrote my app in an hour. I reall…

I think that's the barrier with C# in general - the framework nature of it means there's a lot of "I don't know what I don't know" especially with ASP.NET which is quite large in scope. Don't get me wrong - that's the usual dev reaction when switching from their familiar language/tools to a new one but I don't think, at least historically, C#/ASP.NET made it as easy as it could of been. Which namespace do I open to i…

> Which namespace do I open to import the right extension method to register swagger generation

If you use the templates provided by .NET Command Line Interface or Visual Studio, you'll get this all baked in & setup.

VS also added a very nice feature where it suggests & imports popular packages if you type a method on a type that's well known. If you already have it added to your project but need a using statement in this file, it'll pick that up fast as well.

They've also improved their docs quite a bit from years ago with lots of good examples for common things.

Re: The Case for C# and .NET

#297
post #291
post #277

Earlier quoted context omitted.

Rider has pretty decent F# support. Maybe not that many refactorings available, but it's IMHO worth it for the better language ;)

Only if we consider the language in itself, without the .NET ecosystem for GUI, databases, code generators,... Where it is pretty much DYI.

Depending on what code generation you are doing you have alternatives. Biggest one being Type Providers which are arguably better than anything I've seen from source generators so far (which I found incredibly buggy when I used them, and at one point I had to reinstall visual studio it bugged out my environment so much when messing with writing my own).

And see above for database, Type Providers are great at least for SQL server, I think the sql one also works for PostGres but I never used it so not certain.

GUI is a mess last I knew though I agree.

Re: The Case for C# and .NET

#298
I have been teaching myself C# for the last two or three months (with the fantastic C# Player's Guide by RB Whitaker) and I have come to really enjoy working with the language. Discovering Properties, which combine fields and their accessor methods and can be auto-implemented and initialized, was the first moment I realized it might make my life a whole lot easier.

I'm not entirely sold on its use for desktop GUI development yet (will watch MAUI closely) but I am eager to jump into Blazor and see if I can start to remove JavaScript from my stack.

Re: The Case for C# and .NET

#299
post #293

Earlier quoted context omitted.

> The difference between the shootout microbenchmarks and the TechEmpower benchmarks is that the former test computation-intensive tasks and the latter test an end-to-end web backend example. That proves my point even further, because I don't develop anything remotely web-related, hence that performance scenario is completely moot for me. > What's so good about MS ranking in the TechEmpower benchmarks is that it's th…

> That proves my point even further, because I don't develop anything remotely web-related, hence that performance scenario is completely moot for me. I hope you realize non-web development is a niche nowadays. So it's perfectly reasonable to prioritize .NET benchmarks that target ASP.NET Core web apps/APIs.

> I hope you realize non-web development is a niche nowadays.

That's a terrible attitude. If you want a certain ecosystem to get a better rep, you have to be ready to talk with different communities, and accept their feedback.

Python is what it is largely because it can cater to a large number of these very different communities, which has ensured its long-term success. Compare with Ruby, which became effectively a web-only language and has since struggled to go anywhere.

Re: The Case for C# and .NET

#300

Earlier quoted context omitted.

I tried writing a simple crud api with asp.net, which should parse and respond json. It was the worst development experience I ever had while writing json apis. Validation? Not existent. OpenAPI/swagger documentation generation? Not existent. Then it also tried to force me into using MVC, while acting that it is express with its middlewares. I switched back to node.js with fastify and wrote my app in an hour. I reall…

As a C# developer I could say the same about my experience dealing with my first foray into [insert random language] and my attempt to develop [something with a non-trivial framework]. The issues you had could be attacked by navigating through this section of documentation, diving into the tutorial referenced in the beginning of the Overview section and the subsequent sections: https://docs.microsoft.com/en-us/aspnet…

That's true (and minimal APIs help a lot) but ASP.NET still has a real problem with too much magic.

For example, the secret incantations required to output a mere string as raw json mimetype or log incoming deserialization errors* are unintuitive and very labourious - see InvalidModelStateResponseFactory. Or that I had to create a custom output formatter to output raw json. Why? Sometimes I just want ASP.NET to get out of my way and it's not trivial to tell it to let go.

* For example, url?parameter=1 for a boolean parameter, which would have worked with .NET Framework but won't for .NET Core/.NET.

Post reply on HN