18 ms·

The downside of c# is it's easy until you run into the 80 flavors of async it has.

• schemescape 4y ago
  What is there besides Task<T>?
  • legulere 4y ago
    First there was APM https://learn.microsoft.com/en-us/dotnet/standard/asynchronous-programming-patterns/asynchronous-programming-model-apm https://learn.microsoft.com/en-us/dotnet/standard/asynchrono... then there came TPL (using Task but without async await but ContinueWith) and finally async await with some later refinements like ValueTask. Generally you just use async await nowadays with maybe the complication of when to use Task or ValueTask
    • vips7L 4y ago
      C# tends to have this problem with multiple ways to do the same thing. Look at construction: var a = new A(); A a = new(); A a = new A();
      • schemescape 4y ago
        When did that second one get added? I haven't written C# in a while, but I don't remember seeing that one. I skimmed the C# grammar and didn't see it there either, but I only glanced and might have missed an entire section.
        • vips7L 4y ago
          C# 9.0: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9#fit-and-finish-features https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... I'm honestly surprised they haven't add the ability to drop the `new` keyword like Kotlin: val a = A();
          • schemescape 4y ago
            Thanks! For anyone else who’s curious, these seem to be called “Target-typed new expressions”.
• api 4y ago
  Async is a wart, period. It’s an ugly hack around poorly scaling threading abstractions. It basically implements light weight threading but in a way that forces the developer to constantly think about it and clutters up the language with ugly complex async crap. Go is the only language that gets concurrency right. Rust async is ugly but it’s ugly because async is ugly and as a systems language there are limits to how much of that ugliness it can hide. If we could fix threads to scale better at the OS or core library level we’d save insane amounts of developer time.
  • ithrow 4y ago
    Async in the nodejs ecosystem seems to be doing perfectly fine?
    • eyelidlessness 4y ago
      async (the keyword) is doing fantastic because it’s better than all of the available alternatives. Those alternatives: - ad hoc callbacks, which had a great Result-ish type signature but really do warrant the “hell” in “callback hell” - Promise APIs, which are semantically equivalent to async the keyword, unless you care about call stacks, and have a lot of the same hellish problems as the ad hoc callbacks they were meant to address (less nesting! same everything else!) - Um fibers? Good luck making sense out of whatever that’s doing. It’s a good idea, but it’s also all opaque magic when you try using it. - Actual threads and child processes… there are valid use cases, and they’re worth pursuing if you have a valid use case, but the facilities for development with them are basically “here’s a bunch of low level concepts that closely mirror their system level counterparts, hope you know/figure out what you’re doing!”
      • ithrow 4y ago
        By async I was referring to node's asynchronous event-driven runtime abstraction which the GP refers to as an ugly hack. I'm not sure if this abstraction is better than all of the available alternatives if you compare it to high-level features multi-threaded runtimes offer like thread-safe collections, atomic updates, concurrent hash maps, immutability, structured concurrency, etc... as in Java/Clojure. Most Java programmers don't work with the low-level thread primitives. The author of esbuild gave up trying to code esbuild with nodejs/worker threads and switched to Go for a less limited/restricted concurrency environment.