The Case for C# and .NET | Hacker News Reader

The Case for C# and .NET

chrlschn.medium.com

314 pointsgreenSunglass371 comments

I also think that C# and .NET are awesome. Especially latest releases dotnet 6 and upcoming 7 have a ton of new things to be even more productive.

I like the fact, that you can develop command line apps, Web APIs, Desktop Apps and smartphone apps all with the same toolset, including the fact that deployment is possible on nearly every major platform for every major platform (except iOS and macOS Apps, as always only on macOS). Even systems programming and AOT is doable or full featured static deployment is possible integrating a small runtime into a single binary.

And boy is .NET fast...

This facts made Golang pretty interesting to me, but what I did not like here is the lack of a usable cross platform Plugin-Loader technology, most of the stuff has to be monolithic, then the module management and some of the missing concepts (like generics, which is also now available in go).

The sheer amount of concepts in C# is overwhelming (from basics like Generics to less common ones like Extension-Methods, operator overloading, etc.).

I don't like Visual Studio as IDE, but VS Code is an acceptable alternative tool, although I personally prefer the non-free JetBrains Rider.

Nuget package manager also has it's caveats, e.g. that the official repo can only "unlist" packages, not delete them or that the publish times sometimes have horrible delays, but that's also still acceptable, since you can use the github package registry or bring your own to overcome these issues.

Technologies on my todo list include getting into MAUI (a cross platform UI stack) combined with Blazor[1], which can use Web Components in native UI apps and develop TRULY cross platform (Web, Desktop AND Mobile with the same codebase). Like electron, but without the browser dependency due to native integration.

Although everything is tied pretty tight to Microsoft, there is a huge open source community developing cross platform libraries, that are easy to use. Even though i find that microsoft has often made strange decisions in the past, the current state is clearly a recommendation to have a look.

https://www.youtube.com/watch?v=2eIsQ3Pm2bE

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 really like C# for cli and windows desktop applications, but I probably won’t touch it for the web in the next few years.

Validation and Swagger/OpenAPI have been available for a long time and well documented. I don't know what resources you used to learn ASP.NET, but they failed you.

All the way back to .NET Framework 4.5 at very least (2012).

Looks like I was using the wrong ASP.NET features! Route-to-code does not support OpenAPI.

https://docs.microsoft.com/en-us/aspnet/core/web-api/route-t...

FluentValidation and Swashbuckle are two great libraries for the tasks you referenced. This is a good enough reference repository should your curiosity be piqued again in the future: https://github.com/jasontaylordev/CleanArchitecture

Yep. The problem that the parent commenter had is distinguishing between "Not existent" i.e. the tool that I am trying out sucks; and "I don't know how to use this tool yet" - a completely normal part of the learning experience.

Failing to find the differences between them will impede learning in general.

You don’t need to use MVC either since minimal APIs are a thing now

The issue here is that you didn't know what you were doing (which is completely normal when trying a new language)

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/core/web-api/?view=a.... This is not necessarily in defense of c# and dotnet, but this reads like you barely spent any time trying to digest the documentation.

I’ve been a C# developer for a decade and I still think it’s hopelessly convoluted for getting very simple things up and running. Maybe there is something wrong with me, but it’s just not intuitive to me and it has frankly never been. I do think the move to core and then core to .net has improved things, but it’s still a really weird and way of doing things compared to other languages that I have worked with, and most of the “boiler plate projects” are very rarely useful, so why are they there?

Then once you need to go beyond the standard libraries it becomes a nightmare to deal with. In some cases, like extending the AD libraries, it’s sort of easy to extend classes with methods but the documentation on how to do so tends to assume a lot of domain knowledge. In other cases like if EF’s standard functionality isn’t enough for you, or you need to deal with weirdly formatted XML or non standard SOAP requests (don’t ask) it can be such a nightmare that it’s sometimes easier to write a micro-service in another language to do the “translation”.

I think it speaks of a language that doesn’t see too much use by its own creators. I may be wrong on that, but having build a lot of things for Azure, Typescript has often felt more like a first class citizen than C#. Obviously not for everything, far from it, but sometimes and those sometimes are enough to make C# troublesome because unlike things like typescript that are great second class citizens in the Microsoft ecosystem, C# isn’t. It either fits really well or you have to fight it.

I wholly disagree as a person who worked in C#/.NET for over 15 years and recently waded into Node/JS/TS dev. C# and .NET are hands down the easiest platform to start on.

In my decade around management that was not my experience with onboarding new people.

Maybe that is because we didn’t have a fascist linter for C# the way we do with Typescript, but it’s always been much, much, harder to get people to make “good” C# code in my experience. It hasn’t been hard to have the build things in C#, but it’s been hard to get people to build things the same way so that they can work on each others code flawlessly. So hard that I would never again consider using resources on it until developers drop significantly in pay, which isn’t likely to happen until I’m retired, if ever.

I wonder if it has to do with regional differences. I’m Danish, everyone (there are odd cases, but it’s more “everyone” than “almost everyone”) here has a CS degree and often they’ve been taught Java, sometimes C# but poorly, while obtaining it.

> I’ve been a C# developer for a decade and I still think it’s hopelessly convoluted for getting very simple things up and running.

For me, fsharp interactive is one of the best prototyping experience I have ever experienced.

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.

You are actually right. Today I opened the documentation again: https://docs.microsoft.com/en-us/aspnet/core/web-api/route-t...

And it says right at the bottom, that OpenAPI and model binding is not supported in their route to code feature.

I initially googled how to create a simple json api, and that’s the documentation which I found. Looks really easy in the beginning, but after you’re done with your routes, you’ll read at the end of the documentation, that OpenAPI generation, model binding etc is not supported. I blame that the guide‘s title is misleading and - of course - that I should’ve read till the end before actually following any step of that tutorial.

Well, while I understand, what you are trying to say (a simple crud web api should be easy to accomplish), I think that you were just overwhelmed by amount of possibilities, tutorials and outdated information, because C# / .NET is evolving fast.

That said, you may take a look at my small very early state pet project `tonehub`[1], which can be seen as pretty modern CRUD Web API in 2022, utilizing swashbuckle for OpenAPI, JsonApiDotNet for CRUD, Entity Framework 6 for Database, HostedServices for background tasks and some other nice concepts (DI / IoC, Options Pattern, FileStreams, etc.). I could also use SignalR for WebSockets / Realtime, integrated OpenID/OAUTH2 Authentication, FluentValidation for validation, Api Versioning and much more.

I've never accompilished something like this with this small amount of code...

[1] https://github.com/sandreas/tonehub

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 import the right extension method to register swagger generation? How do I configure it? All that stuff IS existent actually and having worked with both in my current role the .NET version eventually ends up being a "just works" experience. Its just hard to approach and integrate if you don't already know the "patterns" and the libraries. Sadly there's a lot to learn compared to say Fastify for a basic working app. However it is very configurable and flexible. I've seen the same reaction from dev's to the Spring Framework as well - its just feels bloated for a lack of a better term to people coming from JS.

As per another comment after having seen JS devs switch to F# for very large professional application and not wanting to go back I feel its fine for web. YMMV.

> 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.

These are nice but:

