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