Hacker News new | ask | show | jobs
by kemonocode 1831 days ago
Here's hoping .NET can some day shake off its Windows exclusivity stigma, as I've been writing pretty interoperable C# code for the past 3-4 years or so, and it's been a joy. Night and day compared to Java, at least.

I'll admit it takes some time to get started, but it's smooth sailing once you get past the initial hurdles of setting up your project, understanding some idiosyncrasies when it comes to ASP.NET/Web API/Entity Framework if you're going that route for your backend and such. And now with Blazor, I can even work on the frontend and touch Javascript as little as possible.

8 comments

It's not really about the exclusivity, more so its about being driven by MS and their internal needs and their internal timelines, and nothing will change this. This is not a criticism of MS, .NET is their platform to support their products, it's just a reality. It's the same problem with Swift trying to escape the Apple ecosystem while ultimately being driven by Apple's needs.

So if you're an MS dev whose looking for some additional reach into other platforms, the increased interoperability is great. However for those of us not working on MS platforms, .NET has a huge uphill battle competing with every other platform available to us.

I think this is perceived much worse than it is. I work in a polyglot company. .NET had never limited us compared to the Java, Python, C++ or JavaScript languages we have also in use.

.NET is not tailored to something specific Microsofty. However, the .NET community is still challenged when taking 3rd party dependencies (which is the actual limitation) and then complaints when Microsoft is not delivering the perfect kitchen sink.

I might be in a minority because I write a lot of .NET which in production is almost exclusively deployed on Linux. It's absolutely viable, performance is great, and tool support is fantastic. We agree so far.

However, I have to point out that .NET does have a Windows-only heritage, and as a result, a lot of lower-level APIs (files, processes, signals, pipes, terminals) still have some painful Windows-isms. Fortunately, the situation improves every year, and for a typical server application that exclusively communicates over the network, you're completely fine (and have been for several years now).

Up until very, very recently .NET was absolutely useless on non-Windows platforms, only supporting the bare minimum APIs you need for web apps. It's still not very useful on non-Windows platforms.
Out of curiosity, what is missing in .NET that isn’t being prioritized by Microsoft and that other languages provide?

C# has been pretty groundbreaking, adding features like async await and generators before other mainstream languages.

They are also pushing forward ASP.NET pretty aggressively, even having first class support for gRPC and other popular technologies.

Proper AOT compilation and better handling of low level COM APIs.

NGEN never was anything more than a good enough start-up accelerator, and while .NET supports COM, is cannot directly use COM like APIs like DirectX without some extra help in wrapping.

Every time .NET teams try to improve these scenarios, usually Windows Dev team comes around and steals the show, apparently too much .NET isn't welcomed in some units.

This is how you end up with Longhorn and Midori being sabotaged, or .NET Native being dropped.

>Out of curiosity, what is missing in .NET that isn’t being prioritized by Microsoft and that other languages provide?

First class support for native code. I'm not too sure where their IL stuff is going anyway.

The team quite systematically ignores messaging (as in RabbitMQ and friends). HTTP is covered in all aspects but messaging really lacks behind.
What's lacking? I'm sorry, I last fooled around with message queues like over ten years ago (and it was MSMQ and IBM MQ), but was recently working on a hobby Rpi project where I came close to dinking around with RabbitMQ via Python. It looks like RabbitMQ has a library for .Net. Or are you talking about how the native library System.Messaging is not generic enough to go outside the bounds of MSMQ still? Truly not challenging anything you're saying, just curious to know what you'd prefer to see.
HTTP has a huge infrastructure for translating http request into endpoints. With all the bells and whistles. Nothing is there for messaging. You can get a library for everything but there is no focused stack for processing messages.
SignalR can be used for some applications, but “messaging” is a pretty broad category of different solutions, and I’m not sure what you’d want baked into ASP.NET to accommodate that. HTTP is standardized enough that basically everybody is doing it in very similar ways, but many pieces of a web application are better left for libraries to support.

Is there another mainstream platform with better messaging support without needing libraries that you can name as an example?

I mean, HTTP is a protocol with huge footprint/mindshare/utility to put it mildly. Messaging has.. who can name it? AMQP. I think it would be brilliant if System.Messaging was reoriented to AMQP, especially since MSMQ is not coming back. It's a bit lame that the namespace is locked into to a proprietary and EOL product, for sure.
I’m not sure I follow; why would/should Microsoft make libraries for projects they don’t own?
Because there are two kinds of microservices... HTTP ones and messaging ones. There is a gap.
Could you explain the difference between the two, for nonweb devs?
MassTransit, NServiceBus, ReBus - you have plenty of options.
2nd that, couldn't quite put my finger on it, but this says it nicely.

