6 ms·

> I personally don't mind it much, as that explicitness is one of my favourite things about Rust. Rust has operator overloading, so the + operator may call a f

> I personally don't mind it much, as that explicitness is one of my favourite things about Rust. Rust has operator overloading, so the + operator may call a function, I don't call that explicit. For me the 2 first checkmarks of being coloured are what matter most, the author argues that you can work around the third point, but it seems like a huge pain to do routinely. I'm still in the camp that non colored async runtimes are more useful.

nindalf 6y ago
What are some examples of non coloured async runtimes?
- majewsky 6y ago
  One of the more widely deployed ones is Go. Code looks like with synchronous IO, but everything runs in green threads that can be suspended when IO would block. So if you do a File.Read, after it returns, you might be running on a different OS thread because you were suspended mid-Read and later woken up on a different thread. It's generally nice to work with, unless you need to interface with a non-Go library that expects you to use a single thread throughout (e.g. for callbacks), in which case suddenly everything turns into a royal mess.
  - pansa2 6y ago
    > everything runs in green threads that can be suspended when IO would block AFAIK the main objection to this model is that you have to write your code so that it can handle being suspended at any point. OTOH when using async-await, the only potential suspension points are the places marked with `await`.
    - gpderetta 6y ago
      I don't think that's a very strong guarantee though. Trivially you can call any function that can block. Less trivially, any function that you can can resume any other suspended coroutine. So in practice there isn't much you can rely on. In general you can not rely on state that has escaped your function to be unmodified across function calls (although here of course rust has tools to prevent that, but they would work even without the sync/async distinction). It is true that other code can only run at function call boundaries, but that's true for any cooperatively scheduled runtime, even with stackfull coroutines.
    - tedmielczarek 6y ago
      Rust was originally built with green threads. The RFC that proposed removing them has an extremely detailed explanation of why the change was made pre-1.0: https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b1d20284b43f87cbe1c6/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b... I think this has proven itself to be the right decision. It's one of the main reasons that Rust works so well alongside other languages—there's very little default Rust runtime that complicates interop. There are also lots of programming scenarios for which green threads are not the right tool, and Rust accommodates those.
- dathinab 6y ago
  IMHO there are non! Through there are mono colored languages. E.g. go would be mono red. Normally mono blue languages allow you to "emulate" red contexts using callback's, listeners and similar. So some would argue there are no mono blue languages. Many of the points (like red being harder to use) are 100% language impl. dependent. The only think which is generally true about coloring is that mixing colors is a bit harder and sometimes can be sub-optimal for performance. But how much harder depends fully on your programming language and use-case might be negligible. Same is true for performance. Also the two big problem of mono red languages is that while red has less overhead when a lot of parallelism is involved it has more overhaed if little parallelism is involved. And that interacting with other programs using a FFI conceptually harder. Which can lead to a varying degree of complexity and potentially performance drawbacks. But again how much this matters is again very language and use-case dependent. All kind of tooling (including type checking) can reduce the drawbacks of either model (but introduces new drawbacks like longer compilation times). As a side note: Communicating between red and blue functions is only potentially hard when they call each other. In the same way mono-red languages have only problems with external programs if they communicating over a FFI. If things like futures, streams, channels or similar are used (assuming proper implementation) red and blue code can normally communicate just fine, even if run in the same process.
  - jcelerier 6y ago
    > Normally mono blue languages allow you to "emulate" red contexts using callback's, listeners and similar. So some would argue there are no mono blue languages. well, that's exactly what is done in traditional C, C++, Java...
dathinab 6y ago
> Rust has operator overloading, so the + operator may call a function, I don't call that explicit. Not quite right. Rust allows you to implement the + operator for your type, but not to overload it for other types. It furthermore avoids many of the problems other languages (C++) have with it by being more restricted in how you can implement it and strongly discourages any "unusual" usage of it. Lastly there isn't rally any magical about `+` (in difference to some other languages). So `a + b` is just basically the same as `a.+(b)` except that rust doesn't allow symbols as function names so it's `a.add(b)`. So arguing that because rust allows you to implement +/-/etc. it's not explicit is a very flawed argument. Now you could argue that because of how rust's type system works it's not explicit. E.g. does `a.foo(b)` com from a trait implemented for A or is it a method on A? But here rust rejects compilation if it's ambiguous. So it's not a place where implicit creates a problem at all. > I'm still in the camp that non colored async runtimes are more useful. I would argue there are no non-colored async runtimes. It simply can't exist as far as I can tell. At best you can: - Make a language which is mono colored, e.g. all blue or all red. - Make a language which chooses colors for you. But in both cases coloring still exists and you will still run into it when e.g. interacting with a FFI. Also mono colored languages mean you have to use that color.

