4 ms·

But how could they "be a LOT better"? I see this being said, but from what I've seen async handling is generally not very graceful; with that said, Promises ar

But how could they "be a LOT better"? I see this being said, but from what I've seen async handling is generally not very graceful; with that said, Promises are a very simple but powerful API that seem to handle the problem fairly elegantly. That is why I'm surprised. I just don't know what the alternative is supposed to be! Can you point me to a language and a library that you would say does a better job of handling asynchronicity than Promises?

Lazare 9y ago
I think this sums of my issues with promises quite well: https://staltz.com/promises-are-not-neutral-enough.html https://staltz.com/promises-are-not-neutral-enough.html
mercer 9y ago
Elixir, for one. It's only when I started properly learning other languages than JS that I started seeing how much better a lot of things could be. I say that with a lot of affection for JS, but JS style Promises are among the things that I don't miss. EDIT: To elaborate a bit, what I don't like about (JS) Promises, in hindsight, is that 1) they seem to infect my entire codebase, and 2) making non-async code async is usually nontrivial. In Elixir it's basically a matter of 'telling' a function or an entire module to go do it's thing in another process and report back when done. It means in many cases I only need to change the caller side of things and the code that runs async itself looks the same as the sync code. And that's not even the best part of (Erlang style) processes!