[blacktriangle]

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.

[oaiey]

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.

[codeflo]

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

[R0b0t1]

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.

[brokencode]

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.

[pjmlp]

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.

[Bayart]

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

[oaiey]

The team quite systematically ignores messaging (as in RabbitMQ and friends). HTTP is covered in all aspects but messaging really lacks behind.

[aksss]

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.

[oaiey]

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.

[brokencode]

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?

[oaiey]

Agree with what you said. It is a complicated problem.

I do not look into other platforms. I look into my solutions: http i can write my business logic and that is mostly it. On messaging i have to think about threading, acknowledging, dead / poison letters, decoding, trace contexts, etc. And these is all non trivial code especially when done right.

[aksss]

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.

[gionetrix]

I’m not sure I follow; why would/should Microsoft make libraries for projects they don’t own?

[oaiey]

Because there are two kinds of microservices... HTTP ones and messaging ones. There is a gap.

[atatatat]

Could you explain the difference between the two, for nonweb devs?

[oaiey]

It is mainly about non functional needs. A message queue you would use when you have no need in synchronous results, peeks in traffic or want a higher reliability.

If you are ab embedded dev, imagine you want to hand of sensor value to a central service without required immediate response.

If you are a game dev, imagine a play turn result hand off to a central leadership board.

Queues and related Message processing are a tool everywhere not just web development.

[GiorgioG]

MassTransit, NServiceBus, ReBus - you have plenty of options.

[DarkmSparks]

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.

[oaiey]

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.

[oaiey]

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

[addicted]

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.

[pjmlp]

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.