3 ms·
> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible
by wiseowise 2y ago
> And, it absolutely should not require creating two identical function definitions to get around the function coloring problem - that's completely indefensible.
Where do you see insanity like this?
- vips7L 2y agoEverywhere in the C# ecosystem. You’ll see things like x.Read() and x.ReadAsync().
- lolinder 2y agoThat sounds more like a legacy problem than a problem with the async/await model in the abstract. If you were designing a language from the ground up, why would you implement a synchronous read operation? I would just assume that all code written in the language will treat async the way that Haskell programmers treat IO and make all IO operations async no matter what.
- vips7L 2y agoThere’s lot of programming models that don’t require async or it’s complexity. Not everything is a web server that needs to serve 100k requests.
- neonsunset 2y agoBecause Read and ReadAsync are usually meaningfully different. There is nothing wrong with that. See https://news.ycombinator.com/item?id=41055328 https://news.ycombinator.com/item?id=41055328 This bifurcation is mostly a concern for the standard library. It’s not something you do this way in your regular application code.
- dragonwriter 2y agoEverywhere that hard function coloring exists where the language also supports synchronous calls that do the same thing (JS doesn't support sunchronous calls for lots of things and has only soft function coloring since async is sugar for Promises, so it has two reasons why that doesn't need to happen.)