3 ms·

All of the examples await each and everything. Where does being async become most useful? I can’t think of anything I might want to do really that won’t have me

All of the examples await each and everything. Where does being async become most useful? I can’t think of anything I might want to do really that won’t have me wanting to wait for the previous thing I was saying to Chrome to first complete.

petters 6y ago
You can use this for integration testing. If you have enough memory, you can then run several tests in parallel. Or, of course, if you need to do something with headless chrome while serving a request.
munro 6y ago
Lol someone is still having an async syntax debate? How passé. Essentially programmers want the ability to write concurrent code, without specifying the actual constructs (like threading), and the ouija board of programming community have spoken that explicit syntax is ideal. Promises were cool for a hot second, but then everyone coalesced on async/await. I thought other approaches like Python's gevent were really clever way of handling semantics, but I guess the majority didn't agree, people like explicit. But I will say, this syntax in this Rust library does look odd to me, but I agree 100% that the library made the right choice making it explicitly async. I really wish Selenium in Python used asyncio. You're literally bike shedding on someone's amazing effort.
hansvm 6y ago
> I can’t think of anything I might want to do really that won’t have me wanting to wait for the previous thing I was saying to Chrome to first complete. That's precisely the point. By using async/await you can describe each of the things you want to do as a sequence of steps depending/waiting on previous results, but at the places you'd have to pause anyway (waiting on chromium, a database, etc) you can clearly signal that the machine is free to do other things till it has your results. If you have other tasks you'd _also_ like to be doing then those can be similarly coded with async/await, and they can run during times when the first task would otherwise have been idle (or however they're being scheduled). As an aside, async/await is just a tool to try to make your life easier. It's moderately easy to reason about (each task is sequential after all, and shared structures can only be modified at explicit pause points), the syntax is only mildly more cumbersome than writing the sequential task you were going to write anyway, and it's remarkably easy to write a scheduler to execute an async program with some degree of efficiency. You can absolutely use any other parallel execution model you'd like or none at all as the situation demands.

petters 6y ago

You can use this for integration testing. If you have enough memory, you can then run several tests in parallel. Or, of course, if you need to do something with headless chrome while serving a request.

munro 6y ago

Lol someone is still having an async syntax debate? How passé. Essentially programmers want the ability to write concurrent code, without specifying the actual constructs (like threading), and the ouija board of programming community have spoken that explicit syntax is ideal. Promises were cool for a hot second, but then everyone coalesced on async/await. I thought other approaches like Python's gevent were really clever way of handling semantics, but I guess the majority didn't agree, people like explicit. But I will say, this syntax in this Rust library does look odd to me, but I agree 100% that the library made the right choice making it explicitly async. I really wish Selenium in Python used asyncio. You're literally bike shedding on someone's amazing effort.

hansvm 6y ago

> I can’t think of anything I might want to do really that won’t have me wanting to wait for the previous thing I was saying to Chrome to first complete. That's precisely the point. By using async/await you can describe each of the things you want to do as a sequence of steps depending/waiting on previous results, but at the places you'd have to pause anyway (waiting on chromium, a database, etc) you can clearly signal that the machine is free to do other things till it has your results. If you have other tasks you'd _also_ like to be doing then those can be similarly coded with async/await, and they can run during times when the first task would otherwise have been idle (or however they're being scheduled). As an aside, async/await is just a tool to try to make your life easier. It's moderately easy to reason about (each task is sequential after all, and shared structures can only be modified at explicit pause points), the syntax is only mildly more cumbersome than writing the sequential task you were going to write anyway, and it's remarkably easy to write a scheduler to execute an async program with some degree of efficiency. You can absolutely use any other parallel execution model you'd like or none at all as the situation demands.