News for hackers. Stuff that matters.
Re:Rust’s async isn’t colored by dathinab on Thursday March 11, 2021 @08:42AM (#26423902)
> 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.

There are no comments on this comment yet.