4 ms·

Just for the reference: I'm building similar systems professionally (and have done that with most mainstream programming languages on the market), and I was pro

Just for the reference: I'm building similar systems professionally (and have done that with most mainstream programming languages on the market), and I was probably the first one who explored async IO and eventloops in Rust (https://github.com/Matthias247/revbio https://github.com/Matthias247/revbio - but I'm not really proud of it) - so I think I'm at least halfway qualified to talk about this. And unfortunatly by experimenting with these things I really got the fealing that these problems don't expose the best side of Rust. Wrapping lots of types into stuff like Rc<RefCell<T>> wasn't the greatest experience, and the problem that this didn't work with trait objects back then did not increase that either (might have changed). Message passing is a low level primitive, and it's probably a decent solution for communication between threads. However there is also a need asynchronous communication inside a thread (the eventloop thing), for which they are not really useful. Futures/Promises/Observables are great for both use cases (and imho even greater in a singlethreaded environment). These are definitly harder to implement in Rust - and if you don't believe me just check out how many good implementations are currently available in Rust vs. other languages. How does the eventloop design in Servo look like? Wasn't that some integration with Spidermonkey? I agree that in Rust you will spend less time on writing tests and debugging - but this applies also for a lot of other statically typed languages which bring in a better ecosystem for that task.

kibwen 11y ago
> this didn't work with trait objects back then did not > increase that either (might have changed) I believe the feature that you're referring to is called "DST coercions", which has been available in stable Rust since 1.2. See an example here: https://play.rust-lang.org/?gist=ff8bed62730d54c329f2&version=stable https://play.rust-lang.org/?gist=ff8bed62730d54c329f2&versio...
- Matthias247 11y ago
  Yes, that was missing back then. But also including the ability to do checked upcast/downcasts in the results, do change between Rc<RefCell<Base>> and Rc<RefCell<Derived>>. Is this now possible?
Manishearth 11y ago
Ah, async I/O with event loops is a different thing. I thought you were talking about the event loop based model of concurrent programming. I haven't used mio/mioco (the current async I/O solution for Rust: https://github.com/carllerche/mio/ https://github.com/carllerche/mio/, https://github.com/dpc/mioco https://github.com/dpc/mioco), but I've heard good things about it. They seem to interact with safety pretty cleanly. Rust in 2014 was a very different language. It looked the same at the surface, but a lot of the innards (including the fact that it shipped its own async I/O solution!) have changed since then. > might have changed It has. Though the explicitness of Rc<RefCell<T>> is still there, since Rust prefers ownership and mutability implications to be explicit. Not much extra typing, and you can always typedef it. > a need asynchronous communication inside a thread Agreed. There are some coroutine libraries in Rust which are pretty nice. There is active effort towards having coroutines inside the language itself (see https://github.com/erickt/stateful https://github.com/erickt/stateful for a POC plugin, which should get RfCd at some point when it's complete). See also: https://dwrensha.github.io/capnproto-rust/2015/05/25/asynchronous-io-with-promises.html https://dwrensha.github.io/capnproto-rust/2015/05/25/asynchr... (uses mio) > How does the eventloop design in Servo look like? Wasn't that some integration with Spidermonkey? Like I mentioned, I meant the event loop model of communication. We have a lot of message passing between threads, many of which are event loops. The script thread does feed events into its own event loop (after all, JS is event looped, we need to mirror that), and it works pretty well. We do some gymnastics for thread safety (especially because the Javascript GC is involved) but the interface is safe and clean. > but this applies also for a lot of other statically typed languages which bring in a better ecosystem for that task. Sure, but these languages don't have quick prototyping either. Except perhaps Go. Rust doesn't really end up with an additional burden on prototyping over any other similar statically typed language; the borrow checker is something you rarely tussle with once you get used to it.

kibwen 11y ago

> this didn't work with trait objects back then did not > increase that either (might have changed) I believe the feature that you're referring to is called "DST coercions", which has been available in stable Rust since 1.2. See an example here: https://play.rust-lang.org/?gist=ff8bed62730d54c329f2&version=stable https://play.rust-lang.org/?gist=ff8bed62730d54c329f2&versio...

Matthias247 11y ago
Yes, that was missing back then. But also including the ability to do checked upcast/downcasts in the results, do change between Rc<RefCell<Base>> and Rc<RefCell<Derived>>. Is this now possible?

Manishearth 11y ago

Ah, async I/O with event loops is a different thing. I thought you were talking about the event loop based model of concurrent programming. I haven't used mio/mioco (the current async I/O solution for Rust: https://github.com/carllerche/mio/ https://github.com/carllerche/mio/, https://github.com/dpc/mioco https://github.com/dpc/mioco), but I've heard good things about it. They seem to interact with safety pretty cleanly. Rust in 2014 was a very different language. It looked the same at the surface, but a lot of the innards (including the fact that it shipped its own async I/O solution!) have changed since then. > might have changed It has. Though the explicitness of Rc<RefCell<T>> is still there, since Rust prefers ownership and mutability implications to be explicit. Not much extra typing, and you can always typedef it. > a need asynchronous communication inside a thread Agreed. There are some coroutine libraries in Rust which are pretty nice. There is active effort towards having coroutines inside the language itself (see https://github.com/erickt/stateful https://github.com/erickt/stateful for a POC plugin, which should get RfCd at some point when it's complete). See also: https://dwrensha.github.io/capnproto-rust/2015/05/25/asynchronous-io-with-promises.html https://dwrensha.github.io/capnproto-rust/2015/05/25/asynchr... (uses mio) > How does the eventloop design in Servo look like? Wasn't that some integration with Spidermonkey? Like I mentioned, I meant the event loop model of communication. We have a lot of message passing between threads, many of which are event loops. The script thread does feed events into its own event loop (after all, JS is event looped, we need to mirror that), and it works pretty well. We do some gymnastics for thread safety (especially because the Javascript GC is involved) but the interface is safe and clean. > but this applies also for a lot of other statically typed languages which bring in a better ecosystem for that task. Sure, but these languages don't have quick prototyping either. Except perhaps Go. Rust doesn't really end up with an additional burden on prototyping over any other similar statically typed language; the borrow checker is something you rarely tussle with once you get used to it.