I want to like what I'm seeing in .net, but there just doesnt seem anything compelling when compared to say Graalvm or even nodejs.

The VM market is very very crowded with fantastic offerings these days, many of which share many commonalities easing dev while each is tailored for a slightly different market.

in the case of .net - xbox.

When it comes to what it is tailored: there are two VM models: CoreCLR optimized for speed and throughout and MonoVM optimized for aot and small size workloads (aka apps and webassembly).

Nodejs is beat by CoreCLR dramatically on its own domain.

GraalVM i have to little insights but CoreCLR beats/equals performance of it java equivalent. I guess you can tweak GraalVM a lot more than CoreCLR because that is an actual weak point of the CoreCLR.

.NET is not tailered to XBox. UWP (which runs Xbox apps) is lacking now 2 versions behind .NET itself.

When you wanted to address unity, that is far more than Xbox.

And gaming is a maybe 20% share of .NET.

This is almost entirely wrong.

.Net is not even close to being driven by Microsoft’s internal needs, for the simple reason that their biggest internal products don’t use .Net.

.Net is far closer to Sun with Java or Kotlin with Jetbrains than Apple with Swift.

That is mostly caused by the internal politics that .NET belongs to DevDiv while C++ has always been part of WinDev.

Back in the early Windows days it was C and C++, then VB came along and it was VB for business while real developers used C++/MFC.

With .NET management tried to create an homogenous runtime, hence why it even supported Managed C++ (replaced with C++/CLI on .NET 2.0).

But they made an huge mistake that persists to this day, splitting the languages across these divisions, thus fuelling their feudal politics.

I've been playing with the AoT compiler and it is decent, especially if you strip the binaries to get 10-20MB files.

Biggest hurdle for me (as a UNIX greybeard, Java survivor and occasional LISPer) is ramping up on idiosyncratic C# syntax and various generations of .NET libraries

But what little I've done in the past couple of months (with .NET 5) works OK in Linux, and the tooling (VS Code + Remote to have .NET on a remote VM at a safe distance from my Mac) suitably lightweight and hassle-free.

(full disclosure: I actually work at Microsoft these days but never developed for Windows alone - did mostly C++ and Java when I targeted it - and never did .NET before, as it only makes sense for me to use it now that I can target Linux)

Java is miles ahead in terms of cross-platform support. .NET applications may be running fine on other operating systems (I write them at $DAYJOB and they mostly do), but the development tooling is absolutely incomparable across OSes. As long as .NET is being developed and pushed by Microsoft, the situation won't change, because it doesn't align with their incentives.

Some people/companies also care about more than the big three operating systems that MS cares to acknowledge. .NET has no official FreeBSD port, for example.

I use jetbrains rider. Tooling on linux is just as good as Windows. Developing .net is far more enjoyable than Java.
Yea Jetbrains Rider is fantastic. I'm assuming the parent never tried it. Seeing as it is essentially IntelliJ the comparison to Java tooling seems ironic.
I second this. .NET core works flawlessly on Linux and JetBrains Rider (and on Mac, which is what I develop on). The standard libraries and ASP.Net core are really well designed and a joy to work with.
Seconding Rider. I use Windows and still prefer it to VS.
On an IDE written in Java....
Rider is a solid mix of C#, F#, Kotlin, and Java (and likely more). The R# engine is a very large .NET codebase, and the F# plugin to that is written largely in F#. So it's a little more complicated than whatever the shell is written in.
.net is catching up very quickly in cross-platform support.

Tooling for. Net is miles ahead of anything else I've witnessed.

As for FreeBSD there's a huge nuance:

> FreeBSD support still requires additional work to implement features that are missing in the runtime to reach parity with the other operating systems. The community will most likely need to do that work in .Net 3.0/3.1 but I would like to see official automated daily builds for FreeBSD restarted with the master (.Net 5) branches of the necessary repos.

As for your statement on Microsoft. I'd trust Microsoft with. Net more than Oracle with Java.

Where is this FreeBSD quote coming from? Link please, I tried to google it without success.
VS Code is available everywhere and can even connect to remote environments. Visual Studio is on Windows, and there's a Mac version that's slowly getting better.

What other languages stacks provide a much better tooling experience? If you use IntelliJ then you get the same thing with Rider (which is just IntelliJ + Resharper), and the rest are all basically VSCode at this point.

It's been a while since I looked at .Net, but last time I checked it was inferior in terms of multi-platform tooling to many languages.

So take VS Code for example, last I looked you could not build Xamarin apps in it, where as with Go, JS, Dart, etc you can use VS Code to create anything in those languages.

