| ▲ | andrewstuart 4 days ago |
| I like async and await. I understand that some devs don’t want to learn async programming. It’s unintuitive and hard to learn. On the other hand I feel like saying “go bloody learn async, it’s awesome and massively rewarding”. |
|
| ▲ | marssaxman 3 days ago | parent | next [-] |
| Intuition is relative: when I first encountered unix-style synchronous, threaded IO, I found it awkward and difficult to reason about. I had grown up on the callback-driven classic Mac OS, where you never waited on the results of an IO call because that would freeze the UI; the asynchronous model felt like the normal and straightforward one. |
|
| ▲ | jandrewrogers 2 hours ago | parent | prev | next [-] |
| It is an intrinsic tradeoff. With async there is significantly more code complexity with substantially higher performance and scalability. If you don't need the performance and scalability then it is not unreasonable to argue that async isn't worth the engineering effort. |
|
| ▲ | nottorp 4 days ago | parent | prev | next [-] |
| > It’s unintuitive and hard to learn. Funny, because it was supposed to be more intuitive than handling concurrency manually. |
| |
| ▲ | palata 4 days ago | parent | next [-] | | It is a tool. Some tools make you more productive after you have learned how to use them. I find it interesting how in software, I repeatedly hear people saying "I should not have to learn, it should all be intuitive". In every other field, it is a given that experts are experts because they learned first. | | |
| ▲ | brazzy 4 days ago | parent | next [-] | | > I find it interesting how in software, I repeatedly hear people saying "I should not have to learn, it should all be intuitive". In every other field, it is a given that experts are experts because they learned first. Other fields don't have the same ability to produce unlimited incidental complexity, and therefore not the same need to rein it in. But I don't think there's any field which (as a whole) doesn't value simplicity. | | |
| ▲ | palata 3 days ago | parent [-] | | I feel like it's missing my point. Using a chainsaw is harder than using a manual saw, but if you need to cut many trees it's a lot more efficient to first learn how to use the chainsaw. Now if you take the chainsaw without spending a second thinking about learning to use it, and start using it like a manual saw... no doubt you will find it worse, but that's the wrong way to approach a chainsaw. And I am not saying that async is "strictly better" than all the alternatives (in many situations the chainsaw is inferior to alternatives). I am saying that it is a tool. In some situations, I find it easier to express what I want with async. In others, I find alternatives better. At the end of the day, I am the professional choosing which tool I use for the job. |
| |
| ▲ | nottorp 4 days ago | parent | prev [-] | | Except you're hearing it from someone who doesn't have a problem handling state machines and epoll and manual thread management. | | |
| ▲ | dullcrisp 7 hours ago | parent | next [-] | | Right but how do you expose your state machine and epoll logic to callers? As a blocking function? As a function that accepts continuations and runs on its own thread? Or with no interface such that anyone who wants to interoperate with you has to modify your state machine? | |
| ▲ | palata 3 days ago | parent | prev [-] | | And that was intuitive and easy to learn? | | |
| ▲ | nottorp 3 days ago | parent [-] | | I find state machines plus some form of message passing more intuitive than callbacks or any abstraction that is based on callbacks. Maybe I'm just weird. | | |
| ▲ | palata 3 days ago | parent [-] | | When I did not know how to program, neither async nor message passing were intuitive. I had to learn, and now those are tools I can use when they make sense. I never thought "programming languages are a failure, because they are not intuitive to people who don't know how to program". My point being that I don't judge a tool by how intuitive it is to use when I don't know how to use it. I judge a tool by how useful it is when I know how to use it. Obviously factoring in the time it took to learn it (if it takes 10 years to master a hammer, probably it's not a good hammer), but if you're fine with programming, state machines and message passing, I doubt that it will take you weeks to understand how async works. Took me less than a few hours to start using them productively. |
|
|
|
| |
| ▲ | littlestymaar 4 days ago | parent | prev | next [-] | | It is. A lot. But concurrency is hard and there's so much you syntax can do about it. | |
| ▲ | afiori 4 days ago | parent | prev | next [-] | | Some come to async from callbacks and others from (green)threads. If you come from callbacks it is (almost) purely an upgrade, from threads is it more mixed. | | |
| ▲ | nottorp 3 days ago | parent [-] | | Yeah, that's what annoys me, async comes from people who only knew about callbacks and not other forms of inter thread communication. | | |
| ▲ | josephg 5 hours ago | parent [-] | | Not true. I’ve used both, and I often prefer the explicitness of async await. It’s easier to reason about. The language guarantees that functions which aren’t async can’t be preempted - and that makes a lot of code much easier to write because you don’t need mutexes, atonics and semaphores everywhere. And that in turn often dramatically improves performance. At least in JS. I don’t find async in rust anywhere near as nice to use. But that’s a separate conversation. |
|
| |
| ▲ | shakow 4 days ago | parent | prev | next [-] | | Frankly, async being non-intuitive does not imply that manual concurrency handling is less so; both are a PITA to do correctly. | |
| ▲ | andrewstuart 4 days ago | parent | prev [-] | | It IS intuitive. After you’ve learned the paradigm and bedded it down with practice. |
|
|
| ▲ | Yokohiii an hour ago | parent | prev | next [-] |
| Really? async/await is the model that makes it really easy to ignore all the subtleties of asynchronous code and just go with it. You just need to trial and error where/when to put async/await keywords. It's not hard to learn. Just effort. If something goes wrong, then "that's just how things go these days". |
|
| ▲ | tcfhgj 4 days ago | parent | prev | next [-] |
| I can't follow that it's hard to learn and unintuitive |
|
| ▲ | cmrdporcupine 2 hours ago | parent | prev | next [-] |
| Or... we've learned it and don't like it? For legitimate reasons? |
|
| ▲ | brazzy 4 days ago | parent | prev [-] |
| What's awesome or rewarding about it? It forces programmers to learn completely different ways of doing things, makes the code harder to understand and reason about, purely in order to get better performance. Which is exactly the wrong thing for language designers to do. Their goal should be to find better ways to get those performance gains. And the designers of Go and Java did just that. |
| |
| ▲ | swiftcoder 4 days ago | parent | next [-] | | > It forces programmers to learn completely different ways of doing things, makes the code harder to understand and reason about, purely in order to get better performance. Technically, promises/futures already did that in all of the mentioned languages. Async/await helped make it more user friendly, but the complexity was already there long before async/await arrived | | |
| ▲ | brazzy 4 days ago | parent [-] | | Yes - I was really talking about "asynchronous programming" in general, not the async/await ways to do it in particular. |
| |
| ▲ | tcfhgj 4 days ago | parent | prev [-] | | What different way of doing things? If I want sequential execution, I just call functions like in the synchronous case and append .await.
If I want parallel and/or concurrent execution, I spawn futures instead of threads and .await them.
If I want to use locks across await points, I use async locks, anything else? |
|
