Hacker News Reader

Comment by kbd | Hacker News Reader

Is there any reason I should care about .NET today if I'm not already in the ecosystem? I've done C# professionally in the past, and C# is a good language. I wish Microsoft focused on open source and wider industry adoption for C#/.NET sooner so that it could have taken some share from Java. Now .NET is finally open source but Microsoft is a bad steward of the open source ecosystem for .NET, and I certainly wouldn't feel comfortable to say to my team "let's do this next project in C#". I don't see any particular reason to make my own tools in C# vs anything else.

So without already being in an existing Windows-based Microsoft shop, is there any reason I should be interested in .NET today?

View on HN

* Runs great on Linux in my experience & others

* Great performance - https://www.techempower.com/benchmarks/#section=data-r20&hw=...

* Open source - Microsoft has made a lot of missteps but they have came a very long way. The bright side is both how far they've came & the outcomes of the recent missteps.

* Very productive toolset imo. I focus mostly on web based tech though. I really like the syntax & type system.

* Swiss Army Knife in that you can use .NET to do just about any type of project - Web (front & back end), mobile, games, IoT, desktop, machine learning, etc.

* You can use C# & F# syntax, both very popular (though let's all be honest, F# is a 2nd class citizen in .NET but it's got a great fan base)

I don't think F# is that second class anymore especially if you are developing on Linux/Mac OSX. The more concise language/syntax is a big plus when you don't want the heavy IDE and want to be cross platform. The VS Code plugin for example seems more mature than Omnisharp and while like any other Code plugin less flaky than many of the others.

