26 ms·

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

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.

oaiey 5y ago
The team quite systematically ignores messaging (as in RabbitMQ and friends). HTTP is covered in all aspects but messaging really lacks behind.
- aksss 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
        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 5y ago
      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 5y ago
  I’m not sure I follow; why would/should Microsoft make libraries for projects they don’t own?
  - oaiey 5y ago
    Because there are two kinds of microservices... HTTP ones and messaging ones. There is a gap.
    - atatatat 5y ago
      Could you explain the difference between the two, for nonweb devs?
      - oaiey 5y ago
        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 5y ago
  MassTransit, NServiceBus, ReBus - you have plenty of options.
pjmlp 5y ago
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 5y ago
>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 5y ago

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

aksss 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
    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 5y ago
I’m not sure I follow; why would/should Microsoft make libraries for projects they don’t own?
- oaiey 5y ago
  Because there are two kinds of microservices... HTTP ones and messaging ones. There is a gap.
  - atatatat 5y ago
    Could you explain the difference between the two, for nonweb devs?
    - oaiey 5y ago
      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 5y ago
MassTransit, NServiceBus, ReBus - you have plenty of options.

pjmlp 5y ago

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 5y ago

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