nindalf 6y ago

What are some examples of non coloured async runtimes?

majewsky 6y ago
One of the more widely deployed ones is Go. Code looks like with synchronous IO, but everything runs in green threads that can be suspended when IO would block. So if you do a File.Read, after it returns, you might be running on a different OS thread because you were suspended mid-Read and later woken up on a different thread. It's generally nice to work with, unless you need to interface with a non-Go library that expects you to use a single thread throughout (e.g. for callbacks), in which case suddenly everything turns into a royal mess.
- pansa2 6y ago
  > everything runs in green threads that can be suspended when IO would block AFAIK the main objection to this model is that you have to write your code so that it can handle being suspended at any point. OTOH when using async-await, the only potential suspension points are the places marked with `await`.
  - gpderetta 6y ago
    I don't think that's a very strong guarantee though. Trivially you can call any function that can block. Less trivially, any function that you can can resume any other suspended coroutine. So in practice there isn't much you can rely on. In general you can not rely on state that has escaped your function to be unmodified across function calls (although here of course rust has tools to prevent that, but they would work even without the sync/async distinction). It is true that other code can only run at function call boundaries, but that's true for any cooperatively scheduled runtime, even with stackfull coroutines.
  - tedmielczarek 6y ago
    Rust was originally built with green threads. The RFC that proposed removing them has an extremely detailed explanation of why the change was made pre-1.0: https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b1d20284b43f87cbe1c6/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b... I think this has proven itself to be the right decision. It's one of the main reasons that Rust works so well alongside other languages—there's very little default Rust runtime that complicates interop. There are also lots of programming scenarios for which green threads are not the right tool, and Rust accommodates those.
dathinab 6y ago
IMHO there are non! Through there are mono colored languages. E.g. go would be mono red. Normally mono blue languages allow you to "emulate" red contexts using callback's, listeners and similar. So some would argue there are no mono blue languages. Many of the points (like red being harder to use) are 100% language impl. dependent. The only think which is generally true about coloring is that mixing colors is a bit harder and sometimes can be sub-optimal for performance. But how much harder depends fully on your programming language and use-case might be negligible. Same is true for performance. Also the two big problem of mono red languages is that while red has less overhead when a lot of parallelism is involved it has more overhaed if little parallelism is involved. And that interacting with other programs using a FFI conceptually harder. Which can lead to a varying degree of complexity and potentially performance drawbacks. But again how much this matters is again very language and use-case dependent. All kind of tooling (including type checking) can reduce the drawbacks of either model (but introduces new drawbacks like longer compilation times). As a side note: Communicating between red and blue functions is only potentially hard when they call each other. In the same way mono-red languages have only problems with external programs if they communicating over a FFI. If things like futures, streams, channels or similar are used (assuming proper implementation) red and blue code can normally communicate just fine, even if run in the same process.
- jcelerier 6y ago
  > Normally mono blue languages allow you to "emulate" red contexts using callback's, listeners and similar. So some would argue there are no mono blue languages. well, that's exactly what is done in traditional C, C++, Java...

dathinab 6y ago

> Rust has operator overloading, so the + operator may call a function, I don't call that explicit. Not quite right. Rust allows you to implement the + operator for your type, but not to overload it for other types. It furthermore avoids many of the problems other languages (C++) have with it by being more restricted in how you can implement it and strongly discourages any "unusual" usage of it. Lastly there isn't rally any magical about `+` (in difference to some other languages). So `a + b` is just basically the same as `a.+(b)` except that rust doesn't allow symbols as function names so it's `a.add(b)`. So arguing that because rust allows you to implement +/-/etc. it's not explicit is a very flawed argument. Now you could argue that because of how rust's type system works it's not explicit. E.g. does `a.foo(b)` com from a trait implemented for A or is it a method on A? But here rust rejects compilation if it's ambiguous. So it's not a place where implicit creates a problem at all. > I'm still in the camp that non colored async runtimes are more useful. I would argue there are no non-colored async runtimes. It simply can't exist as far as I can tell. At best you can: - Make a language which is mono colored, e.g. all blue or all red. - Make a language which chooses colors for you. But in both cases coloring still exists and you will still run into it when e.g. interacting with a FFI. Also mono colored languages mean you have to use that color.