It seems to be keeping up with the broader .NET ecosystem pretty well I think - (https://devblogs.microsoft.com/dotnet/whats-new-in-fsharp-6/). In some ways it is ahead of C# as well so I wouldn't say it is behind at all.

I think there's at least one way in which F# is a second-class citizen: documentation. The documentation for anything in .Net will contain code in C#, but code in F# is quite rare.

So if you want to use F#, I think you still need to be able to read C# code.

It might not be full second class but I dunno I'd go all the way to first class. For example F# doesn't support the source generators feature that came with .NET 5 (unless they added it in 6 and I missed it but when I looked at that post you linked I didn't recall seeing it).

They got type generators which somewhat influenced and predates the Source Generator feature by a few years. Not the same thing of course, and from what I've seen are slightly different in target/scope. (e.g. F#'s seems more appropriate for scripting where you can use it without a proj entry).

Do you mean type providers? That's their own type of nice thing but to your point it is only for generating types, source generators can generate much more than a basic type. Also I swear I saw somewhere type providers were not functioning as well in newer .NET but that was hearsay as I never tried them in 5 and now 6.

They are working in .NET 5 last time I checked. Opened an FSX script, "#r: nuget SwaggerProvider", point to a JSON API and it seems to work with IDE auto complete included with 2 lines of code, no project scaffolding, or package manager files required. Things seem to be improving on this front I guess as well.

I do agree - source generators have a better API as an implementer and can generate more than classes. I guess as soon as I need to jump into a proj file and I'm working with MsBuild anyway what stops me creating my own generation framework that runs before PreBuild that generates code for my compile step? I've done it before source generators were a thing.

I also did a quick Google search - Myriad (F# library) might be something that does something similar.

Oh Myriad looks super interesting. As I figure out what I want to do as I pick f# back up more seriously I'll have to keep this in mind.

F# is the reason I'm investing in .Net. So far it's been an amazing developer experience.

For internal admin tools I can throw together a windows form app in C# much quicker than any other system I've worked with. I'm pretty new to the eco system so to it's amazing how fast you can get up to speed.

Outside of a few very small stumbles, I don't think that Microsoft is a bad steward of open source .NET. Especially if you use Java as the alternative example where there were decades of Sun/Oracle shenanigans around open source Java.

Microsoft has done an amazing amount of work writing and rewriting code to make cross platform open source .NET a real thing. All open licensed and developed in the open.

> Microsoft has done an amazing amount of work writing and rewriting code to make cross platform open source .NET a real thing. All open licensed and developed in the open.

It's fitting you mention all the work Microsoft has done rewriting code. You're talking about .NET itself but I'm talking about the ecosystem, where Microsoft often does take others' projects and release their own version (the Windows package manager comes to mind), training the community to only trust things that come from them. Of course there was the recent famous example of Microsoft deleting public code so they could feature it in Visual Studio, but this tweet is typical of the attitude I've seen from the community: https://twitter.com/GeoffreyHuntley/status/14540569884432179...

This reply doesn't really have anything to do with your original comment. If Microsoft is producing a solid language / framework in the open and improving their product such that 3rd party "light-weight" libraries like Nancy are no longer necessary, why is that a bad thing?

In my opinion, while other ecosystems have exploded in complexity in recent years, the increasing simplicity and batteries-included nature of .NET is an appealing contrast.

That's my answer to your question about why you should be interested in .NET if you're not already in the ecosystem.

> If Microsoft is producing a solid language / framework in the open and improving their product such that 3rd party "light-weight" libraries like Nancy are no longer necessary, why is that a bad thing?

Because they are killing community made solutions by reimplementing the same solution and utilizing community's habit of favoring only MS software that they themselves engraved into that community throughout the years, even if original solution was better, thus closing the circle. They essentially kill the community around .NET themselves because instead of supporting projects like Avalonia, they reinvent the wheel(often ineptly) to ride on that 'Microsoft ecosystem' wave. The only exception to that that I know so far has been Polly that they pulled into .NET Core.

If it's all open source, why does it matter? My node_modules folders are a good example of why having thousands of individual open source fiefdoms is not always a good thing.

I don't think the Avalonia example is a good one either. Nobody talks about why Ruby on Rails doesn't support Sintara. In other ecosystems, every project is in competition. Why should .NET be singled out.

I think the argument that open source software can't compete with Microsoft is total bunk. If the alternative is competitive, it can succeed. Dapper has been around for over 10 years. Avalonia is "used by >170,000 companies, including 431 on the Fortune 500 list" according to their own website. Xamarin joining Microsoft is pretty much why we're talking about .NET 6 right now. Microsoft's first party solutions are really very good (in house or acquired). This is again why you might choose .NET over a more chaotic ecosystem.

C# is fast and .NET core is cross-platform. It's good for games, web, and mobile development. F# is a great functional programming language. There are fun tools like SignalR (easy websockets), Blazor (write C# and run it in the browser through WASM), and LINQ (built right into the language and allows you to query objects like a database).

Toplevel programs should make it easier to experiment with C# if you're interested. We also have first-class support for C# commands in https://ab.bot if you just want to play around with the language and make a fun Slack bot or something, although it might take us a week or so to get move up to .NET 6.

> and LINQ

Shudders at memories of coworkers writing giant, ridiculously inefficient LINQ queries without understanding how it's actually using the database and what it's doing server-side

> Toplevel programs should make it easier to experiment with C# if you're interested.

Definitely interested in that small feature :) If I had extra time I'd like to see what it takes to brew install dotnet and write a simple CLI program. Can .NET deploy a static binary nowadays?

True of nearly all ORMs really. LINQ on objects basically makes C# a very nice functional language. Dapper is arguably better for database but then use LINQ in those results is very nice.

I almost wish they hand't wrapped IQueryable and IEnumerable under the same branding. I get that there's a lot of overlap at the interface level, but, in terms of what they're doing under the hood and the effect on how you use them, they're really quite very different.

> True of nearly all ORMs really.

I disagree in a respect. I think with an ORM it's clear when you're hitting the database, though it makes it easy to write loops over (related) rows ("n+1 problem"). I think with LINQ using the same syntax/expressions across local and remote operations it can be more blurred what's happening.

> Can .NET deploy a static binary nowadays?

You can bundle everything in a single file but that file contains the runtime, so even small Hello World apps are 50MB+ last I checked, though there have been some improvements recently with trimming and AOT is hopefully coming next year with .NET 7.

Very cool, thanks for answering. Yeah I understand they'd have to bundle the runtime so that makes sense. Glad to know they're working on improving that use case as well.

They're really working on reducing the compiled (app + framework) size in order to make the WASM target in browsers more viable for Blazor.

Yeah, starts closer to 12MB for a trimmed console app in .NET 6. It works really well (I've been distributing one for a few months now).

LINQ is best when used on in-memory object graphs, partly for the reasons you brought up, and partly because then you're not dealing with weird limitations or deviations from how functions normally work etc. For in-memory queries, it's basically just a very advanced form of sequence comprehensions.

(I also suspect that the vast majority of LINQ code in the wild is of that variety, rather than Entity Framework etc.)

> Can .NET deploy a static binary nowadays?

You can, as sbelskie mentioned below. In .Net 6, it's available as a Preview [1]. But it's going to ship with the main framework in 7.0 [2].

The preview works quite well. You can build self-contained, smaller executables, and shared libraries callable from say, C code.

[1]: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/...

[2]: https://github.com/dotnet/runtime/issues/61231

Depends what you're after. The only correct advice for "what to do a project in" if you're looking to ship and/or make money is "use what you know" so any advice beyond that is heavily contextual.

There is no killer feature for .NET I think. That's why it's a hard sell. I think its sales pitch is more or less parallel to Java (though I prefer C# to Java and VS to IntelliJ).

Do you want a statically typed, extremely fast, cross-platform language with a comprehensive standard library and huge ecosystem of 3rd party packages with almost unrivalled devX (Rider on non-Windows OSes) and streamlined packaging and deployment that allows you to scale from single person PoC to large team development within the same codebase with no additional overhead?

I'd note that it's a bit of a jack-of-all-trades when it comes to desktop and ML. The ML.NET package keeps getting better but for those areas where there's an obvious standard, e.g. Python for ML, you may as well use the standard for that thing. The desktop story continues to disappoint and I'd advise people to steer clear of desktop unless they want a nasty surprise. But for web applications I'd not want to use anything else.

>I'd note that it's a bit of a jack-of-all-trades

And that's why developers and companies like it. It is a good, easy to use, well supported, well documented, sane jack-of-all-trades.

I've spent much of my money-making programming time doing CRUD web apps in PHP. Several years ago, when .NET Core was in its infancy, I had the chance to try a different language for a new/different CRUD web app.

The .NET Core ecosystem was a lot sparser back then but picking up the language was actually the most pleasant "learn a new language and be productive in it" experience I've ever had, and I don't think I'd ever turn away from it now. YMMV, of course, depending on how much you like whatever you're writing in now.

> I don't see any particular reason to make my own tools in C# vs anything else.

I can tell you why the company I work for uses C# to develop microservice based products:

-cross platform

-tons of libraries

-integration with most of the things we need

-great speed

-good productivity

-great tools

We can iterate fast, have performance. Also, C#/.NET is good for other purposes such as mobile apps, frontend, writing glue code, and even desktop if the need arises.

MAUI, maybe?

https://github.com/dotnet/maui

Based on past experience it’s a very very very bad idea to rely on anything that MS does in the desktop development area. I would be shocked if MAUI wasn’t dead in five years.

C# is good for game development, building applications with sockets or creating small GUI applications. Though I admit that I have a bias since C# was the first language that I learned to program with. Plus C# has garbage collection and multithreading!

> I certainly wouldn't feel comfortable to say to my team "let's do this next project in C#".

Could you expand a bit on that?

I used .Net 1.1 and 2.0 for awhile, and coming back to it now while deciding the future path for our application.

I left .net around the 2.0 days and came back with .net core 5.0. It's a world of difference, and absolutely worth checking out again. If anything, you don't need Windows to run it, and there's great tooling support outside of Visual Studio (VS is still pretty nice though).

Probably not.

I've heard the more recent releases of .NET have been pretty good, but I don't see any real reason to be interested in it. There are already plenty of good options out there.

Low/No code solutions are really eating the lunch of where C# was useful in large internal apps. I use it because F#, but it’s getting harder to sell that.

As someone who programs with .NET in their day job...no probably, not.

Outside of a few areas related to DDD, event sourcing, and some distributed-system frameworks (NServiceBus and MassTransit) there's really no killer app for .NET, in my opinion.

The big selling point for .NET now is that it runs on Linux...which is not really a selling point in the grand scheme of things.

ASP.NET Core is an excellent and high-performance general purpose web framework.

Blazor is an excellent C# on the browser stack.

And MAUI will target React Native (native controls) and Cordova (Blazor on Maui) at the same time ... which is extremely powerful. But that is half a year out.

.NET has a lot to offer if you take individual app models of it. If you want to stick in one language, it is even a top contender.

Linux selling point is already gone. That is standard already for 5 years now.

> If you want to stick in one language, it is even a top contender.

That's why I like it. Not only being able to do tons of stuff with one language, but using the same frameworks and libraries.

I'd say the ability to run on Linux is a major selling point. Without this, I think .NET would have largely disappeared.

Reply on news.ycombinator.com