I would disagree with you on the first point more; Rust is actually perfect for event loop based semantics (we use this in Servo, it's very clean). Ownership fits perfectly with message passing.
You should avoid sharing state when you're using a message passing-based system. The cross-thread communication is handled by the messaging, sharing the messages itself just muddles things further. So the borrow checker disallowing that isn't a bad thing.
> the necessary dependencies (websocket libraries, etc.)
I agree; though the websocket library Servo uses is pretty good (still, not battle-tested, so it's a very valid point).
> it might also not be something that allows to move as much forward in speed as you want for a prototype
Again, with the prototyping thing, sure, it's harder to prototype in Rust, but that's not the whole story -- you spend less time writing tests and debugging.
(Also, I'm not sure how much harder it is; I've never had trouble with doing it and before Rust I was mostly programming in Python/JS)
> Yes - I'm sure the Rust commmunity will disagree with me on the last point
Which sort of indicates that it's probably inaccurate? :)
A lot of the perceived problems with Rust (e.g. fighting the borrow checker) go away after a month or two of actively using the language.
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 - 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.
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?
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 for a POC plugin, which should get RfCd at some point when it's complete).
> 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.
You should avoid sharing state when you're using a message passing-based system. The cross-thread communication is handled by the messaging, sharing the messages itself just muddles things further. So the borrow checker disallowing that isn't a bad thing.
> the necessary dependencies (websocket libraries, etc.)
I agree; though the websocket library Servo uses is pretty good (still, not battle-tested, so it's a very valid point).
> it might also not be something that allows to move as much forward in speed as you want for a prototype
Again, with the prototyping thing, sure, it's harder to prototype in Rust, but that's not the whole story -- you spend less time writing tests and debugging.
(Also, I'm not sure how much harder it is; I've never had trouble with doing it and before Rust I was mostly programming in Python/JS)
> Yes - I'm sure the Rust commmunity will disagree with me on the last point
Which sort of indicates that it's probably inaccurate? :)
A lot of the perceived problems with Rust (e.g. fighting the borrow checker) go away after a month or two of actively using the language.