5 ms·

My discussion was intended to be about two things: - is function coloring better than alternatives? - is it possible to interact with APIs that require they b

My discussion was intended to be about two things: - is function coloring better than alternatives? - is it possible to interact with APIs that require they be called from a specific UI thread using those alternatives? The answers are resoundingly “no” and “yes”. The point is that I think C# should at some point adopt lightweight preemptible threads similar to goroutines for the benefits, not that you need to switch to Go for GUI apps on Windows. I don’t agree at all that function coloring for async is a benefit, or that poorly written tasks being able to block the executor is a benefit, which is what the GP basically argued. C# is a good language, but defending function coloring feels the same as those Go developers who defended not having generics for years. It’s important to be able to recognize the shortcomings in languages so that improvements can be made. Generics will be a benefit to the Go language, even if it took a surprisingly long time to materialize. Async in C# is better than what it had before, but that doesn’t mean it is perfect. To your question more directly, Go’s runtime automatically uses the underlying native async APIs in most places where it makes sense in the standard library. WinRT probably isn’t used by Go, but I haven’t ever looked. If you’re specifically referring to UI APIs, then this is irrelevant to the discussion, because I’m not saying you should switch to Go for that. Plus, Google doesn’t care about using native windows GUI APIs from Go, so it probably wouldn’t fit your definition of “natural”, since I doubt anyone has put in the effort to clear that bar.

int_19h 5y ago
Function coloring is what allows WinRT to be a language-agnostic async API (whether we're talking about UI or not is immaterial - it's all async). I'm well aware of the shortcomings of coloring, but the point remains that it's the only way to do async that does not result in insular ecosystems with a penchant to rewrite everything so as to gain the benefits of their bespoke green threading (i.e. exactly like Go). This may change if we can even standardize green threads on OS level, such that all languages can target it in an interoperable way. But the experience with the adoption (or rather lack thereof) of fibers in Win32 shows just how difficult this can be.

int_19h 5y ago

Function coloring is what allows WinRT to be a language-agnostic async API (whether we're talking about UI or not is immaterial - it's all async). I'm well aware of the shortcomings of coloring, but the point remains that it's the only way to do async that does not result in insular ecosystems with a penchant to rewrite everything so as to gain the benefits of their bespoke green threading (i.e. exactly like Go). This may change if we can even standardize green threads on OS level, such that all languages can target it in an interoperable way. But the experience with the adoption (or rather lack thereof) of fibers in Win32 shows just how difficult this can be.