4 ms·

C# is not faster than Rust - but you can get near Rust performance with all the safety and memory management goodness. On benchmark C# is giving go run for its

C# is not faster than Rust - but you can get near Rust performance with all the safety and memory management goodness. On benchmark C# is giving go run for its money! But again, it is easy to get carried away by benchmarks. Go-routines are a killer feature, .Net async/await come with gotchas. The weird space of .Net/.net is because the first 15 or so years - it was hostage to Windows. There by tainting its mind-share and engineering culture. Links (a bit old ones about C# low level chops) https://mattwarren.org/2019/03/01/Is-CSharp-a-low-level-language/ https://mattwarren.org/2019/03/01/Is-CSharp-a-low-level-lang... https://www.youtube.com/watch?v=mLX1sYVf-Xg https://www.youtube.com/watch?v=mLX1sYVf-Xg

briHass 5y ago
> .Net async/await come with gotchas. What are the gotchas? The only snags I see with async/await are when developers don't know what they're doing and try to force async methods to be synchronous with .Result. If you async it all the way down the stack: your web controller methods are async / your program's main is async, you'll have no issues. It's actually great, because you don't even have to know the internals or what it's doing.
- lostmsu 5y ago
  The gotcha is method tainting. You have to duplicate every waiting method if you want to support synchronous and asynchronous API. And it spreads.
- gregmac 5y ago
  There's a performance penalty which happens if you don't need async (eg, if the innermost thing is actually using Task.FromResult), and I've never tested but there's probably some cutoff point where if an awaited operation is faster than x, it's faster to write non-async code (though x may vary by cpu or some other factors). Practicality speaking, this isn't much of a concern for most code, though. I've only really run into this in a couple specific scenarios: unit tests, and when using something like a message bus or cache layer that has a local/in-memory implementation. I noticed only incidentally (as opposed to because of a perf problem): on unit tests where the time got slightly longer when we changed to async, and in the message bus case when doing some performance profiling and using the "local" dev version.
  - jayd16 5y ago
    If there's no actual yield, async/await IS synchronous.
    - int_19h 5y ago
      The method still needs to allocate a Task, though. ValueTask along with more aggressive placement of structs in registers helps with that in more recent .NET versions, but it's still not entirely free.
  - metaltyphoon 5y ago
    Async / Await can actually happen synchronously if there is no yield.
  - kqr 5y ago
    This is principally a throughput-vs-latency thing, right? Async promises better throughput because concurrency, potentially at the cost of latency.
- jayd16 5y ago
  Async/await can do more than goroutines but because of the explicit nature you do need to be more careful. Not being foolproof is certainly a gotcha.

briHass 5y ago

> .Net async/await come with gotchas. What are the gotchas? The only snags I see with async/await are when developers don't know what they're doing and try to force async methods to be synchronous with .Result. If you async it all the way down the stack: your web controller methods are async / your program's main is async, you'll have no issues. It's actually great, because you don't even have to know the internals or what it's doing.

lostmsu 5y ago
The gotcha is method tainting. You have to duplicate every waiting method if you want to support synchronous and asynchronous API. And it spreads.
gregmac 5y ago
There's a performance penalty which happens if you don't need async (eg, if the innermost thing is actually using Task.FromResult), and I've never tested but there's probably some cutoff point where if an awaited operation is faster than x, it's faster to write non-async code (though x may vary by cpu or some other factors). Practicality speaking, this isn't much of a concern for most code, though. I've only really run into this in a couple specific scenarios: unit tests, and when using something like a message bus or cache layer that has a local/in-memory implementation. I noticed only incidentally (as opposed to because of a perf problem): on unit tests where the time got slightly longer when we changed to async, and in the message bus case when doing some performance profiling and using the "local" dev version.
- jayd16 5y ago
  If there's no actual yield, async/await IS synchronous.
  - int_19h 5y ago
    The method still needs to allocate a Task, though. ValueTask along with more aggressive placement of structs in registers helps with that in more recent .NET versions, but it's still not entirely free.
- metaltyphoon 5y ago
  Async / Await can actually happen synchronously if there is no yield.
- kqr 5y ago
  This is principally a throughput-vs-latency thing, right? Async promises better throughput because concurrency, potentially at the cost of latency.
jayd16 5y ago
Async/await can do more than goroutines but because of the explicit nature you do need to be more careful. Not being foolproof is certainly a gotcha.