- Templates are no substitute for intuitive and minimal code for a number of reasons. (e.g. how to extend, how to customize, confidence that it isn't brittle if I change one thing, etc etc). If a template doesn't have the exact variation you want (e.g. a faster logging library) the learning curve is very high for a newcomer .NET dev. NOTE: I think this applies to some other OO languages too.

- Suggesting popular packages and namespaces is a great tooling improvement. But it could also imply a closed wall garden. The fact that other non C#/Java like languages don't have this problem even with something as minimal as VS Code as your IDE shows that the tooling is trying to cover over a language and/or library problem. With the Java/C#/other old OO lang workflow you need the knowledge you need to use the library itself (convention based, which class, which extension method, which namespace for that object to configure this feature, startup class conventions, etc). It isn't discoverable even with the packages imported. Remember just getting Serilog working in new ASP.Core and it taking a day or so with all the packages, config, etc etc if you don't already know what you are doing.

I like the improved docs. But fundamentally simplification/minimization is better. I think the dev workflow that means I don't need these tooling improvements is still a better experience. I like .NET, but I do understand when using other languages they seem to not have these issues despite not having the uber tooling that C# has. They don't have package suggestions, they barely even have auto complete yet the library design feels a lot more intuitive.

I can look up say a Fastify, Golang, even some F# examples with something like Giraffe and get a web app quickly with little code and no convention magic with everything being explicit yet concise. No fancy attributes I need to remember, no conventions in my startup classes I need to understand if any customisation, even dep injection is something to learn from people coming from some other platforms rather than just standard library calls composed together.

I actually like the .NET platform, don't get me wrong, I do think it is one of the best web platforms right now. Its more intuitive than Spring/Java as a comparison but that isn't saying much IMO. For newcomers I think the user experience to newcomers who are used to a lot less ceremony could be improved further. My first suggestion would be less "developer headspace required" to get started. On a personal note I think natural F# code tends to favor this from the teams I've been in but can't put my exact finger on a reason as to why - it feels more like coding Go/JS to me at least than C#.

I'm curious who does this well? I've personally not found any specific language or framework that is better than others unless you're using their preferred libraries. At that point it depends more on the library authors than the base framework.

For newcomers, I would say the best user experience (no matter language/framework) is provided by code hinting such as GitHub GitLens & competitors do. If I'm using an unfamiliar framework/language it's great at suggesting what I might want without me having to search.

You might really like the new .NET minimal APIs that are being built for web development. They're very similar to a Node.JS style of API.

In regards to logging specifically, I've found swapping logging tools fairly easy & straightforward as far as adding the logging in the code base. If there has been anything challenging it's been outside the code base & setting up the infrastructure or learning the logging's reporting tools. I'm curious what was challenging for .NET with you. It's usually as simple as using Ilogger no matter the tool & writing a few lines in the program.cs file.

I think for swagger documentation you install the swashbuckle nuget package and then add these three lines

services.AddSwaggerGen();

app.UseSwagger();

app.UseSwaggerUI();

Personally, I'd rather generate documentation at compile time.

Which you can do, by adding a post build step.

I do it during tests.

Since I'm already spawning a TestHost and trying out various API calls, one of these tests basically does "curl $host/openapi/openapi.json | diff ./docs/openapi.json". If it spots a change and fails the test, I check that the difference is expected, and if so I temporarily enable and run a different "test" which actually writes the updated file.

ASP.NET configuration is one of the most arcane parts of .NET that I don't like. You have to perform the incantation thrice: add package reference, add service reference, invoke the builder extension. And there's the right order and the wrong order of invocations, and if you pick the wrong one, your app silently won't work correctly.

Arcane? What did you expect? Add a package and magically everything works? If you make it work by just adding a reference its “too much magic”, if you make it so people write everything “it’s boilerplate” and if you do something in between “its arcane”.

Totally opposite experience for me. C# + .NET ASP core Web Api framework + Swashbuckle + FluentValidation does out of the box what I still haven't seen a good solution for in the NodeJs world (which is the one I'm in now).

NestJS seems to hit the sweet spot for these. I'd add a proper Result type (from fp-ts) to get better error handling (than try-catch everywhere) and you're good to go.

We've just started looking into that, but the amount of existing raw JS+express we have means adopting something like NestJS is going to be a huge undertaking. What slightly baffles me is that at no point did anyone seem to stop and think if there shouldn't be a better way...

What do you actually mean by "non-existent"? The asp.net framework includes more functionality by default with its standard libraries than just about anything else.

> It was the worst development experience I ever had while writing json apis. Validation? Not existent. OpenAPI/swagger documentation generation? Not existent.

They are existent and good.

I'm not sure which learning material you used back then but this seems more like an unfortunate accident.

With .NET 6 SDK, 'dotnet new webapi' will give you a template project that does everything you listed save for extended validation logic which you can easily add with 'FluentValidation'.

In addition, to run ASP.NET Core nowadays you only need:

  var builder = WebApplication.CreateBuilder();
  var app = builder.Build();
  app.MapGet("/posts/{name}", ([FromRoute] string name) => /* controller logic, classes will be serialized as JSON */);
  await app.RunAsync("http://localhost:8080");

But Node.js doesn't ship with those features built-in either?

You did something wrong.

  dotnet new webapi -minimal

This will scaffold a project which is more or less the exact same as Flask, Express, or any other "easy" framework.

OpenAPI output is built-in, but tooling for development does require a bit of knowledge (agree that Microsoft would benefit from making this work out of the box).

A small repo here showing how to connect OpenAPI and front-end TypeScript client generation: https://github.com/CharlieDigital/dotnet6-openapi

> I switched back to node.js with fastify and wrote my app in an hour.

Of course you did. You're on familiar ground.

Personally I'm also familiar with .Net and could do the same in that stack in that timeframe too. Like with many things worth doing, it requires a time investment to reach that point.

Having said that, .Net APIs support JSON request/response out of the box, validation is available on the models in seconds using a powerful set of attribute annotations, and Swagger is also built in out of the box. And API projects can seem similar to MVC ones as they use the same framework and libraries, but whilst the out of the box APIs have controllers they don't have views.

So to repeat, it's down to familiarity.

Edit: For clarity this is not a criticism. I fully understand why these things may not be obvious up front. Both the validation attributes and the Swagger URL for the default support are not obvious to the newcomer.

I've been a .NET developer professionally for seven and a half years. Rider is the way to go. Visual Studio has improved dramatically over the last decade or so, but Rider is still way ahead of it on code search/discovery, performance, and general user experience. I did a tech talk at my company where I demoed Rider vs Visual Studio 2019 performance on our bigger projects... it was embarrassing for VS. VS 2022 was substantially better on performance, but also crashed during the demo.

I'd love to watch that talk if you're comfortable posting a link

Unfortunately, because it contains proprietary source, I cannot :(.

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.

Rider does not have a community edition unlike IDEA. It was created due to a combined threat of VS Code and Roslyn and is the reason ReSharper is almost neglected these days.

ReSharper isn't a heavy focus because it's not worth it anymore. To get the same performance as other tools they'd need to throw out a ton of work and rewrite it for Roslyn. With Rider, they get to continue to use their existing ReSharper codebase to power it.

They don't forget to charge same (even increased) fee for minimal updates, though.

Visual Studio is great, but also one of the most broken bits of software I've had to use.

Was that comparison both with or without ReSharper? Were you comparing fresh installs with no plugins on both sides?

I'd love to use Rider on Linux or even Windows. Sadly the lack of .NET hot reload on Linux and Rider's issues with hot reload on Windows are what keep me on Visual Studio. (Rider's implementation of hot reload doesn't support assemblies loaded at runtime yet, which my application depends on).

It's sad that the time saved with Visual Studio's hot reload alone seems to outweigh the (massive) performance gains from using Rider, given that I have to restart VS from its memory leaks multiple times a day or it will slow to a crawl. Omnisharp isn't performant or reliable enough for daily use, either. The current state of .NET tooling leaves me unsatisfied.

I’m amazed hot reload works consistently enough for you to be able to use it.

> The sheer amount of concepts in C# is overwhelming

Agreed. But F# is one of the best designed languages around.

I don't disagree, and I love F# but I think it owes a lot of that to OCaml. That said, since we're talking about C#, F# and VS Code I'm gonna vent a little about something that arises when you use all three :D

If you open a C# project in VS Code when the "Ionide" extension (basically the F# extension for VS Code) is installed then the extension thinks it's a F# project and will open some F# stuff after a few seconds (or prompt you to setup some F# stuff in its gitignore). The root cause has been identified (plugin activates when it sees a ".sln" file), a PR has been opened and rejected with no mention as to why (https://github.com/ionide/ionide-vscode-fsharp/pull/1401) and the developers behind it are frustratingly non-communicative about it, closing issues about it (https://github.com/ionide/ionide-vscode-fsharp/issues/1701), they're not present in the discussion (https://github.com/ionide/ionide-vscode-fsharp/discussions/1...). Usual rules about OSS maintainers apply, they don't technically owe us users anything, we should be patient and respectful etc ... but man it is truly bizarre to be ignored or ghosted like this.

I still need to get into OCaml. I of course know bits by virtue of having used F# and SML, but OCaml definitely has its own unique features. For F#, I appreciate how well it sits upon the host VM for the CLR and .NET. It just integrates almost seamlessly while still being a functional-first ML. When I use F#, it's by far the easiest code I write. I find myself just writing out the domain and boom, I got a working program. Recently, I wrote some bindings for a C/C++ DLL, and F# really made that easy. It's the easiest time I've ever had creating such bindings in a language.

For the Ionide stuff, I agree. I don't use it, even though I use Visual Studio Code for other languages, and am happy enough with Visual Studio on Windows and Visual Studio for Mac on macOS.

About the 'dependency problem':

It's not as bad as in npm with node_modules, because .NET provides a lot of base functionality in the standard library.

But when you start to use multiple nuget packages, sooner or later you will also enter dependency hell, where managing versions and updates of nuget packages gets very painful.

All in all we have to reference about 10 external libraries. The visual studio nuget package manager started to be frustrating if you need to manage those dependencies in multiple solutions. We therefore switched to Central Package Management [1], but then you realize, that you're just shifting the problem around. Now we have to put the whole dependency tree into the file 'Directory.Packages.props' and have to manage the version of 140 libraries. If there are version conflicts, we force nuget to use the latest version and just hope for the best.

Managing versions of dependencies and dependencies of dependencies is a major pain, but it's an ubiquous pain all programming environments share. And no, .NET won't relieve you from that.

[1] https://docs.microsoft.com/en-us/nuget/consume-packages/cent...

I'm not sure if it will help in your scenario, but faced with a similar problem (~80 project solution, mixed c#/f#, with varying dependencies), I found success with Paket (https://github.com/fsprojects/Paket)

It is much more prevalent in the f# community (at this point `dotnet restore` is a perfectly fine default until you hit trouble), but isn't limited to just being applied there.

Yeah this is probably one of the biggest pain points, but modern tooling is really helping to the tide on this. Dependency management is never fun in any language, and .NET has some quirks which make it a challenge as you say. I switched to .NET from java about 5 years ago now and I'm pretty I !are the switch as .NET just keeps getting better. Dependency management is one of the last pieces of the puzzle to really solve for in terms of getting a much better experience. That said if you're starting a brand new .NET project today you can set up your CI/CD pipelines to do Continuous Deployment and use Renovate to automatically upgrade your dependencies and merge if your tests are green. In addition the trend is for smaller codebases these days which makes it far easier to upgrade major versions of dependencies due to much smaller scope of breaking changes. I think those two things in combination eliminate some of the pain we've all felt with not being able to upgrade several years out of date dependencies in huge monolithic codebases. I'm pretty excited for the future of .NET to be honest.

Did you really mean only 10 external libraries? If you'd said 100 I could understand - I hit a version conflict issue in a recent project on adding what was probably package #60 or so, but solved it easily enough after a bit of googling. And we knew we were using a lot of quite old packages (including .NET 2.1 EF, because of a rare breaking change they introduced with 3.0 that we didn't have a good solution for).

Technically just 2 libs are enough to produce the issue...

Our dev loop playbook at work has an advice to never touch Visual Studio's nuget package manager haha.

Instead, dotnet CLI + VS Codes find+replace does a very good job at managing dependencies. It has never been a pain and on project build, all imported version will be consolidated to a single one anyway.

> I don't like Visual Studio as IDE, but VS Code is an acceptable alternative tool, although I personally prefer the non-free JetBrains Rider.

I've used Visual Studio for 20 years now, and while the tooling has come a long way, I'm starting to feel like MS and the community are abandoning it for VS Code. I don't mind VS code, but unfortunately the stack I'm working in (Dynamics 365) requires plugins for Visual Studio that tend to lag behind the release cycle of Visual Studio versions by a few years. I use Rider for .net core projects on my mac and it's fantastic.

In fact my biggest criticism of my day to day job is Microsoft's support for this incredibly enterprisey framework I have to work in.

Hey fellow Dynamics 365 (CRM?) developer.

I see they move in VSCode direction with tools like Power Platform CLI [1], power platform tools extension [2]. PCF (PowerAps Component framework) enabling to develop UI components in frontend framework-of-choice... however none of that is available (yet?) for On-Premise deployment so we're 2nd class citizens. Because of that, haven't been able to play with this and try out so don't know how far that tooling goes.

As a platform, I really like it. Sane, consistent (except some very early stuff there), the backend extensibility - thumbs up for that.

[1] https://docs.microsoft.com/en-us/power-platform/developer/cl...

[2] https://marketplace.visualstudio.com/items?itemName=microsof...

F&O, sadly...

F&O would be former AX? That seems highly rewarded field. I know it only from SQL point of view - It helped grow my SQL skills when SQL would be brought to it's knees (along with the business) due to skewed data distribution and occasional query plan invalidation.

Yep, it's the replacement for AX. I can't say I love working in it, but the clients are massive and as such, it can be a rewarding financial choice. The tooling is poor and the APIs are a bit difficult but it's made for some fun workarounds :)

> that the official repo can only "unlist" packages, not delete them or that the publish times sometimes have horrible delays

It's to avoid the npm left-pad problem. nuget.org packages are idempotent.

For the publish times, I found out you can cut it in more than half if you tell nuget to ignore caches.

I know... but sometimes it is a bad thing for indie hackers testing around :-)

Draft releases would be awesome.

You don't have to use Nuget.org, it's just the public community version of a Nuget package repo.

You can use your own private repos like MyGet[1] or Github Packages [2].

1. https://www.myget.org/ 2. https://docs.github.com/en/packages/working-with-a-github-pa...

Yeah I know all this, you can even use BaGet[1] symbol server to cache or manage private dependencies in an enterprise network. That is not the point... I think that the most used tool / platform should provide more flexibility for non-enterprise or less expierienced developers.

No offense, I like nuget, but I recently made a typo and checked in 0.0.23 instead of 0.0.2. Now, everytime I add a dependency that is < 0.0.23 to a project, that has not been synchronized / validated yet (the other problem I described), it automatically takes the best match, which is 0.0.23 assuming to be the newest package, even if unlisted.

I also burned a 1.0.0 because of a failing script like that... not really bad, but annoying...

https://github.com/loic-sharma/BaGet

Why not just setup a local feed?

FYI Nuget also work with folders.

Drop nupkg in a folder, use it as a source, you now have a "feed".

Idempotent, in which way? Do you perhaps mean immutable?

Yes, sorry, I meant immutable, not idempotent.

Just developed something using MAUI's predecessor Xamarin.Forms

It was perfect and exactly what I wanted. I had experience with XAML and MVVM thanks to Silverlight and WPF, so that explains at least some of why it was such a breeze. But it is way nicer than coding for the web, and I've done my fair share of that.

I was able to port over most of the code to MAUI easily, except for the missing controls. But MAUI is very exciting overall, and I look forward to using it more. After a map control is released I will fully port my app.

This thread shows there is still a large amount of FUD around .NET and it’s community.

Folks here still think it’s Windows-only and comparable to Java. Yet latest TechEmpower benchmarks shows .net running on Linux and being faster than Go, Python, Node, and Rust.

The dev experience is Windows only, STILL:

https://news.ycombinator.com/reply?id=32220935&goto=item%3Fi...

