Argorak

9 ms·

61.
by Argorak 7y ago
> How does this work? Does the runtime tracks duration for each future? There's a watchdog. It's similar to the sysmon thread used in go: https://utcc.utoronto.ca/~cks/space/blog/programming/
62.
Stop worrying about blocking: the new async-std runtime for Rust, inspired by Go(async.rs)
12 points by Argorak 7y ago|2 comments
63.
by Argorak 7y ago
None, I would suggest pushing on the stabilisation of generators ;).
64.
by Argorak 7y ago
We're working on the rest :). Look out for some announcements in the coming days and weeks.
65.
by Argorak 7y ago
Sooo... in standard profile, yes. `async_std::spawn` uses async-stds runtime. Also, our io interfaces (TcpListener, etc.) are effectively bound to our runtime (they need our mio instance in the back). But this cannot made work generically i
66.
by Argorak 7y ago
We don't maintain futures-rs. But for the reasons you outline above (stability), our interface is also effectively done. The choice of not using all of futures for their interface is outspoken the strategy of tokio. We have encouraged
67.
by Argorak 7y ago
You are right, but I also want to point out that we fully buy into the futures-rs interface over custom implementations.
68.
by Argorak 7y ago
> I think the main clash was not about runtime differences but about the interface incompatibility (futures.rs) There is a huge amount of complaints just fundamentally about async-std's existence, though.
69.
by Argorak 7y ago
The position of the async-std project is that people should use _futures-rs_ as the integration point and avoid integrating into tokio or async-std if possible. (both are IO optimised) Especially for things like an actor system, I would rec
70.
The Tide Rust Web Framework(blog.yoshuawuyts.com)
1 points by Argorak 7y ago|0 comments
71.
Announcing Async-Std 1.0(async.rs)
37 points by Argorak 7y ago|6 comments
72.
by Argorak 7y ago
Note that the current implementation still needs thread local state, which is sometimes not available on embedded systems, but this is going away.
73.
by Argorak 7y ago
Rust shines as a language that both allows threaded and async programming, especially by being able to model concurrency issues. But async programming was always hampered by several issues, which made it's own code generation and synta
74.
Save Co.up(yakshav.es)
1 points by Argorak 7y ago|0 comments
75.
by Argorak 7y ago
The stdlib is already just a facade. There's plans to make that more explicit, maybe opening up the way to things like that. But that plan is severely understaffed, we go so much else to do.
76.
by Argorak 7y ago
Yes. E.g. some databases highly recommend using their C library, as they don't consider their protocol specified. That gap might close, but it will stay with us for years.
77.
by Argorak 7y ago
Nerding a bit more, it was a bit late yesterday: this is why the Future takes this weird type called a `Pin`, which is a guarantee that the value does not move in memory while the Future is polled. This is also one of the reasons the featur
78.
by Argorak 7y ago
I'm being dumb, too I misread my owns library API :(. In any case, it's 2:30am here, I'll just had to bed :D.
79.
by Argorak 7y ago
Thank you! :)
80.
by Argorak 7y ago
Any code in Rust is free to bind to FFI and sockets can be gained through `libc`.
81.
by Argorak 7y ago
> async-std has the equivalent of std::net::TcpListener, however it does not appear to actually impl AsyncRead / AsyncWrite. So as of now you can't do anything with it. TcpStream does impl them, at least. It does implement Asy
82.
by Argorak 7y ago
> It's best to treat 'await' as syntactic sugar, and to dig in to the underlying concepts. Slight word of warning: `async/await` is more than just sugar in Rust, it also enables borrowing over awaits, which was previo
83.
by Argorak 7y ago
Correct. It's also common practice.
84.
by Argorak 7y ago
I do Rust since 2013. It did actually had two half-baked runtimes as a compile time mode. It also was constantly crashing and had weird semantic issues. I very much prefer the current state, even if I'm a bit sad that async/await
85.
by Argorak 7y ago
I'm pretty sure that once you don't want `std`, you also want to pick your own scheduler. In this case, you can use the base library (`async-task`) and get started.
86.
by Argorak 7y ago
I wouldn't rely on that. Next step, someone binds to a blocking database driver and you are back at square 1 again. This is definitely not rigorous. I would love to see a lint for known-blocking constructs in async contexts, though: h
87.
by Argorak 7y ago
It does the scheduling for you. That's why all Futures put onto task through `async_std::task` must be `Send`. That's Rust parlance for "can be safely migrated between threads". It's not Go, but we know what people
88.
by Argorak 7y ago
It's similar in some ways, yes. As always, details and labels differ.
89.
by Argorak 7y ago
In small examples like this, you don't gain anything. For the sake of the example, we just run one task. But you _could_ run 100 with them. And at each of those `awaits`, they could schedule differently. For a more complex networked ap
90.
by Argorak 7y ago
Rust async functions are also different here. They don't run the code, they create a Future structure in it's initial state. Contrary to e.g. JavaScript, it doesn't start to run until you end up putting it on an executor. So

More ›