8 ms·
I can see where the author comes from. I've been working with ^W^W fighting against Tokio this week, and the error messages are horrible. Representative example
by majewsky 9y ago
I can see where the author comes from. I've been working with ^W^W fighting against Tokio this week, and the error messages are horrible. Representative example:
error[E0271]: type mismatch resolving `<futures::AndThen<futures::Select<futures::stream::ForEach<futures::stream::MapErr<std::boxed::Box<futures::Stream<Error=std::io::Error, Item=(tokio_uds::UnixStream, std::os::ext::net::SocketAddr)> + std::marker::Send>, [closure@src/server/mod.rs:59:18: 59:74]>, [closure@src/server/mod.rs:60:19: 69:10 next_connection_id:_], std::result::Result<(), ()>>, futures::MapErr<futures::Receiver<()>, [closure@src/server/mod.rs:74:18: 74:74]>>, std::result::Result<(), ((), futures::SelectNext<futures::stream::ForEach<futures::stream::MapErr<std::boxed::Box<futures::Stream<Error=std::io::Error, Item=(tokio_uds::UnixStream, std::os::ext::net::SocketAddr)> + std::marker::Send>, [closure@src/server/mod.rs:59:18: 59:74]>, [closure@src/server/mod.rs:60:19: 69:10 next_connection_id:_], std::result::Result<(), ()>>, futures::MapErr<futures::Receiver<()>, [closure@src/server/mod.rs:74:18: 74:74]>>)>, [closure@src/server/mod.rs:78:34: 83:6 cfg:_]> as futures::Future>::Error == ()`
--> src/server/mod.rs:85:15
|
85 | return Ok(Box::new(server));
| ^^^^^^^^^^^^^^^^ expected tuple, found ()
|
= note: expected type `((), futures::SelectNext<futures::stream::ForEach<futures::stream::MapErr<std::boxed::Box<futures::Stream<Error=std::io::Error, Item=(tokio_uds::UnixStream, std::os::ext::net::SocketAddr)> + std::marker::Send>, [closure@src/server/mod.rs:59:18: 59:74]>, [closure@src/server/mod.rs:60:19: 69:10 next_connection_id:_], std::result::Result<(), ()>>, futures::MapErr<futures::Receiver<()>, [closure@src/server/mod.rs:74:18: 74:74]>>)`
found type `()`
= note: required for the cast to the object type `futures::Future<Item=(), Error=()>`
I have hope that things will improve on this front when `impl Trait` lands.
EDIT: After re-reading this, I want to add that I don't mean to hate on Tokio. I like the basic design very much, and hope that they can work out the ergonomics issues and stabilize the API soon.
- kibwen 9y agoCoincidentally, `impl Trait` stabilization was just approved, meaning it should be in the next beta: https://www.reddit.com/r/rust/comments/86f3h6/impl_trait_stabilization_was_just_rd/ https://www.reddit.com/r/rust/comments/86f3h6/impl_trait_sta... . It will be a crucial step forward for Tokio's error messages.
- gnode 9y agoThe grievances you and the article's author mention seem less to do with Rust itself, and more to do with this seemingly horrible futures library. As far as I can tell, it's still in the rust-lang-nursery, which is an indication it's not ready for prime time yet.
- pimeys 9y agoDon't get me wrong, it's a great library! You can do pretty darn fast systems with it, all type-checked and correct. Just don't try to fit in too many things into one thread yet, wait for async/await and non-statical lifetimes in the core.
- reaperducer 9y agoIf we'd all start programming in stable, mature languages instead of letting peer pressure goad us into using betaware and worse, work would be a lot simpler. It would also encourage organizations large and small to start releasing complete, polished products instead of the "move fast and break things" crap that has infected the industry. Imagine if car makers worked the same way.
- alexeiz 9y agoFinally, a language that can compete with C++ on complexity and size of error messages!
- plandis 9y agoThis is still an unstable library (futures and Tokio are both still 0.1 release) actively being developed, in general I tend not to see crazy compile errors working on synchronous projects. FWIF I’ve made a Chip8 emulator with Rust and am working on a Z80 emulator now.
- pimeys 9y agoYeah, sync projects are just pure pleasure to work with. The language is ergonomic, errors are easy to read and tooling is the best ever. The problems right now start when you want to go async. I follow the development because I want to see easy, safe and fast way of writing async programs, and there's lots of interesting development happening with Rust.
- pimeys 9y agoThat's nothing! | 212 | / fn call(&self, payload: Self::Request) -> Self::Future { 213 | | let request = self.create_request(payload); 214 | | 215 | | let work = async_block! { ... | 254 | | FutureResponse(Box::new(work)) 255 | | } | |_____^ note: ...so that the type `impl futures::__rt::MyFuture<<[generator@src/client.rs:215:20: 252:10 self:&client::Client, request:hyper::Request for<'r> {futures::Async<futures::__rt::Mu>, (), fn(std::result::Result<hyper::Response, error::Error>) -> std::result::Result<<std::result::Result<hyper::Response, error::Error> as std::ops::Try>::Ok, <std::result::Result<hyper::Response, error::Error> as std::ops::Try>::Error> {<std::result::Result<hyper::Response, error::Error> as std::ops::Try>::into_result}, futures::MapErr<hyper::client::FutureResponse, [closure@src/client.rs:217:59: 217:85]>, hyper::Response, std::option::Option<std::string::String>, &'r hyper::Response, hyper::StatusCode, fn(std::result::Result<hyper::Chunk, error::Error>) -> std::result::Result<<std::result::Result<hyper::Chunk, error::Error> as std::ops::Try>::Ok, <std::result::Result<hyper::Chunk, error::Error> as std::ops::Try>::Error> {<std::result::Result<hyper::Chunk, error::Error> as std::ops::Try>::into_result}, futures::stream::Concat2<futures::stream::MapErr<hyper::Body, [closure@src/client.rs:234:49: 234:75]>>}] as std::ops::Generator>::Return>` will meet its required lifetime bounds
- vardump 9y agoI see. Rust is aiming to be closer and closer to C++ every day! Anyways, I think it has still long way to go to match the length of even common C++ template related error messages...
- pimeys 9y agoI've definitely seen much worse with C++. These kind of errors you get though when you use Tokio and combine many different futures together, the future wanting to have static lifetimes and me using a reference to self inside an async block, hopefully solved this year.
- thowawayburnout 9y agoI have found while the C++ error messes can be very long, its surprisingly often in the first line of the error message that you see the problem.
- insulanus 9y agoThat is rough, but after looking at C++ template error messages a lot recently, that error message looks pretty sweet!
- swfsql 9y agoThe last tokio re-ergo really helped me and my classmate.. now we are getting stuff done, and we are enjoying it a lot, since we are combining our connections as instances of async state-machines (which, by the way, a given state may be a sub state-machine). This is so awesome.
- xfer 9y agoYeah, i have recently finished a tokio based server. Working with future combinators is very frustrating. I accidentally captured a variable in a closure(should be cloned and moved), and it didn't tell me where it happened, just an error saying requires 'static lifetime for the variable.
- steveklabnik 9y agoThe new async/await stuff will help a lot with this; it'll enable borrowing across futures, which will remove this requirement and make things a lot simpler.
- xfer 9y agoAre there any plans to make them happen this year?
- steveklabnik 9y agoNot just this year, but by the third quarter.
- saghm 9y agoI know this won't help you, but there is an issue tracking this: https://github.com/rust-lang/rust/issues/43353 https://github.com/rust-lang/rust/issues/43353