Take a look at Rider, it’s relatively recent, it’s possible you missed it. Basically, it’s Resharper embedded in an IntelliJ IDE, and it’s superb.
Well, perfview, for one. I have to keep a Windows VM nearby just for that thing. It doesn't come in handy every day, but is absolutely indispensable when it does. They have a shitty Linux port which basically doesn't work and receives almost no development.

I should also add that you /can/ dump a dotnet application running under Linux. It's just you can't do anything really useful with it, the best tooling is Windows-only. Clearly shows you their priorities.

Use perfcollect for Linux: https://github.com/dotnet/coreclr/blob/master/Documentation/...

Since that is adapted to use Linux specifics :)

If you're writing Java, you're going to use IntelliJ (unless you're a masochist). Conversely, if you're writing C#, you'll want to use Rider.

Rider is better than Visual Studio at the moment; we'll see what happens if they actually get VS 2022 cut over to be 64-bit, maybe the performance will be back to usable for medium-large solutions.

When I write Java I actually don't ever touch InteliJ because I am not a masochistic.

No support for JNI debugging, no incremental compiler, 10 finger key chords, requires explicit menu actions to display project errors, never stops indexing the world,....

What do you use instead?
Eclipse and Netbeans.
> Conversely, if you're writing C#, you'll want to use Rider.

Sure, that's what I do, and what my friend did before he went to another company where they somehow managed to fuck up the project configuration so bad it was absolutely impossible to deploy from under anything other than Visual Studio. It's using some sort of integrated Azure wizardry, I don't work there and can't pry into their secrets. The thing is, you can't work with that project without a Windows license and a Visual Studio license. MS has zero interest in supporting this use case (can't blame them, I'm just stating the fact.)

And that is the thing right! When you stop understanding the tools, you are screwed. I (as a .NET fanboy) prefer CLI tools anytime over some VS Azure toolbox no one understands).

Azure CLI just works fine without VS.

You can't please everyone all the time.

Rider is my daily driver - no matter what OS I use (primarily Windows/Mac and occasionally Ubuntu.)

the miles you mention are one thing, but performance was always more important to me.

java pendant c# was always much more performance focused than java, having structs, unmanaged c# and c++ interoperability. it took java 16 years or so to accept that structs have their justification.

i also find the c# language much nicer than java. f# versus clojure are both excellent additions and again, f# is the more static and performant while clojure has very nice and inspiring features and aspects. it depends on what one wants here.

finally i think even if java is the larger universe, the .net universe certainly is not small either. if .net would not have taken the cross platform road i would have switched to the java runtime, but happily the opposite happened.

I wouldn’t call it performance, but control. The Java and .NET world focus on different things - the JVM has a very very advanced JIT compiler and due to the programmer not being able to specify all that much about certain aspects of code it has a better chance of optimizing it (similarly to how SQL queries can be made very fast precisely because they are at a high level of abstraction). The CLR provides more control at the expense of less optimization opportunity. This escape hatch is really useful for some programs, but not all of them would benefit from it.
I know. The first time I deployed a .NET application to a box running Linux it was like a great disturbance in the Force :-)
> interoperable C# code for the past 3-4 years or so, and it's been a joy. Night and day compared to Java, at least.

Can you give an example of this interoperability, please? Also -- what was the difference compared to Java that you noticed?

I've mostly been writing backend code which pretty much works just the same whether deployed on Windows and Linux, that's interoperability by default.

With Java the issues came from elsewhere- it was less so the interoperability and more just how messy the whole ecosystem is and how there are some aspects of the language itself (such as the excessive verbosity and the way the standard library is structured) that kept mounting up as little annoyances over time. Kotlin wasn't really an option at the time, either.

It's interoperable by default, unless you add a Windows-specific library like WinForms.
eh, Windows Forms is the default GUI library, this means relying on third party libraries if you want to write cross-platform desktop apps.
There isn't really a "default" GUI library at this point. WinForms and WPF are both rather equal in support. (Arguably WPF gets far more updates than WinForms, most months.)

MAUI (in .NET 6+) will be a first party library for some types of cross-platform desktop apps.

The default "GUI" library for .NET Core has always been web.
What's the cross platform GUI situation like on .NET? I know MAUI won't work on Linux, and no Linux support is a deal breaker for me.

F# is really nice, and I enjoy using it for web related things, but I have to reach for different languages if I'm looking to build a GUI right now.

Perhaps developers should still consider .net as windows-only. Given how the large the runtime is and it's creator's reputation for pushing malware, I would not dare run .net core directly in any of my machines, and many non-windows users would probably feel the same. I don't think I even have the option in openbsd. Targeting Linux though I guess makes sense because of containers.
They played games for so long with keeping it closed source and then only opening parts of it to ECMA and then advocating Mono before finally opening more parts of it. I wanted to play with LINQ back then and couldn't. So non-MS people said screw it and moved on.