Yeah, the janky foundation made me and my boss wish we chose Java for the back-end multiple times. I like async / await (or coroutines in Kotlin-land), it’s easier to wrap my head around than Promises / Futures and I thought I would miss Reactive Programming, but not that much.
Coroutines are indeed much easier to work with, and I find it shocking that they didn’t catch on in Js world. In general though, I find plain sync code is just much easier to reason about and far less error prone. If you can keep IO at the edges, async’s not too bad, but in a lot of cases you need to do some IO deep within your logic, and that’s when things start to fall apart. Now you have to make everything async, error handling in particular becomes a pain. I think having async is nice as an opt in, but it shouldn’t be the default.
Yeah, the janky foundation made me and my boss wish we chose Java for the back-end multiple times. I like async / await (or coroutines in Kotlin-land), it’s easier to wrap my head around than Promises / Futures and I thought I would miss Reactive Programming, but not that much.
Coroutines are indeed much easier to work with, and I find it shocking that they didn’t catch on in Js world. In general though, I find plain sync code is just much easier to reason about and far less error prone. If you can keep IO at the edges, async’s not too bad, but in a lot of cases you need to do some IO deep within your logic, and that’s when things start to fall apart. Now you have to make everything async, error handling in particular becomes a pain. I think having async is nice as an opt in, but it shouldn’t be the default.