• ☆ Yσɠƚԋσʂ ☆OP
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    2 days ago

    Those are the arguments I’ve seen most commonly as well. In practice, I don’t find they hold up in practice either. The downsides of having a janky foundation for the backend far outweigh any perceived benefits of having a single full stack platform. Also, async style is just far more painful to work with.

    • BlackEco@lemmy.blackeco.com
      link
      fedilink
      arrow-up
      1
      ·
      2 days ago

      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.

      • ☆ Yσɠƚԋσʂ ☆OP
        link
        fedilink
        arrow-up
        2
        ·
        2 days ago

        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.