Comment by debugnik

Comment by debugnik 20 hours ago

> Languages that don't make a syntactical distinction (such as Haskell) essentially solve the problem by making everything asynchronous

What the heck did I just read. I can only guess they confused Haskell for OCaml or something; the former is notorious for requiring that all I/O is represented as values of some type encoding the full I/O computation. There's still coloring since you can't hide it, only promote it to a more general colour.

Plus, isn't Go the go-to example of this model nowadays?

gf000 20 hours ago

Haskell has green threads. Plus nowadays Java also has virtual threads.

Reply View 3 replies

debugnik 20 hours ago

And I bet those green threads still need an IO type of some sort to encode anything non-pure, plus usually do-syntax. Comparing merely concurrent computations to I/O-async is just weird. In fact, I suspect that even those green threads already have a "colourful" type, although I can't check right now.

Reply View | 2 replies
- iviv 16 hours ago
  
  Pure actions can be run in parallel with https://hackage-content.haskell.org/package/parallel/docs/Co...
  Impure actions use the IO monad like always in Haskell: https://hackage.haskell.org/package/base-4.21.0.0/docs/Contr... (or the higher-level async library)
  I suppose an extreme version of the function coloring argument could be that all types are colors.
  
  Reply View | 1 reply
  
  debugnik 13 hours ago
  
  In a sense, kinda? The function colour problem is that you can't call an async API from a non-async caller without modifying the entire call chain (or blocking the full thread). In async/await languages the conflict comes from changing the return types; the syntax is orthogonal.
  Maybe in practice some properties of code are better off being whole-program than represented as types, even if they're less modular or harder to check.
  Also thanks for the reference, I haven't touched Haskell in ages; I'm more of an F# and OCaml guy.
  
  Reply View | 0 replies