4 ms·

Unless you're working on a SOTA HFT application where you're optimising your latency by the nanosecond, I can't see modern .Net/F#/C# being a problem in product

Unless you're working on a SOTA HFT application where you're optimising your latency by the nanosecond, I can't see modern .Net/F#/C# being a problem in production. Given that Bing[1] and Azure Active Directory[2] run on .Net Core/.Net 5, which are among the most used applications on the entire internet, the idea that a medium-large project cant use them is ridiculous. This isn't even just with modern .Net aswell, Microsoft Trill has been running trillions of operations a day on single machines since 2012 as a .Net library [3]. [1] - https://www.bing.com/version https://www.bing.com/version [2] - https://devblogs.microsoft.com/dotnet/azure-active-directorys-gateway-service-is-on-net-core-3-1/ https://devblogs.microsoft.com/dotnet/azure-active-directory... [3] - https://www.microsoft.com/en-us/research/project/trill/ https://www.microsoft.com/en-us/research/project/trill/

daxfohl 6y ago
I used to work in the Azure Resource Manager team and we had big GC issues there. API servers would pause for 200 ms and queues would explode. Workers would grind to a near halt in certain conditions due to GC overload. Granted this was a couple years ago and running dotnet framework, so perhaps things have improved. I think it's likely most of the serious problems there could have been fixed by smarter in memory caching: a few big objects instead of millions of small ones. However the whole experience left a sour taste in my mouth for overly allocation-happy code styles.
- phillipcarter 6y ago
  Do you think that a lot of what you experienced was before widespread use of the Span primitive in the .NET libraries and frameworks? Even if you go to great lengths to avoid GC pauses in your own code, the components you depend on may not have done that and then you're toast. Much has changed in the past 1.5-2 years to eliminate almost all unnecessary allocations across the stack. C# and F# also got compile-time analysis for working with spans, span-like, byrefs, etc. as of 2018 so that you can write some of this code yourself and have a reasonable assurance the the compiler will keep your code from allocating. Coding like this isn't easy either, but it's far simpler than it used to be because of the underlying types an compiler analysis that can help you.
  - daxfohl 6y ago
    Oh, absolutely. In fact I proposed an effort and wrote up a few prototypes to bring those things into ARM codebase while I was there. IDK if any of it ever went anywhere though, as I left the team shortly thereafter.
- motives 6y ago
  "Granted this was a couple years ago and running dotnet framework, so perhaps things have improved" - I think this explains the differences in our opinions on .Net, as I'm from the opposite side of the spectrum having only worked on .Net Core on Linux. From other discussions I've had with people who used older versions of .Net, they seem to share your opinion that it was nowhere near as pleasant of an experience as something like .Net 5. As the other comment mentions, Span<T> has really permeated through core libraries, and the effect is much smoother, more predictable performance, with low memory usage making container based development a breeze.

daxfohl 6y ago

I used to work in the Azure Resource Manager team and we had big GC issues there. API servers would pause for 200 ms and queues would explode. Workers would grind to a near halt in certain conditions due to GC overload. Granted this was a couple years ago and running dotnet framework, so perhaps things have improved. I think it's likely most of the serious problems there could have been fixed by smarter in memory caching: a few big objects instead of millions of small ones. However the whole experience left a sour taste in my mouth for overly allocation-happy code styles.

phillipcarter 6y ago
Do you think that a lot of what you experienced was before widespread use of the Span primitive in the .NET libraries and frameworks? Even if you go to great lengths to avoid GC pauses in your own code, the components you depend on may not have done that and then you're toast. Much has changed in the past 1.5-2 years to eliminate almost all unnecessary allocations across the stack. C# and F# also got compile-time analysis for working with spans, span-like, byrefs, etc. as of 2018 so that you can write some of this code yourself and have a reasonable assurance the the compiler will keep your code from allocating. Coding like this isn't easy either, but it's far simpler than it used to be because of the underlying types an compiler analysis that can help you.
- daxfohl 6y ago
  Oh, absolutely. In fact I proposed an effort and wrote up a few prototypes to bring those things into ARM codebase while I was there. IDK if any of it ever went anywhere though, as I left the team shortly thereafter.
motives 6y ago
"Granted this was a couple years ago and running dotnet framework, so perhaps things have improved" - I think this explains the differences in our opinions on .Net, as I'm from the opposite side of the spectrum having only worked on .Net Core on Linux. From other discussions I've had with people who used older versions of .Net, they seem to share your opinion that it was nowhere near as pleasant of an experience as something like .Net 5. As the other comment mentions, Span<T> has really permeated through core libraries, and the effect is much smoother, more predictable performance, with low memory usage making container based development a breeze.