(Also the benchmarks are a cheat, look at the source code of C# vs the source code of Go or Java)

I use Rider on my Ubuntu machine and the dev experience for me, is even better than using VS2022 on Windows.

Every benchmark is a cheat and not a real-world problem.

I also thought their benchmark is a cheat. But it is not. It is testing exactly what the benchmark was testing in that scenario. That is why TechEmpower Benchmark suite is so powerful. It uses different web server scenarios (connection, JSON parsing, database connections, ...). The different test case implementation .NET and others have are making sure no other factor is influencing this. For example: when you benchmark connections why dealing with MVC, validation and database connections.

It is not .NET who cheats, it is the others who do not properly isolate the tested performance aspect.

And to make the comparison a bit more real and day-to-day applicable, you need to pick the right framework configuration (like aspcore-mw @ 80% / aspcore-mvc @ 37%) and compare with other reasonable scenarios (like express @ 1% / spring @ 2% / quarkus @ 8%). Both are then far of the top 10 ten list but still comparable. The top 10 combinations are for cases where developer productivity does not matter but throughput is the key (e.g. a DoH resolver or a system like a Cache / Database).

So, either way, the benchmark is not an apples-to-apples comparison between frameworks?

Until Microsoft can match the dev experience of writing front and backend in typescript with pnpm, I’m not touching the dotnet/nuget cli(s) with a 10-ft poll. If you want to write C# just write go

> If you want to write C# just write go

I don't get this. If you want to write C#, write C#. If you want to write Go, just write Go.

Go is a great language because of its simplicity and ecosystem, has lots of useful things in the standard library, has pretty good runtime performance and also compiles to static executables easily (which is especially useful for projects like Nomad). It's both a good fit for web development, as well as writing smaller or larger utilities. Honestly, its packaging situation is leaps and bounds ahead of something like Python, so I predict great future for it in DevOps too.

C# is a more advanced language with a rich history and a lot of the functionality for web development in particular coming as first party packages. Some of that historical baggage weighs it down and the complexity can be annoying, but ASP.NET Core, EF Core, Kestrel and many other components are great. Plus, running on *nix is good, even though the single executable/runtime/deployment situation isn't quite as easy as with Go.

Write code in whatever technologies work for you. My caveat to add would be that I'd (almost) always develop front end and back end separately, since the React/Angular/Vue webapp really shouldn't care much about what technologies are behind the APIs. Of course, being able to use a single language for both FE and BE development is also a worthwhile approach!

> I don’t get this

That’s because my argument has nothing to do with the language itself but you still felt compelled to write an essay. I’m saying the modern Linux-based tooling, ecosystem, and devex of C# is inferior to so many other choices.

I don't get it because the claim that "If you want to write code in language X, just use language Y" doesn't vibe well with me. It feels needlessly dismissive somehow.

Hence the exploration of the good things about each of the languages and genuine reasons why people might enjoy using them for slightly different use cases.

At the end of the day, everyone can make that choice for themselves, unless their org makes it for them.

The performance really is astonishing in many areas now.

The part that keeps me hooked is the fact that I can stand up something capable of producing those numbers in 30 lines of code using 1st party dependencies only. I can then have a full prototype to demo by late afternoon, again having antagonized over exactly zero 3rd parties.

For me, the performance numbers aren’t just about speed while in production. It’s also about speed to production. Having the confidence that it’s almost certainly going to be fast enough by default keeps me from worrying about optimizing random bullshit throughout.

I still haven’t seen anything that comes remotely close to the combination of speed and stability offered here. I do some pretty nasty things with the runtime and it just copes. GC seems like pure magic now too. I continue to avoid things like LOH allocations with streams, but I don’t worry about it like I used to in the 4.x days.

If you like the productivity, just wait till you try Rails.

Rails is still a thing in 2022?

Old habits die hard I guess. Some languages just need to buy a coffin already

LOL. That's good. Thanks for that.

PHP is still a thing since time immemorial… And will remain there for a long time to come. (Seems like they made quite some improvements in the latest iterations as well.)

> If you like the productivity, just wait till you try Rails.

I like Rails (vintage, Rails 5). Unfortunately DotNet and EF combined now have virtually the same productivity but with massively better performance. Which is a shame as Ruby is a great language.

I’ve tried very hard to use EF. If you think it’s equivalent to the productivity of ActiveRecord, well… more power to you, I guess.

And that's why there are so many ecosystems - to cover the variety of tastes and preferences.

I think the end game may be one unique ecosystem per developer (like with JS frameworks).

Coming from Java, Go, and Javascript, C#/.net just plain sucks. Things that should be simple, e.g. Collections APIs.. aren't. I stopped trying after this realization.

I preferred the C# from 15 years ago compared to whatever is going on over there at present. If you're already indoctrinated into the ecosystem, I'm sure it's fine. Otherwise, buckle up - things are going to get choppy.

How are collections in C# worse than in Go? In C# you have LINQ, in Go you're writing for loops around array slices.

Maybe I was using it wrong? As I recall, "the usual" APIs present in most other OO languages were not available when I tried to help a friend with a project 3 montjs ago.

Which APIs were those?

You might've forgotten to reference LINQ and Collections.Generic in your project? Because C# definitely has good collection APIs that influenced many languages including Java Streams.

C# has very comprehensive collection API. More so than those languages.

Most languages copy c#

Which collection APIs were you missing? Between the standard interfaces and their default implementations[1] and the extension methods to IEnumerable[2] you can do quite a lot in my experience.

[1]: https://docs.microsoft.com/en-us/dotnet/api/system.collectio...

[2]: https://docs.microsoft.com/en-us/dotnet/api/system.collectio...

.NET core can run on any platform it wants, but as long as it's from Microsoft, the company as we know it, I won't even write "Hello, World!" with it.

A language can't be the fastest at everything in today's mature language ecosystem. OTOH, Debian's "Programming Language Games" benchmarks shows it's on par with Java (which is not slow in any means), and not as fast as you claim [0].

In the page I shared, some C# benchmarks are impressively fast, because they are written with explicit hand crafted SSE3/AVX vectors, which a run of the mill programmer won't want to touch (for most of the time, anyway).

Comparing .NET Core, which is a hybrid JIT language with purely interpreted ones like NodeJS and Python also makes no sense at all, considering Python Compiler does not do any optimizations whatsoever, and is still confined to a single core per process unless you pull some tricks.

Choosing horses for courses is fine, and we all shall do it, but claiming a language as winner over a single benchmark suite, including the one I referenced is wrong.

Choose what works best for you.

[0]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Curious, what is it with Microsoft that makes it so poisonous for you that you won't touch anything they make with a ten foot pole? As an example, I'd say Facebook (Meta) is a way more toxic company but I've never heard of a developer have moral arguments against using React

I'm using Linux for 20 years, and witnessing what Microsoft is doing for more than 25. Being openly hostile towards Linux and plotting ways to lock it out of hardware platforms and tech ecosystems is enough of a motivation for me.

It's not only their stance against Linux only, but everything competing with them.

I believe hardware and software should be open and platforms shall compete openly. I don't use any vendor which openly kills this interoperability and try to corner market with underhanded tactics.

It's not limited to Microsoft, though. I use Java because there's OpenJDK, Go because there's gcc-go toolchain, etc. Similarly I don't use Rust because it's LLVM only for now.

However, this doesn't mean that I want these to disappear. I want them to compete fairly, so we can improve. I'm not a web-dev so I have no need for this frameworks, but I'd make similar choices if I enter to that arena, too.

> I believe hardware and software should be open and platforms shall compete openly. I don't use any vendor which openly kills this interoperability and try to corner market with underhanded tactics. [..] Similarly I don't use Rust because it's LLVM only for now.

I'm curious, what do you have against LLVM? I'm sure it supports fewer backends than GCC, no surprise given their relative ages, but it's still got quite a few and it's open enough that it has documented support for adding new backends.

I think the point was not against LLVM itself, but rather against languages for which only a single implementation is available, which is a pretty strong argument IMHO.

I'm not strictly against LLVM. My objections are the license, and how companies use it against GCC/GNU.

I open everything I can, and strictly with GNU/GPLv3+. I want this code can be built and improved upon, even after I abandon it voluntarily or involuntarily. Hence I choose GPL licensed (or close as much as possible) toolchains and tools as much as possible.

For example, I use Eclipse, and include .project files in the repositories, so one can import the project as is, and continue playing, or maintaining the code. I'm improving my Eclipse knowledge to use agnostic paths, so anyone cloning the repo can directly import to Eclipse, and just click build.

I also plan to make my Eclipse and toolchain settings available to make my development environment completely reproducible.

On the case of the Rust, I'm waiting gccrs, which is arriving as an unofficial language in gcc-13. This will both provide an alternative and GPL licensed implementation of the language, and I can be sure that the code I leave behind can be built with the public version of the GCC.

Moreover, I use no compiler specific extensions, because I'm not trying to lock anyone to any toolchain. I'm just trying to make sure that the repo is buildable. I may even add a LLVM (or go-gc) test path to make sure that I don't break anything between implementations.

IOW, I have strong opinions about software freedom, and I apply them to my code, but not force people to obey them (except the license, because I need to underpin it). It's a strong stance, yet there's no insistence. I just set an example, and try to make it a very good one, to show it can be done.

> I use Java because there's OpenJDK

Which is mostly (~95%) developed by Oracle and is about the same in its openness and community participation as

https://github.com/dotnet/runtime/

is.

Or maybe you meant OpenJ9?

FWIW I also use Linux exclusively, develop (and host) dotnet applications on it, and have my own gripes with it (mostly with Linux still being treated as a second-tier platform which is only good for servers as far as MS is concerned — I'm not talking about the abomination that VS is — try to compare the official profiling & debugging tooling).

There's an important distinction: License. OpenJDK is GPL2.0, .NET runtime is MIT. They may be same in terms of openness, but not in freedom sense.

As a result, OpenJDK is much more sustainable in the long term, since it can't be closed down and crippled as easily.

While I am no enemy of MIT/BSD style licenses, the "freedoms" they provide to corporations are damaging to open source ecosystem in my eyes.

OpenJ9 looks like EPL licensed, and indeed interesting. It's worth a look.

I'm not writing Java with any considerable volume for some time (because, I didn't need that), hence I was just keeping that in my peripheral vision without paying much attention. However, I'm using Eclipse because it's a great IDE for my needs, and comes with OpenJ9 embedded.

Thanks for bringing this to my attention, will look deeper.

I don't touch anything from facebook, will not touch react or projects with react.

us old farts remember Microsoft (and Gates) as true villains. Things have changed but those wounds run deep and the scars remain. Every time i see the Bill and Melinda Gates foundation in the news all i can see is Bill trying to buy his way into heaven.

Same, except I don't still trust him or his foundation. The foundation is a tax dodge to push their unelected will on the population.

In proper society, the population would get to vote on the initiatives they care about.

I never considered Microsoft as villains in the 90s. They were the only company making computers usable, and thanks to them I didn't have to use the archaic Unix systems that were prevalent at the time. Microsoft was being unfairly punished for things that are commonplace today, like integrating browsers with operating systems.

They have strategy called Embrace, Extend, Extinguish.

They are still running this strategy, but now also buy good PR buying paying high profile developers thru their developer advocate positions.

""" Microsoft finally is fulfilling its dream of EEE to Linux. Windows Subsystem for Linux (WSL) embraced the API – letting you run Linux binaries (and GUIs!) on Windows natively. Next, WSL extended the kernel with GPU driver support. "" " - https://matt-rickard.com/embrace-extend-extinguish/

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 like drogon or just-js are impressive feats of engineering, but the only reason they exist is so that their authors can mention that on their resume. If you run them in production, you are on your own.

There's equally fast Vert.x, which you can buy support from Red Hat for, but most Java shops use Spring Boot (vmware or Red Hat support available), which is easier, but hopelessly slow in comparison.

> 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 the fastest full-featured "enterprise" framework.

Again, the same because the software I develop is not "Enterprise" either.

What I develop is scientific software, and needs to be extremely performant. In my case C++ is the best language, but it's not the best for every case. This is why I also learn Go and use Python for other tasks.

In my case, Debian's benchmarks are directly related to my use cases, however even that's not a definitive measurement for my case. It's just a bunch of data to keep in mind.

> 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.

And that's fine. Your niche is valid. Just no need to point out that a benchmark targeted at web frameworks focuses on... web use cases.

> 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.

> 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.

Hard disagree. I prefer specialized tools over jack-of-all-trades. Otherwise we would be coding web applications in assembly.

Your example, Ruby, wouldn't even be a blip in history radar if it wasn't for Ruby on Rails, a specialized and very productive toolkit.

Just because RoR now has more competition doesn't mean it isn't/wasn't awesome.

> Otherwise we would be coding web applications in assembly

Some people write web-apps in C. Just because you don't like something, it doesn't mean the world agrees.

>Ruby, wouldn't even be a blip in history radar if it wasn't for Ruby on Rails

Hard disagree. Ruby was getting traction on its own, as "the purest OOP language you can use in the real world", around the same time Python was starting to get traction (early 2000s). Then RoR blew up, effectively coopting the entire ecosystem. Since then, Python has slowly gone from strength to strength in so many different fields, whereas Ruby died on its ass as soon as people moved on to other tools for web.

I only looked at the binary example and it’s some of the worst C# code I’ve ever seen. It’s synchronizing every task in a loop instead of waiting for the tasks to complete like the Java example. It’s returning a result instead of using an array like the Java example. The 2 examples are not equivalent.

I know no C#, but you can contribute a better one if you prefer. Some of the languages have multiple implementations in the games and their performance vary a lot.

Small nitpick, Nodejs has a JIT (via V8) and you will be surprised at its performance when compared to Python.

I know, I've written NodeJS for a very short time, and remember liking it. However I can't position it into my current ecosystem where code is probably be seen by multiple people and need to understand/improve it.

Thanks for reminding, BTW. :)

> Yet latest TechEmpower benchmarks shows .net running on Linux and being faster than Go, Python, Node, and Rust.

That's not true atm.

At time of writing (TechEmpower 21) Rust frameworks have top 3 out ouf 5 slots (#2, #3 and #5) in composite rankings. https://www.techempower.com/benchmarks/#section=data-r21&tes...

Which goes to show, benchmarks change and depend on use case. And Rust is very competitive (in league with C/C++).

Whats wrong with comparisons to Java, and why the need for you and the article author to throw shade at Java while singing the praises of C#?

Java and C# are very similar languages.

Shitting on Java is part of .NET ethos (I've worked in a couple of .NET shops)

I recently worked with some .Net developers who wanted a primarily Java based company to let them work with .Net. In their opinion .Net was so much better (faster, larger ecosystem, more developers) that it would pay off quickly. When I asked them for documentation, they pointed to some microbenchmarks that had no significance to the type of work they would do. They also complained that Java was more "corporate" than ".Net", which is ridiculous in my opinion. Even if that was the case, the differences would be a "rounding error"

I think that's part of every other language's ethos.

In the Java dev teams I haven't noticed any common target that would be consistently shat on.

Just use F# instead and you will have Rust, typescript, Javascript, dart, python all at once https://twitter.com/FableCompiler/status/1550429007443017729...

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

I used to use Visual Studio and VSMac for my F# experimentation. Over the past couple of years, Ionide has got so much better that I've switched completely over to it from VS for all my F# work. The new 7.0 release a couple of days ago looks to have continued this trend.

Try to do a GUI or EF data model design in Ionide, hot code reload while changing a GUI design, or using annotations from code generators.

My view: F#, or to be honest a cross-platform IDE like VS Code isn't probably appropriate for many of these apps or rather the dev workflow that Microsoft promote in those frameworks feels like old .NET to me. The frameworks themselves weren't designed for a minimal IDE, and language first development initially often assuming dev is in full Visual Studio with GUI XAML editors, EF designers, etc. To be bluntly honest with my opinion it isn't a dev workflow that would fly/got started in other more open languages including F# which should be develop-able and maintainable with a lot less tooling support.

F# feels like a different dev workflow than C#, which IMO is a very good thing in F#'s favor. It feels more like coding JS, Go, etc to me with static typing and richer features. I also think EF, as it is designed, doesn't lean to the FP approach that well.

I personally don't like EF - I'm happy with something in .NET like DbUp for migrations and straight SQL. Normally I get better performance anyway doing this and in the age of microservices I feel this pattern actually makes it easier to change DB's if you need to (but I still assert you probably never will without a rewrite most of the time) - just use the different query language and port your data access layer. Move to Redis? Just port your F# module that queries the DB in SQL to Redis code. In F# it also allows a richer data modelling experience doing it this way (e.g use of DU's for modelling cases in your domain) since db logic is decoupled from your domain types.

I never believed my domain model had to look similar to my DB table design which is what EF typically encourages. Especially with the modern features of DB's like Postgres you are leaving more and more performance on the table. In the apps I've written doing that leads to lower DB performance than otherwise, sometimes for some quite trivial apps.

TL;DR: Tooling like Resharper, designers, etc is nice but often is there IMO because the language itself is bloated and not expressive enough to just state your original intent there succinctly. If the code is enough then F# can express pretty much what C# can.

Languages alone are worthless what matters is the whole development experience.

When F# came out in 2010, it appeared it would be made to share the podium with C#, VB and C++/CLI (even that black swan has better tooling on VS).

Instead what we have witness is that management doesn't really know where to F#, and naturally they cannot take it from the box.

More recently they are positioning to go against Python in data science, when .NET lacks the library ecosystem (ML.NET is still half way there and favours C# anyway), and the Microsoft was able to convince Guido come out of his early requirement with the purpose to improve CPython's performance on the top of the already existing ecosystem.

Meanwhile Intel and NVidia are also on the race to improve Python for GPU compute.

So in the end that leaves F# as a nicer ML derived language that happens to have access to the .NET libraries, with a community that kind of re-invents what .NET already offers, and a master that to this way is wondering what to do with it, other than a laboratory for C# features.

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.

You mean the traditional World Data Bank example that we got to see at each F# conference with little relevance for .NET shops?

What I care about are the code generation libraries that get served alongside NuGet packages with attributes, e.g. the ones used by MVVM, MAUI or Blazor.

Just use a mixed solution then i.e. why not both? You're picking one thing that F# isn't great at - generated code tooling which IMO isn't in the spirit of many modern languages anyway. I don't get why some C# devs tend to be antagonistic to F#. Not suited to what you use? That's fine but that doesn't mean it isn't good for others. I've seen dev's coming from other languages to F# and thinking its brilliant that would of never approached C#. I agree that each language has its sweet spot. Looking at their feature sets I think:

- Domain modelling, algorithm, business logic, etc is easier with F# in general. C# is getting better than this, but F# is there and has been there for a long time.

- Integrating with build tooling and generation tends to be C# because these tools were designed for that target (i.e not the language itself). The value is in the tooling and the engineering in that - C# just happens to be the target.

Personally with the above I've found most of the logic tends to be in F# with some C# projects for where the packages needs that build tooling support (i.e. not the language or syntax, but for the tooling or other features of Roslyn). An example would be Grpc.Tools. Most of the time these projects can use generated code anyway so the writing of C# can be kept to a minimum - i.e. not one single C# file in the C# project. Besides I think the learning curve/barrier for a language isn't really syntax, or language features - its the libraries to use, the patterns, the ecosystem, package manager, CI/CD settings, etc. Using F# isn't a large cost once you've learnt all those things that are shared which is way more than isn't.

Mixing languages increases the code complexity and hiring requirements for anyone that has to touch the code.

Everyone on the project has to learn two languages, two ecosystems, because naturally F# folks either reinvent or create idiomatic wrappers for what .NET already offers, a typical side effect in guest languages.

And then there are the enterprise support teams that explicitly only give support if the issues are reproducible with C# when giving example on tickets, increasing the costs to submit support tickets.

Most F# devs know some C# anyway, I don't think this is a big problem. It might be a problem if you mix C# and, IDK, Lua, but C# and F# are just good friends

The point was the other way around, how to justify the adoption of F# in Microsoft shops, when Microsoft itself isn't sure where to go with it, doesn't invest in better VS tooling for it, and recently behaves as the C in CLR stands for C# instead of Common.

I think this is a problem with many languages - e.g. Scala, Kotlin, etc. The easier justification really is: Does it fit your problem space? Will you save dev time overall, is it more maintainable using this tool? Do your staff prefer working with one tool over the other? Does it meet business objectives?

I don't think F# will ever be more than niche; that I can agree with you. Not because of any technical reason though; perception and marketing unfortunately does matter. Your points around "investment", etc are to me impressions/metrics around that.

In the end these things are just tools. I'm personally in a team that is doing a lot of generic math, and in our .NET based projects F# seems easier and quicker to get that performance. I know C# preview adds some improvements here but it seems more complicated than the F# approach.

I have never used a code generator for C#, which one do you have in mind? Pretty much all other .NET things can be used from F# equally well as in C#

Rosylin code generators, the modern way to use compile time reflection in C# and VB.

You can bind them to code attributes, no more INotifyProperty by hand or by having common base classes.

and you'll be in a nitch market as NO ONE uses F#

> For the front-end, JavaScript is unavoidable (for now)

Author really needs to give Blazor a try. I wrote some comments last week speculating that I'd use Dart or TypeScript with C# .NET on the client because WebAssembly doesn't do DOM manipulation, but turns out I should have waited to learn it better before making a comment.

I've learned I can add events and event handlers to elements without ever leaving C#. Then when I need to use a JavaScript library, I can load it just in time for my component. Once I got the hang of it I really felt like I've found the sweet spot for front end development.

Blazor is in development and will only get better. I believe it will eventually be recognized for what it is, but it's still early.

In theory, blazor is really neat. But last I checked you have to either go fully thin-client (server side blazor) or have an annoyingly large initial download (client side blazor). Which is probably fine if everyone's wired to the company network, but maybe less so if there's mobile involved or the general public needs access from the local coffee shop.

I'm currently playing around with server side Blazor and it works well. It's definitely not for general public applications but it seems great for internal corporate apps.

The issue that I have is since it is a thin-client re-deploys kick everyone off immediately. Where the web is totally stateless this is 100% state full. I'm used to being able to deploy production fixes rapidly without disturbing anyone's work but with Blazor server that's impossible. I've started to look into load-balancing solutions or something but not being able to roll out fixes throughout the day is almost a deal breaker for me.

It's a pain, but there are some optimizations to shrink the large download size.

This person was able to get it from 14.4MB to 4.4MB: https://www.michielpost.nl/posts/reducing-blazor-webassembly...

Whether that's acceptable is up for debate but it is in line with most SPAs/websites these days.

If you're willing to go down the f# rabbit hole there's also Fable which I need to try but I've heard very good things about.

Yeah, but F# is even worse than C# in the sense that you need really talented developers to get anywhere. Which is not a problem on personal projects, but can be for the majority of companies.

Building a company based on Fable/F# now. We're in process of taking folks with 2-3 years of react exp and teaching them Fable - it's a pretty quick transition. F# tends to attract some pretty talented developers as well.

Fable is pretty nice to work with. Writing bindings is fairly trivial given typescripts influence on the front-end library landscape, and you can just yolo call things dynamically if you want.

Here's a small gist where I use fable-py to use the python prettymaps project that was posted a week ago on HN: https://gist.github.com/Banashek/1cc3d8435843bcff230906fb037...

Can confirm, we’re developing in Blazor now and it’s fine. Not as loosey goosey as js, but makes as much sense as any other js framework. And having such tight integration with Entity Framework makes development a breeze.

Blazor server or wasm?

Server. From an ergonomic standpoint, the development is basically identical to WASM ASFAICT. This is all internal though, so ymmv if you're developing stuff for the open Internet. I guess it depends heavily on how married your org is or isn't to c#, which we very much are. I vastly prefer this to serving up a separate UI for what we do.

I'm a huge fan of C#, but I didn't really like Blazor when I tried it. I had expected to love it too. I found much of Blazor's boilerplate to be very ugly, I didn't like the complication involved in referencing npm libraries or backend code, and I couldn't figure out where several magical authentication related pages in the example app were coming from. I switched back to Typescript and Vue 3 (almost went with Svelte). I'm investigating the HotChocolate GraphQL library this week to see if I can marry the frontend and backend that way. I was hoping Blazor would give me a nice productivity boost, but native frontend development is hard to compete with. I'll likely try again in a few years.

> I found much of Blazor's boilerplate to be very ugly

I call that bureaucratic software because it reminds me of doing taxes. It's put me off from trying a lot of Microsoft tools, but with Blazor I decided to push through the pain. Once I did, I could see the logic of it and it became less of an annoyance

The thing is in .NET 7, they are going to decouple the WebAssembly toolchain from Blazor.

This will allow people to write competing frontend frameworks, or mix and match their JS framework of choice while calling into .NET app logic.

The latter already possible, though a bit hacky with the official tooling at the moment, since Mono can compile regular .NET code to WASM no problem (a fact already extensively used by game engines like Godot or Unity).

Blazor server was not executed on well. It's a poor react clone before react had hooks. The ecosystem is also small and not flexible. I would choose javascript over it, unless I already had a large investment in C#/.NET.

What? It's Razor templating on the frontend. It's also an MVVM framework, and has much more in common with Angular than React.

> Blazor is in development and will only get better.

How good can it get though? Blazor WASM suffers from the huge initial, multi-megabyte download of the .NET runtime. How is that expected to come down to something in the range of 50-500kb what we have with most JS frameworks now? I just cannot do that on public-facing parts of an application. It is unusable when accessed from a slow mobile network. Company-internal stuff sure, who cares.

I really wanted to love Blazor, and evaluated replacing some of the complex frontend UIs at work which are a JS nightmare with either Blazor Serverside or WASM. But serverside seems like an afterthought to me. I recently learned about Phoenix Liveview here on HN, and according to what I read, it seems like a much better option if you want that server-side rendering stream model. With Blazor-server, I get the feeling it is only a makeshift-solution until WASM takes off, and that makes me even more reluctant to use it.

I know that newer frameworks are slim but in practice bundles still seem pretty huge. Maybe that’s just asset bundling going on but I feel like people are still able to get away with.a lot

While the total download size is unlikely to go below 2MB with Blazor due to .NET Framework binaries, they are working hard on AOT and binary stripping, meaning your app could consist of a base framework download, served from a CDN, and subsequently cached, and a small app specific library that's comparable to a bundled JS lib in size.

>...served from a CDN, and subsequently cached

Due to cache partioning in browsers now, this will still be a big issue for all clients. Don't also forget that many clients are in poor internet speed zones.

A 2MB "buy in" will be unacceptably high for lots of projects (but not all, obviously).

I know I'm coming across ad a blazor fanboy, but I'm curious what made you feel like server side was an afterthought?

The biggest way server side fucked us was originally db contexts are bound to scope via IOC in asp.net similar to MVC or razor pages.

Which is fine when your scope is a single request, but when the scope is a circuit you get so many weird fucking errors. We worked around this by disabling tracking. But the right fix is we should have used factories, but we didn't figure this out until it was too late and we had written a fuck ton of code.

This is such an obvious issue and should have been in the docs but wasn't.

But other than that it seemed fined.

The vast majority of complex JS SPAs are also multi-megabyte payloads. You can also prerender components the same was SSR is used to mitigate JS initialization.

As far server-side Blazor - it seems like an afterthought because you read about Phoenix Liveview? How is that a serious evaluation? Blazor is a core part of the framework now and the server-side model is always going to be a serious option because it enables functionality that can be done with the disconnected client/WASM mode (like direct DB access without the serialization + API overhead).

> The vast majority of complex JS SPAs are also multi-megabyte payloads

I suspect you're talking about full apps that include third party deps. The majority of SPAs are < 1MB unzipped and <150KB zipped. Source:

https://gist.github.com/Restuta/cda69e50a853aa64912d

You can't look at some site that has 10MB of third party deps and compare that to what Blazor is doing. You'll still need third party deps with Blazor as well.

The sites that have a large 10MB bundle would have had 100's of 100KB scripts pre-spa days.

Have you actually tried Blazor ? Just the schism between WASM and Server and the feature matrix there, and generally shit quality of early stage Microsoft product - I wouldn't touch it with a 10 foot pole, likewise for MAUI - I've seen coworkers prototype both for some greenfield projects in last month or two and both projects gave up on it because it just isn't there yet for mainstream development.

I mean .NET core was pretty much in this boat pre v3, it took them years to move past the .NET standard mess, Xamarin never cleaned up and they are hoping MAUI will eventually just sweep it under the rug.

I wouldn't bet on any Microsoft stack that hasn't had 3+ years of successful use in the wild - I've been burned too many times. You might say the same is true for any other project/stack - but even when they moved to OSS .NET projects have this Microsoft level of complexity and boilerplate that makes diagnosing trivial things a slog. And Microsoft likes to put "stable" label on a lot of things these days with the pressure to ship. Good rule of thumb - not worth my time until v3.

I've tried Blazor. I built and deployed 3 apps for clients over the last 3 years while consulting and was able to deliver the projects for 33% what it would have cost to deliver them with react or angular.

Clients have been very happy with the results.

Then I built my own startup with it, and we have a solution that 3 devs have been working on for 2 years.

I can't recommend Blazor enough. I love it.

I have run into a fuck ton of problems with MAUI though. It's a fucking dumpster fire of a technology.

* Blazor server side I have very limited experience with client side.

They should really just dump MAUI..calling it a dumpster fire is being polite. Rather let their devs spend some time on Avalonia.

> was able to deliver the projects for 33% what it would have cost to deliver them with react or angular.

That’s a pretty extraordinary claim.

I know single stack can be more productive, but that sounds very impressive. Could you perhaps talk details of:

- styling blazor (eg. Bootstrap, tailwind); is it just drop in? How do you use it, eg. Without the tailwind preprocessor npm package?

- interactive front end components (eg drag and drop) that lag badly when using SS blazor in examples.

- bridging to native js (which is ultimately unavoidable in situations where you need integration like maps as far as I know)

- scaling load on concurrent users (one ws per user right? Are you using the signalr service & functions? I tried this and found the long running azure functions are quite expensive to run. Do you have advice?

Sorry I misspoke I meant a 33% reduction in the size of the projects. So projects that would have taken 6 weeks in React took 4 Blazor server side.

1. We just dropped in a wrapbootstrap template.

2. We wrote some javascript for interactive front end components like drag and drop or rich text editors. It was a little more work than it would have been in React but not much and everything else more than made up for it.

3. We found it wasn't particularly difficult. We'd just put JSRuntime.InvokeAsync in a C# method. Used it for things like popups and initializing some js libraries.

4. We're only using Azure App Service and Azure SQL database. Our long running functions we just run as a scheduled service on the app service. (though eventually we'll to do some refactoring when we need to scale horizontally). We're a B2B SaaS company so our revenue is quite high compared to our compute usage. By our back of the envelope calculations we won't have to add another server until we're somewhere between 5 and 15 million ARR. We think we'll need to do about 2-3 months of refactoring at that point to allow for horizontal scaling.

I wouldn't recommend Blazor-Server Side for B2C typical applications that have a low ARPU.

The big advantage in development speed is we got the functionality of a SPA but at the development cost of a classic multi-page application.

>* Blazor server side I have very limited experience with client side.

That's part of my problem with it - from what I see they are pushing two independent tech stacks (WASM and dynamic server rendering/JS updates) under the same name - but the APIs underneath and the architecture is very different.

The problem I have with Blazor Server side is that it requires a stable internet connection otherwise client socket connection drops and the browser issues a full page reload.

Or at least those were my findings last time I tried. I would be very happy if that isn't the case currently.

For intranet web apps it looks amazing though.

Definitely agree with you. Blazor is absolutely amazing and makes development extremely fast. Makes me wonder if people commenting have even tried it.

> "Have you actually tried Blazor? "

Yes. Server-side Blazor is incredibly productive and fantastic for complex UIs, especially for B2B and other SaaS products.

Server side Blazor is really like webforms in terms of client state management and scalability. I am not sure I would really use it for anything.

Man, I tried out Blazor over the last few days. I really wanted to love it (I love C#), and it looks like it might be good one day, but I found it sadly lacking. I couldn't even add a mouse event to a canvas element. I had to install an extension package to even use a canvas (BECanvas), and then that extension package didn't even have mouse events. I have to say, thats so absurdly basic of a thing to be missing that it made me call the entire library into question: what other extremely basic things could it be missing as well?

Anything with canvas, or a very interactive experience I think Blazor is a bad fit for. I'd do just straight JavaScript or typescript.

But so much of the world is user clicks a button, run server side code, update html, and blazor is an amazing fit for that.

Like I'd never build a Google sheets, Microsoft word, or outlook replacement in Blazor.

But I'd totally build a hub spot, Salesforce, Facebook, reddit or hacker news clone with it.

I was really excited for Blazor, until I tried developing for it. The DX is not really there yet and in the mean time I stumbled up HTMX (https://htmx.org/) and now I'm having an even harder time being excited for Blazor. And don't get me started on Blazor Server vs Blazor WASM...

The thing is, Blazor will become the lingua franca of (web) UI development for bigcorps, so I just need to suck it up and learn it (I'm a .NET consultant geared towards finance & insurance)

Its funny, after considering Blazor serverside and WASM, I also opted for HTMX + Alpine.js (when needed) + ViewComponents. Considering how nice server-side rendering story is in ASP.NET, I feel like this is a setup that really works well in a lot of situations, from low-interactivity pages to really complex UIs. It is lightweight on the client side (just load the small htmx and alpine scripts), lets me do much of rendering server-side in .cshtml views, and which needs no JS build pipeline of any kind.

This my exact setup and the only thing I’m missing is Blazor-style component syntax instead of the fairly convoluted way with <vc:*>

With blazor you need to choose Client or Server Blazor. Client will give you 10MB+ page downloads, Server will require stable and low-latency internet connection. It's fine for intranet systems, but not for general webdev

Author here.

I tried Blazor. We used it for one mission critical project.

We found that the development cycle is too long and it has too much friction compared to Node for front-end development.

Back to Node for frontend (Vue)!

Blazor WASM is promising but it really lacks some like MobX. There is a Weave based project that's sim to MobX, but hasn't gotten a ton of traction.

Then there is a Redux-like option and.. No thanks :D

The thing I miss the most with C# and dotnet is offline documentation. With Java, I can install the java-17-openjdk-javadoc package and have the full API reference (at /usr/share/javadoc/java/index.html), and download a couple of PDF files to have also the full language and bytecode specification. With Rust, I can install the rust-doc package and have the full API and language reference (at /usr/share/doc/rust/html/index.html). But so far, I haven't found an equivalent for dotnet, unless you're running Visual Studio on Windows. When you want to learn by leisurely browsing the API documentation and language reference, the speed difference is massive: the online documentation takes a bit of time to switch from one page to another, while with offline documentation it's nearly instant.

You might be able to do something with this: https://github.com/dotnet/docs

The browsy bits might not work without a server (not sure), but the documents themselves are markdown.

could you clone the docs repo? https://github.com/dotnet/docs

I use Zeal documentation browser and it has most of .NET docs available offline

Most topics on docs.microsoft.com have links to pdf, e.g. https://docs.microsoft.com/en-us/dotnet/csharp/ have "Download PDF" in bottom left corner which links to 2756 pages of C# documentation: https://docs.microsoft.com/en-us/dotnet/opbuildpdf/csharp/to...

I wouldn't lose a second to C# or any MS platform unless required for employment reasons.

https://github.com/OmniSharp/omnisharp-vscode/issues/5276

Could you explain your point a bit more? They are EEE'ing a VSCode extension, so you're going to avoid that and the language, and the entire ecosystem?

They are replacing an open source extension with a closed source extension. Makes people nervous given the embrace, extend, extinguish paradigm that they previously employed.

See https://www.isdotnetopen.com/

> They are EEE'ing a VSCode extension, so you're going to avoid that and the language, and the entire ecosystem?

Sounds like a pretty good reason to me?

Sorry, but OmniSharp sucks, and this is not a controversial opinion even among Microsoft employees. I am all for the .NET experience in VS Code improving greatly from where it is with OmniSharp. This will actually help increase adoption of .NET, which, I remind you, is open source.

> Sorry, but OmniSharp sucks

I agree. This appears more like an attempt to get the most value (integration of proprietary Visual Studio features that devs want) into the VSCode extension as quickly as possible.

Said proprietary libraries are likely not able to be easily open sourced for a variety of possible reasons, so a closed source LSP bridge was the compromise the teams came to.

The directly related fight here is Microsoft's pylance on the Python side. pyright still exists and many of the components in pylance are still open source, but pylance itself is closed source and bundles closed source tools. (That is pylance is not just a pyright fork, but closed source LSP bridge for pyright + proprietary parts.)

It's not without controversy on the Python side as well.

At some point it simply becomes questions of stewardship and transparency: How good are they at pointing out the open source parts wrapped inside the closed source LSP bridge? What cadence do they upstream fixes to the open source parts?

So far Microsoft's stewardship on the Python side seems strong: pylance has a lot of transparent documentation of all the open source bits. There seems to be a steady upstream flow to pyright for users that prefer to stay entirely with an open source LSP. Microsoft isn't treating it like a competition to "win" and encourages users to make their own choice among the options.

Of course, Microsoft doesn't "own" Python in the same way it "owns" .NET so I can definitely understand why there's increased fear that Microsoft won't be as good of a steward with respect to this "competition" with OmniSharp simply because of .NET's past. But in .NET's past this controversy would be happening after Microsoft did all the work in building the closed source LSP replacement. The fact that we're having this discussion now in only an "architectural discussion" state says a lot already about how Microsoft's stewardship and transparency have changed today.

Yes, but it works and it's open source. All the other languages have open source tooling (LSP or similar), why can't we have one for C#?

Why would you ever waste time using VSCode for C# when VS and JetBrains Rider exist?

Maybe it's good to have an open ecosystem for using the language that doesn't rely on paying for an IDE? I personally soured on Kotlin for this same reason!

VS is free though.

Yeah but it's terrible?

It's slow, it's bloated, it's loaded with way too many configuration options and yet still doesn't have a lot of config I like from other editors. It has plenty of plugins and still manages to be missing extensions that I find important.

Development with Visual Studio just doesn't feel very good compared to other environments these days.

You mean lack of GUI tooling, no proper debugger, no parallel code debugging, no GPGPU debugging, no hotcode reload, no REPL, no mixed language debugging, no lifecycle management,... yeah those environments rock.

That sure isn't my understanding if you work for a large enough business. It is very explicitly NOT free.

https://visualstudio.microsoft.com/license-terms/mlt031819/

This is the rare post where I would be fucking ecstatic to be proven wrong but sadly I believe I'm correct.

Yes, VS is free for individual devs, and for five users in a small business. Does it matter though? If you're too cheap to pay for developer tools, you're probably a terrible place to work at.

Yeah it's pretty important if you're at such a terrible place to work at, because you can make that place a little less terrible, and because you can use the C# experience you garner to get into a less terrible job.

Why is it assumed that you're only ever professionally working on code? Do none of you work on side projects, or open source projects?

Did you read what you replied to?

It's free for individual developers, small businesses, and work on open source projects (no matter the size of the organisation).

https://visualstudio.microsoft.com/vs/pricing/

...and doesn't on Linux

Why do people feel they are absoultely entitled to having best-in-class IDEs for free? Don't the developers of those IDEs have the right to, you know, eat?

ALso, JetBrains' IDEs are:

- free for students, startups and opensource projects

- cost an insane "two/three beers a month" for individual licenses (yeah, it's more expensive than two beers in many countries, but as a developer I could easily afford it even in the shithole that is Moldova)

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.

Those are not best-in-class. Pretty much the entire industry is now VS Code by default - which is very good but not a full IDE like VS or Rider/IntelliJ series.

I'm extremely happy writing Rust with neovim and rust-analyzer. There are plenty of long time rust users who will absolutely tell you that rust-analyzer beats IntelliJ Rust, and I find it very much comparable to writing Java in IntelliJ, which I do professionally. Likewise, Elixir's open source and community developed LSP is incredible and easily an IDE-class experience with neovim or VSCode.

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 can read things like "X is amazing for refactoring because you change something, and the compiler will tell you all the places where it can't compile".

Good tools are expensive. 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.

And, to re-iterate, no language is dependent on an IDE these days. Go grab Kotlin's CLI compiler, https://kotlinlang.org/docs/command-line.html fire up your vi/emacs/gedit and code to your heart's content if you're so set against commercial IDEs.

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!

> The context is about using VS Code (or something else) with OmniSharp instead of VS and Rider

This is what you said, in it's entirety: "Maybe it's good to have an open ecosystem for using the language that doesn't rely on paying for an IDE? I personally soured on Kotlin for this same reason!"

And then you go ahead and praise a tool that implements LSP...

Do you realise that "open ecosystem" literally couldn't produce anything of note for any language until the megacorporation you love to hate came along and provided a solution? It wasn't "open ecosystem" that gave you the language server protocol. It was Microsoft that designed it and implemented it for their own VS Code. And the "open ecosystem" that sat on its ass for decades flocked to it and to the protocol like kids to the Pied Piper of Hameln.

And again with "you need paid IDE to develop this and that". No. You don't. There's LSP for C#. There's LSP for Kotlin. You'd know that if you went ahead and looked just slightly beyond your blind hate of commercial IDEs.

Honestly, you've been attacking me personally for quite some time now for no reason (I've done the courtesy of not attacking you, perhaps you could try to do the same?) so I'll not bother responding after this. At any rate,

> You'd know that if you went ahead and looked just slightly beyond your blind hate of commercial IDEs.

Maybe you missed me saying I use IntelliJ professionally in the previous comment? I'm a happy, paying user of JetBrains IDEs, I've defended them several times on HN myself. I don't hate commercial IDEs; I hate being forced to use them.

It's extremely bizarre that you assume I'm trying to cheap when I'm trying to be principled: I believe the presence of free (as in speech) solutions are essential for me to seriously consider a language. Being tied to a corporation's whims to efficiently use it is ridiculous; I was a happy F# hacker myself until I saw the more recent moves MS has been making. I think what they're doing - replacing omnisharp with a closed source solution and the debacle with trying to make hot reload a paid VS feature being two major, recent issues - show that MS simply cannot be trusted to run a language ecosystem without trying to force its users into behaving as they want them to. There's simply no reason to invest any time into the dotnet ecosystem when there's very comparable languages with comparable performance and ecosystems which don't have this issue.

> And then you go ahead and praise a tool that implements LSP...

What? I'm afraid you've completely lost me here. It doesn't matter that MS came up with LSP, so long as the protocol is open and people can implement and use it without MS's approval. Dozens of editors that have nothing to do with MS implement LSP, the fact that it was made by them is almost incidental.

I work at Microsoft as a SWE and use VS Code for c# and js. I've been using VS and Rider a bit as well, but after years of doing python and everything else in VS Code, it's just so familiar and it works just fine for everything my team does so far.

Obviously everyone's preferences are different, so this isn't a direct response but just another anecdote.

I tried VS Code and couldn't get used to it. So now I use Rider for C# and Webstorm for JS. Sometimes I open Visual Studio, though:

> There are some custom plugins someone in my org wrote that help accomplish some team-specific tasks > When I need to work on stored procedures in our SQL databases. Rider doesn't know how to parse the schema from the sql project files, instead it wants me to connect to a live database or it will color everything with little red underlines and give me no autocomplete

I think it's nice that my employer is willing to pay for my Jetbrains licenses despite the fact that it is selling a proprietary competitor and also simultaneously pushing an open source alternative. I appreciate it.

Can they develop remotely on a linux server? Last I checked VSC is the only one that can.

They have a thin client in beta:

https://www.jetbrains.com/remote-development/gateway/

Licensing costs, licensing costs, and the fact that you often don't need to go through corporate approvals to download VSCode and the C# extension particularly if you are an employee who isn't nominally a "software developer".

VSCode with the C# extension is the preferred C# development environment of corporate shadow IT.

Because people will use whatever tool works for them

Edit: I love vscode for c#

I grew up on C# and tried server side JS recently, and my god, the decision fatigue of picking every little library to do every little thing! C# is just so batteries-included. I'm not sure Blazor is ready for prime time but I like the promise of being able to use C# everywhere.

The article makes a case against using Node.js but doesn't bother to provide a comparison of C# and its actual competitors: Java and Go.

Python, Ruby.

Obviously there is some degree of subjectivity as what a given language's competitors are. In some sense all languages compete with one another but I do think there is some natural clumping of languages/ecosystems.

In my view Python and Ruby are not natural competitors to C# as they are dynamically typed and (in Python's case) interpreted. Similarly Rust, C, and C++ are not natural competitors to C# as they do not have a GC. Java, C# and Go, on the other hand, are pretty similar.

This obsession of dynamically typing vs static typing is not useful. ASP.net is used to develop web applications. C# does have better performance than Python, but I highly doubt most applications will ever need or care about that. Choosing C# over Python (or Ruby, JS etc) for performance reasons is premature optimization at best.

Maybe you have some legacy codebase in C# that you need to leverage.

All other reasons to chose C# over something else for web applications seem to lack evidence but certainly not conviction. So yes, Python is a direct competitor to C#, as in there are many more Python web projects out there than C# ASP.net ones.

I certainly hope that the Python language maintainers do not see C#,Go or Java as their competition. I like Python as is.

They definitely see Go as direct competition, or did at various points. Some of the work that was done in Python 15 years ago is now done in Go, mostly because of its superior support for highly-parallel workloads; so Python developers have reacted and improved the parallelization story in various ways (yes, it's still not as good as it could be, but it's undoubtedly better than it was when Go took a significant bite off the ecosystem).

As for Java and C#, it is a fact that all of them joustle for the backend market together with Python. Java and C# were there first and have massive commercial backing pushing them, but Python has slowly carved a larger and larger role on the back of technical merit. As long as it continues to do that, I don't think you need to worry.

I don’t see Python having a lot to offer in terms of technical merit really. Python’s strength is language ergonomics and fun factor. I hope they keep it that way.

Python often seems to be the status quo that "technical merit" has to beat. Python only slowly beats itself but then becomes the status quo again.

Language ergonomic is a technical merit, as opposed to commercial merit (how many companies push it, how many developers are available, etc).

Those don't really compete with C#, except in the most generic sense (as is true for all PLs).

If you are looking at server side stuff, here you go https://www.techempower.com/benchmarks/#section=data-r21

Or Kotlin, since it's IMO a slightly better language than C# in terms of ergonomics and features.

I understand that 90% of Kotlin's audience is mobile devs and server-side Kotlin is rare, but as a .NET developer, a few years ago I did a small production Spring Boot webservice in Kotlin and the experience was really good.

> My hope is that .NET and C# have a resurgence as .NET 6 rounds the corner. With .NET 6, C# 10, and minimal APIs, the language feels more modern than ever and is the perfect gateway from TypeScript/JavaScript on the server to .NET.

Oh please please please let this come true so I can write c# on the backend again. I love typescript because it made JavaScript (i.e. front end web) so much less shit to work on, and I’d prefer it over ruby or python backends still, but c# hits such a sweet spot of ease to write, while still remaining relatively performant.

Go and rust are probably better for certain applications, but c# would be light years ahead of things like ruby or python.

It must be one old article, because what rounds the corner is .NET 7, while .NET 6 and minimal APIs have been available for a better part of a year already

This seems more like Yet Another Medium Article shooting fish in a barrel by describing problems with the JS ecosystem rather than an actual case for C# and .NET.

... with large gifs in the middle.

He already said “medium article”

> This seems more like Yet Another Medium Article shooting fish in a barrel by describing problems with the JS ecosystem rather than an actual case for C# and .NET.

It's the very definition of blog spam.

The data this article quotes doesn't smell right.

The tables and graphs in "The Performance Problem" section should at least feel a little strange. Looking at the original article[1], we can see the source code for JavaScript [2], Python [3], and .Net [4] shows that...there just isn't much going on here. This isn't a comparison of how fast these are. It's a comparison of how fast this AWS setup could do its thing, and how fast this DynamoDB client library is.

In the "So Why/Not .NET?", there's the "Advisories by package ecosystem and severity"[5] graph. So it doesn't feel a little strange that NuGet is the pinnacle of software engineering, and programs there just have no security vulnerabilities? Or maybe...there's some bias going on here, and NuGet isn't as interesting to look at as PyPI, so there are fewer advisories being published? That's another way to look at it.

When things look too good to be true, maybe they are. I don't care if the author (or anyone else) wants to use .Net, have fun. I do care that we sometimes approach technological issues with hostility and rivalry, accepting random data which seem to support us without looking them through.

[1] https://filia-aleks.medium.com/aws-lambda-battle-2021-perfor... [2] https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-p... [3] https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-p... [4] https://github.com/Aleksandr-Filichkin/aws-lambda-runtimes-p... [5] https://octoverse.github.com/static/github-octoverse-2020-se...

Mostly agree with the author. But just wanted to point out that if we're doing C#/Java style OO patterns in JS (as in the Repository example shown), the value of using JS diminishes to almost nothing. JS works better without classes (and interfaces against them if using TypeScript).

If you look at how major backend projects structure their code, it's almost always object-oriented TypeScript.

I submit for the record:

- Apollo Client: https://github.com/apollographql/apollo-client/blob/main/src...

- Storybook: https://github.com/storybookjs/storybook/blob/next/lib/chann...

- Nest: https://github.com/nestjs/nest/blob/master/packages/core/nes...

- MongoDB Driver: https://github.com/mongodb/node-mongodb-native/blob/main/src...

- Prisma: https://github.com/prisma/prisma/blob/main/packages/engine-c...

My understanding is that with .NET Core, the experience of developing and running on Linux is on-par with Windows(?). However, my impression is that once it comes to building web services, ASP.NET has more "windows-specific" assumptions/moving parts - can someone knowledgeable on this correct me if I'm wrong?

I have ton of experience with ASP.NET Core and have not had that impression in the slightest.

You're wrong. Everywhere I've worked the general pattern is to build using Windows/Linux and deploy entirely on Linux (or Docker).

There is nothing in ASP NET that is more “windows specific”. Since its inception, I have used these scenarios and they all worked without flaws:

Windows -> Linux

WSL -> Linux

WSL2 -> Linux (Its real Linux)

macOS -> Linux

All of the scenarios were deployed to AWS.

Any .NET NuGet packages targeting .NET Core/.NET 5+ without the -windows TFM will run on any platform that CoreCLR runs on. ASP.NET 6 is no exception. There is nothing Windows-specific in there any longer, and there hasn't been for quite some time. ASP.NET now runs by default on Kestrel, Microsoft's cross-platform web server.

> Any .NET NuGet packages targeting .NET Core/.NET 5+ without the -windows TFM will run on any platform that CoreCLR runs on.

I got sleepy just reading this. There's just so much fragmentation and frameworks and different versions of frameworks and web-servers... can't Microsoft just let the .NET be and let them do their thing? They have certainly pumped out loads of amazing software that seemed to get a knee on the guts by higher management.

In fairness that is what they have done. .NET Framework is dead, .NET Core is "dead" (to clarify: .NET Framework dies with .NET 4 and .NET Core/CoreCLR is .NET 5 and above).

Mono is a cross-platform (ish) implementation of .NET Framework, but its future is (eventually) to be replaced with the main .NET which is now based on the cross-platform version (.NET 5 and above, which is currently distinguished from Framework by continuing to call it ".NET Core"). Mono and .NET Framework will fade away once Unity gets their act together and moves on from it.

tl;dr: .NET 5 and above are, for all intents and purposes, the only future path for .NET, but we're in a transitionary period right now.

Note that Mono, the framework, is indeed dying. But Mono, the runtime, is now part of .Net and it's an alternative to CoreCLR, used for things like Xamarin/MAUI and Blazor.

Though most of the time, you don't need to know any of this, you just use .Net and it works on Windows, Linux, Android, Apple and in the browser.

You can also use the .NET CrossCore assemblies (available since .NET Framework Core 4.777.2.1) and do multi-targeting for ASP.NET Core (the Framework version of ASP.NET Core, not the Core version which since version 5.0 is incompatible). Using ASP.NET Core 6 (the new name of ASP.NET 4.2) you can also target Linux if you compile with the flag /fuckallthatshit

I wouldn't call it on par. But it has been getting better. Developing on Linux still isn't great (I vastly prefer Visual Studio over VSCode for .NET), but might be good with the Rider IDE, which I haven't used. Running it has come a long way, but there are still some annoyances left. I'd still say that it is good, though

FWIW, I’m on Windows and still prefer Rider over VS

I run all my .NET core apps containerised in Linux. Works the exact same as on windows

The only parts that are noticeably Windows-centric are some of the tools around .NET. The older tools are Windows-only, you can't get Visual Studio on Linux.

For ASP.NET there is nothing Windows-specific in there I've noticed.

There's no issues with Windows specifics in /ASP\.NET( Core)?/ version >= 5.0.

There's some issues if you need to use an older version of ASP.NET and whether or not it has "Core" in the name, but after .NET 5 and ASP.NET 6 there's no longer that fork to confuse things and it's back to much simpler version numbers/checks and no longer needing to worry about the word "Core".

- Ignore all the DotNet version names and numbers unless you're working on legacy stuff.

- If you're starting from scratch all you need to know is that you should use DotNet 6+ and you'll be on the mainstream track with full cross-platform support.

- Nothing is Windows-specific unless you're actually wanting to target Windows stuff specifically.

- If you're doing desktop dev MAUI is the way forward, but personally I don't trust Microsoft with desktop stuff any more (too much switching and deprecation over the years).

Thanks - I was actually more confused by the comments as I'm a total beginner to .NET (just interested to learn). This sounds like a more simple/distilled advice in my context.

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.

C# and TypeScript seem to be far and away the most popular programming languages today.

At least from the perspective of recruiting in Australia.

Python is on the way up and third most popular but well behind C# and TypeScript.

Golang is on the way up but very small in terms of number of developers.

Java is on the way down but will never vanish, it's just not super popular any more.

Ruby is small enough to just be a footnote.

There's lots of other languages that make up the long tail.

The message is that if recruiting matters then you should be using C# and TypeScript.

> Python is on the way up and third most popular but well behind C# and TypeScript.

lolwut. TypeScript is niche compared to Python.

> from the perspective of recruiting in Australia.

Even accounting for that line from the comment?

Even more so. Python is huge in Australia. Can't count front-end as Python is not applicable there.

There's no reason to discount front-end work from "programming languages". You choose python over typescript for machine learning because the ecosystem is there.

You choose typescript over python because Brython and JavaScripthon and Transcrypt have no ecosystem that makes more sense than using NPM, and the people who like to program in python prefer the challenges of other domains than what's in the web browser.

That just makes "most popular programming language" a silly metric. It doesn't mean that nobody uses the language because you ignore all the people who use it for things you aren't interested in.

IMO Python and C# are not comparable. Python is at best a simple scripting language, you really can't build anything globally scalable on it. No offense to people who use Python daily, just my own observations (probably wrong).

Instagram

the biggest python codebase I'm personally aware of is JP Morgan's Athena and is about ~30 million LOC. Google, Youtube and Dropbox use Python extensively etc. Python being a scripting language stopped being a correct statement probably over a decade ago.

Keep telling yourself that and it will become true.

You said about yourself:

> just my own observations (probably wrong).

I am currently in the process of learning C#. I did a deep but brief dive into every language feature in C# 10. Being proficient in Python, absolutely nothing surprised me. All the same concepts, save for a handful, exist in either language, sometimes down to the exact keyword usage. LINQ is a big differentiator in favor of C#, but modern (that is, typed) Python looks very similar to C# (C# left, Python right):

ABCs -- ABCs

Interfaces -- Protocols/ABCs

LINQ -- ??

Enumerable/Enumerator -- Iterable/Iterator

class -- class

static -- staticmethod

foreach -- for

for -- for(range(...))

try/catch -- try/except

break/continue -- break/continue

enum -- Enum

struct -- dataclass, perhaps

namespace -- automatic on the file level

out -- pass by reference

switch/case -- match/case (both do structural pattern matching)

throw -- except

typeof -- type

overloaded methods -- singledispatch (only works for a single argument sadly, no stdlib multidispatch)

inheritance (single) -- inheritance (multiple)

object -- object (root of the type hierarchy)

generics -- generics as well (via typing, runtime never cared anyway of course)

lambda -- lambda

nullability -- None (C# can have nullable reference types, Python types are not nullable, None exists as a first-class type, not a subtype of all other types; similar ergonomics but different structurally)

extension methods -- just go wild in Python (although binding methods after class definition is cumbersome)

tuples -- tuples (both can do unpacking, multiple returns etc.)

operator overloading -- operator overloading

reflection -- reflection (arguably a Python strong-point)

async/await -- async/await

decorators (exist as a pattern) -- decorators (supported on the syntax level)

?? -- top-level/first-class-citizens functions

I probably got a couple wrong, but you get the idea: apart from LINQ, nullability handling and some others, the languages are incredibly similar in their feature set on paper. This is not talking about DX etc. though.

C# vs Java seems to be very country-dependendt. Certain countries are huge C# shops, while in others it is barely existing.

In others, consulting shops do both, including on the same project.

Perhaps in Australia, but certainly not worldwide. C# is way smaller than even Go in total, and Java is a lumbering giant. Slow perhaps, but there's no David around at the moment.

My instincts tell me that there’s no way Go is larger than C# worldwide. Large enterprises are still predominantly on C# and Java… Tiobe index, whatever you may think of it, does not support that… What’s your source?

Source for "C# is way smaller than even Go"? It's possible that there are more shops that use some Go (esp. for DevOps) than there are ones that use some C#, but that's not quite the same as C# being "way smaller".

>C# is way smaller than even Go in total

TIOBE has C# much larger than Go and growing, and it also has Go slightly shrinking over the past year.

https://www.tiobe.com/tiobe-index/

Same results on Stackoverflow https://insights.stackoverflow.com/survey/2021

Same results on IEEE Spectrum https://spectrum.ieee.org/top-programming-languages/

Same for PYPL https://pypl.github.io/PYPL.html

I cannot find a single place that looks at a large dataset and a decent number of languages that gives the result you claim.

Care to list where you got your data to support this claim?

Right now if I type the following keywords in Seek this is what I get (in order):

  SQL - 11,425 jobs
  Java - 7,390 jobs
  Python - 6,777 jobs
  C# - 4,995 jobs
  JavaScript - 4,208 jobs
  TypeScript - 758 jobs
  Ruby - 252 jobs
  Golang - 206 jobs

Did you enclose the search terms in quotes?

The article mentions it, but I'll reiterate: the .NET CLR is fantastic. C# is a great language for the backend: GC'd, lots of libraries, fast runtime, and expressive enough. Do I wish it was more functional? Absolutely. But it doesn't aspire to be that.

The ecosystem deserves mention. There are some high-quality libraries that work well, even if they aren't the most popular. Take objectional relational mappers, for instance. You can go whole hog and have an ultra-coupled, er, cough, "batteries-included" ORM much like every other ecosystem, or experiment with a multitude of options between writing your own SQL but letting the ORM handle hydration, and a full-blown ORM.

Tooling support has always been top of the line, too. It is only in the past few years that other languages have caught up with the quality there (Eclipse/IntelliJ excepted).

> ...objectional relational mappers...

love this typo.

will use objectionable-relational mappers from now on.

- objectionable - adjective, arousing distaste or opposition; unpleasant or offensive (definition source: Oxford Languages)

> Do I wish it was more functional? Absolutely. But it doesn't aspire to be that.

I somewhat disagree about the aspirations. Have you tried out things like switch expressions and LINQ? You can apply functional concepts almost everywhere these days. Complex state machines can be modeled using 100% functional techniques.

Where to start. Comparing advisories per package isn't a good metric. It assumes the usage and visibility is the same. Assuming the much smaller community around nuget packages won't bite you just as hard as bigger communities in terms of supply-chain attacks is a fallacy. Provided you can even meet your supply chain needs, and that's not a given in dotnet.

And not comparing ASP.net to more mature web frameworks is also a strange choice. At the very least, you need very capable developers not to shoot yourself in the food with the enterprisy dependency injection magic. In my opinion much more so than with other frameworks. I mean, if you have a steady supply of highly-qualified dotnet engineers, go for it...

It's a pity the author doesn't mention F#.

I like C# but I've really come to dislike the idea of exceptions and null after working with Rust.

I think C# would benefit from a Result/Option addition.

It should be a simple wrapper Func<> with a generic Option<T>. I’m sure there is a library out there doing it already.

For null, there are nullable reference types now.

Exceptions are here to stay though. I don't see how you could retrofit something like Rust's Result on top of .Net. (Also, .Net has a pattern that's an alternative to exceptions: `bool TrySomething(out T result)`. But it's quite limited, in several ways.)

Are you suggesting a Result type and Exceptions are mutually exclusive? Scala bolted `Either` (a Result type) on top of Java, and it worked exceptionally well in my experience.

Why did you not include Go in your analysis?

The speed comparison is fascinating. Ruby often takes a hit in these parts for being slow, and the inference is usually versus Java, but hose numbers suggest they’re about the same? (Though I’m a big fan of Rails, it’s a criticism I acknowledge, as I came to it from PHP.) And people blithely never refer to JavaScript’s speed, but this is suggesting that it’s 50% slower than EITHER. My point is that the usual conversation about speed of languages seems to need some adjustment.

This article seems to be a lot focused on why you should be careful about using JavaScript for backend development. C#/.NET is one valid alternative, but many others surely also provide similar benefits and also avoid the pitfalls of JS. I agree that .NET is really solid and seems often unfairly seen in a negative light though.

Hot reload for ASP.NET works fine nowadays in VS and even with older versions of .NET.

Dependency handling is still a large problem with .NET. Especially since current is often used instead of LTS. There is also no good way of sharing code between applications.

Arrow functions, btw, solves the this/that problem in JS making React development easier etc.

What do you mean when you say there is no good way to share code between applications?

What I see a lot is private Nuget packages with common functionality used within several applications at companies. These are often binaries (one can place code in a Nuget packages but it won’t update, at least not last time I tested it). In the world pre GIT it was common to link in these files and build them along with the solution. Meaning, one did not have to try to align every .NET version or keep adding build targets to the Nuget packages.

That's what I'm used to too. Shared code in Nuget packages in an internal Nuget feed. But definitely not binaries, as I've never had issues with Nuget packages not updating.

YMMV - maybe you've been especially unlucky.

I started out agreeing heavily with the article (yeah, javascript sucks today!), but one thing stuck out to me:

If Typescript makes Javascript so much work because the tooling discourages learning best practices, how does moving to C#, which is designed very similarly, help?

I.e. if half the cardinal sin was creating Typescript in the first place and that's part of why Javascript sucks so bad (I am inclined to agree, FWIW), how does C# then make it better?

Author is light on the details here. I do agree that strong typing systems, safety checks are preferably on backend systems-grade code, at least, but I don't think C#'s types are strong enough, for that prefer something like a Haskell-ish language, Cayenne e.g., Ada, and with strong code-re-usability. I decline to champion a particular language, I only know C# has a lot of baggage from Java/Typescript/Javascript, which it would be better without (C# is also starting to suffer from a C++-ish problem, where there are so many new and different ways to do the same thing that interoperability and "good" standards are swiftly becoming a problem).

wake me up when it is really open source

This.

https://isdotnetopen.com/

The page is 100% accurate but so FUDy ;). Not helpful.

If Microsoft would only clearly and trustworthy communicate.

Microsoft and trustworthy communication can't me mentioned rationally in the same sentence. I've been working with them as a customer and partner for 30 years and have been screwed over and over again. They are the worst company I've ever worked with or for or with their technology.

Reading this post, it seems like the author never tried Typescript which seems to be heavily influenced by C#. I hate JavaScript as a language, but Typescript is very palatable. Like it or not JavaScript and Typescript are the franca lingua of programming for now

It does seem like the author doesn't have much experience outside dotnet and node.

The problem with TypeScript is that because it's compiled to JavaScript eventually, it's broken whether it wants to be or not. TS might make sense on its own, but the medium is the message. You can't escape the bizarre stuff JS does when it's right there, under the hood, waiting for you...

That is true, but its strengths tend to outweigh its weaknesses.

Nothing is as universal as typescript / JavaScript. Unlike other languages you also don’t have to context change when you’re transitioning from working on the backend to the front end. Everything also tends to be rewritten for node eventually.

The author specifically mentions TypeScript. But it doesn't do anything about the dependency problem, nor the performance. And it can only patch over JS flaws so much, since the runtime and stdlib are still whatever the ES spec says they are.

Source of some images: https://docs.microsoft.com/en-us/nuget/concepts/security-bes...

Hottake:

Without JetBrains Rider .NET would have no cross platform dev experience.

VS is shitty Windows bloatware, VS for Mac is utter rubbish and OmniSharp was killed by Microsoft because they didn't fancy to give away dev tools for free and purposefully killed it in order to replace OmniSharp with a closed source extension, which as of today doesn't exist yet. So if you are a Linux developer then you are basically fucked today if you wanted to use .NET, except there is Rider. Without Rider .NET would be completely unattractive today.

If one is okay with this then .NET is amazing. Otherwise I cannot advocate for .NET anymore I am afraid. Microsoft doesn't see what's good for them. VS Code is the future, not VS. They invest too much time and money and marketing in selling VS to developers instead of making VS Code a great free OSS experience.

I think they are exactly seeing this and acting on it. IMHO they will start offering on VS Code a basic free product (a stable omnisharp equivalent) good enough for coding, debugging, etc. and then pricy options like visual designers, intellitrace, AI-guided coding, hot reload, etc. IMHO they will do the same for Python, PHP and others.

They head of the dev division needs to protect the revenue. Simple as that.

However, I completely agree with your sentiment: "Microsoft doesn't see what's good for them" ... because "free" is not "open source" and trust does not come from "free" but from "open source".

Totally get the bigger point, but I have to say the latest VS Mac is actually shaping up quite well and I like it.

Though of course in retrospect it does depend upon which workloads you're working on - and I mostly do command line tooling, web apps, and APIs, none of which require a design surface so maybe that's why my opinion differs as I've no informed idea how good/bad the layout aspect is.

C# is good, but not good enough to convince me overcoming the hurdle to onboard with its ecosystem. The deal isn't sweet enough.

Language isn't important unless it is business critical. And successful businesses are scarce.

What hurdle?

Until .NET has the equivalent of Zod, I'm not that interested.

Being able to write a validation schema and deriving types from it automatically - that I can share on client and server - is just too big an advantage.

Zod is really cool.

Similar in F# land is https://github.com/Zaid-Ajaj/Fable.Remoting While both client and server are designed to be used from F#, they should be able to be used from js/ts as well as c# if desired, though I have not tested that.

Perhaps you should look into the .NET implementation of gRPC. It works really well in my experience.

The thing with zod is that by reusing schemas on server and client, I get extra client side validation for free.

gRPC seems like it's just for the server.

Kind of an aside, but any one have a clue why those Haskell benchmarks are so slow? In my experience Haskell is relatively fast, so there must be some caveat that these test cases are hitting.

The problem is not with .NET itself, it's Microsoft. I don't even consider using VsCode as main editor because it's from MS.

There are genuine people behind these tools. Awesome people.

Sure, but they work for Microsoft. Who tried to own the industry in the 1990s.

.Net suffers from the same problem as computer science in the popular joke - names for things.

No mention of leftpad? Kids these days don't study history.

Shhhhh, you're giving away my precious secrets!

There are 171 posts at the time of writing, only one (this one) includes the character ♯

Because even microsoft doesn't call it C♯, they call it C#.

See: https://docs.microsoft.com/en-us/dotnet/csharp/

Will you tire of posting about this stupidity? https://news.ycombinator.com/item?id=32117175

Oh I do hope not. As Dr Johnson said, "when a man is tired of mocking Microsoft, he is tired of life".

You don't think something being hard to input can be blamed on the OS at all?

The only built-in way to type a sharp outside wordpad is to have a special registry key set then hold alt and type +266F, isn't it? That sounds to me like it falls under "dreadful support for Unicode".

I bet C# and F# are actually nice languages and I shortly considered adopting them together with Unity but at the end of the day I was still suspicious of Microsoft, and support for other platforms then windows. The article honestly sounds a bit like a straw man argument. Maybe bloomberg could have made another tech choice but then again I don't know the details.

Microsoft has first-party support for .NET on linux and it's open source. Their commitment to non-windows and non-.NET platforms has only increased over time.

They also have a history of randomly deciding to dump a technology (including full languages) too, leaving those invested in it holding the bag.

I like F# too, but I'll stick with one of it's non-MS controlled alternatives.

any software project or language can die, but I honestly struggle to think of a company that has a better history of long term support than Microsoft. You can fault Microsoft for quite a few things but their ability to maintain software and provide stable interfaces for devs is second to none.

MS discontinues a UI library project and then hypes up a new one every few years. Today Blazor and Maui are hot, but there's a lot of abandonware that came before.

You can see it in Windows too, where you can burrow deeper and deeper into progressively older settings dialogs, because they reshuffle the Control Panel every few years.

To be fair. Creating a good cross UI framework is hard. Winforms wouldn’t cross over to OS X / linux. WPF was too heavily tied to Windows. Silver light was a compeditor to flash and both of those died. Now we are up to Maui and Avalion? Blazor is more silverlight replacement imo.

Also, Winforms and WPF were designed before Microsoft embraced Linux and started making .NET truly cross-platform. Starting over with a new cross-platform UI framework sounds like a reasonable thing to do.

OTOH even stuff as old as Windows Forms (which literally shipped with .NET 1.0 - that's 2001!) still works and it actually has maintainers. You don't have to chase the shiny new stuff.

I hear some of IBM's stuff has a pretty long history to it.

Not with their core languages. For example, Windows still comes bundled with the old VB6 runtimes and Microsoft still supports the language even if they no longer add features to it. I'm not really sure of any major Microsoft languages that Microsoft has just dumped, unless you count their smaller more esoteric ones.

Also keep in mind that .NET Core is not only open source, but comes with complete protection from any patents Microsoft might have. The only thing Microsoft can sue people over is the .NET Core trademark itself.

> still supports the language even if they no longer add features to it

This is what I assumed the parent post was referring to. Mostly because it mirrors complaints I've heard (and maybe had) about the .net gui story. WinForms -> WPF -> whatever the windows store app framework was called -> I think MAUI now?

That's hardly a fault with Microsoft though. WinForms is fundamentally flawed and far better alternatives now exist, it'd be foolish to continue investing in WinForms. You can still use WinForms and .NET Framework on Windows 11, just don't expect new features, which is okay.

J# is one that comes to mind. Spent some time learning this only to have it dropped the next year.

Wasn't J# designed to be a transitional language for Java devs migrating to .NET/C#? (Wikipedia calls it a transitional language, too) Sure it wouldn't last long.

For running, yes. For developing, no.

What part of the .NET SDK isn't supported on Linux?

I think they are referring to visual studio support which doesn’t exist on linux.

But if you wanna use VSCode or Rider then the support is 100%

Maybe, but the discussion itself was about Microsoft's commitment to open-source. Open-sourcing VS Professional, traditionally (and still) an enterprise tool, would be a bridge too far. The commenter that started this debate called the article a straw man, which is ironic.

Their support for VSCode is pretty considerable and reached the point where I'm comfortable working on non-GUI applications in C# in it a while ago, and from a UI perspective prefer it to Visual Studio.

What? I do occasional dotnet development on Linux. Using the dotnet SDK which is from Microsoft, and VS Code which is also from Microsoft.

Huh?

If you’re a JavaScript dev, it’s worth noting that NPM is owned by Microsoft. The mistrust angle is real, but I think it’s moot when specifically talking .NET vs. JS.

I've been working in .NET for the last year using intel Mac for the first 6 months exclusively and recently switching between Windows desktop and Mac (performance of desktop machine mostly, not willing to be early adopter with M1/2)

I also use Rider exclusively and going to Visual Studio on Windows now and then I'm not missing much (visual studio did have some nice plugin for debugging compiler plugins, had to hack around than in Rider)

I can't comment on Unity part.

F# for me overpromises and underdelivers - it all sounds amazing in theory but it's been 3 times over the last decade where I've tried to use it (last time just a few months ago) and it never just works - I've spent diagnosing "why isn't this F# feature working as advertised" than solving my problem (from tooling like F# projects breaking autocomplete in VS solution - even for C# projects, to language features like type providers just being a nightmare to work with and integrate into CI/CD)

Honestly I've found F# pretty OK to use compared to some other languages, especially when not using Visual Studio on a non-Windows machine where F# IMO is the better choice. Given a cross-development experience in some of the more recent .NET teams I've been in (great that this is finally occurring btw) especially the Mac developers using VS Code prefer F#. After using it the feedback is that the experience on F#, especially since with F# Resharper is not necessary to function/develop, is preferable over C# (i.e. "its more of a scripting language").

My observation is that the ex JS/Ruby/etc devs learning curve's seem to favor F# over C# as it is more like these languages. There's just a lot less to learn, and the coding style (e.g. modules, function first, etc) is more synonymous with langs like JS than heavy OO languages. I've recently inherited a team that moved to .NET from JS, and getting them to try C# has been painful especially when using things like ASP.NET. There's a lot of knowledge I just took for granted - we don't realise how much knowledge is required to use standard Java/C# OO in a production like setting that many dev's stumbled on when they were junior but have long forgotten the learning curve they went through. They tend to be framework heavy/dependent and require much more experience. From patterns (what's a strategy, repository, etc etc), to dep injection frameworks, to which refactoring tools I need, etc, etc - where in F# in my recent experience the experience is more, but still not quite "just code and work it out as you go".

The pit of success favors F# over C# in my experience with these teams especially if you keep it simple with the features used.

My experience has been that F# appeals to coders who are using the .NET platform coming from languages like JS/Go/etc but also has static typing who usually at least in the jobs I've been in are often on a Mac. C# dev's typically come from Java/C# enterprise kind of shops. Not one is better than the other and I will work in whatever space has interesting problems to solve - I think the difference is more cultural than technical.

Reply on news.ycombinator.com