Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Promises are not neutral enough

staltz.com

Post reply on HN
Print view View original

51–60 of 133 posts

Re: Promises are not neutral enough

#51

Post by codedokode »

rictic wrote: post #42
codedokode wrote: post #29

Earlier quoted context omitted.

If you want to have a specific point to catch an exception, you could write something like this: def start_task(): thread = Thread(do_task) thread.set_error_handler(SpecificErrorType, handler) thread.start()

Yes, but this has a natural analogue in promise land: function startTask() { const promise = doTask(); promise.catch((e) => { if (e instanceof SpecificErrorType) { handler(e); } else { throw e; } }); }

The difference is the default behaviour: whether errors are fatal or whether they are ignored by default.

Re: Promises are not neutral enough

#52

Post by codedokode »

camus2 wrote: post #50
codedokode wrote: post #15

I have a feeling the author doesn't understand Promises well. In my opinion, they are in fact designed poorly, but I don't see any problems with points the author describes. He doesn't like that the callback is called immediately - but Promises just represent a result that will be available later and do not guarantee (and should not) when the function will be called. If you want to delay some function call, do it exp…

> This code will just ignore the error. While it is expected that the runtime error would float up and terminate the program - that is what runtime errors are made for. No, this behavior is consistent with how asynchronous programming works in JS. myDiv.addEventListener("click",function(event){ throw "error"; }); Nobody would expect that code to terminate a browser tab on error. > This also makes writing tests more d…

> Nobody would expect that code to terminate a browser tab on error.

That is because browser environment catches all exceptions and displays them in console. So effectively they become handled exceptions.

Re: Promises are not neutral enough

#53

Post by camus2 »

codedokode wrote: post #33
thesmallestcat wrote: post #26

Earlier quoted context omitted.

This is a known footgun of promises. But if you are using async/await, uncaught error in the promise chain is the same as uncaught error inline.

Then the promises should have been advertised as a part of async/await syntax. But many articles promote using them by themselves.

Promises existed way before they were put in the specification and way before async/await. So no, promises could not have been advertised as part of async/await since they came before async/await.

Re: Promises are not neutral enough

#55

Post by camus2 »

codedokode wrote: post #52
camus2 wrote: post #50

Earlier quoted context omitted.

> This code will just ignore the error. While it is expected that the runtime error would float up and terminate the program - that is what runtime errors are made for. No, this behavior is consistent with how asynchronous programming works in JS. myDiv.addEventListener("click",function(event){ throw "error"; }); Nobody would expect that code to terminate a browser tab on error. > This also makes writing tests more d…

> Nobody would expect that code to terminate a browser tab on error. That is because browser environment catches all exceptions and displays them in console. So effectively they become handled exceptions.

> That is because browser environment catches all exceptions and displays them in console. So effectively they become handled exceptions.

No, it has nothing to do with the developer console. It has everything to do with the fact that async exceptions do not bubble up in the main execution thread. Promises work the exact same way since they existed as libraries long before they were included in the language. It's about consistency, nothing more, nothing less.

Re: Promises are not neutral enough

#56

Post by Veen »

tobltobs wrote: post #48

Promises are classic JS clusterfuck. Replace something shitty, like nested callbacks, with something even more shitty. Thereby ignoring 40 years of experiences of other languages.

> even more shitty

I don't think that's quite fair. At worst promises are marginally less shitty than callback hell, so long as you don't go nuts and nest them too deeply.

Re: Promises are not neutral enough

#57

Post by matharmin »

I work with fairly large JavaScript codebases, and the issues mentioned in the post has never been an issue for me. The switch from callbacks to Promises, and later to async-await has made a massive improvement to the ease of writing, reading and maintaining the code. Lazy and cancellable tasks are edge-cases that don't need support in Promises directly. I haven't needed either of those in more than a couple of places in the code, versus thousands of places where Promises are used as is.

I can see the automatic unwrapping of Promises to be an issue in some libraries that want to make specific guarantees, but in most of my code this has behaviour has simplified things.

I definitely prefer having Promises and async-await right now over another theoretically sound (but probably more verbose) system available in a couple of years.

Re: Promises are not neutral enough

#58

Post by matharmin »

spion wrote: post #43
_greim_ wrote: post #19

I don't know. André Staltz is a great programmer, but I can't help but think what seems "opinionated" to him about promises boils down to the fact that they don't perfectly match certain quasi-ideological preferences he has about async programming, at the expense of all other concerns. As he states at the end, promises still work, you can get things done and everything is fine. But the part about them being opinionat…

This has nothing to do with it. I love promises but they are truly limiting. Here is an example of how promises limit the power of mobx https://twitter.com/spion/status/958906847385341952 Another example relevant in node is continuation-local-storage (equivalent to threadlocal storage). Implementing it on top of generators or other "chainable / thenable" abstractions is trivially easy. Implementing it on top of nativ…

Gorgi Kosev's post highlights a very nice use case for generators (database transactions). However, in all my JavaScript over the last few years, that is the only good use case I've found so far in my code base for generators. In all other use cases I've come across, async-await works just fine, and has a much nicer syntax to work with.

Re: Promises are not neutral enough

#59

Post by matharmin »

lilactown wrote: post #49
_greim_ wrote: post #19

I don't know. André Staltz is a great programmer, but I can't help but think what seems "opinionated" to him about promises boils down to the fact that they don't perfectly match certain quasi-ideological preferences he has about async programming, at the expense of all other concerns. As he states at the end, promises still work, you can get things done and everything is fine. But the part about them being opinionat…

The way that promises are implemented actively hurts the ecosystem. Trying to e.g. create a sound typing of the Promise API is really, really hard because of it's auto-flattening nature. This severely hampers languages like TypeScript, Flow & ReasonML that build on top of JavaScript.

It may have been hard, but TypeScript seems to have managed quite well.

Re: Promises are not neutral enough

#60

Post by Const-me »

I don't think the author has experience working with C# tasks.

Technically, the API documentation indeed says a Task has Start() methods i.e. is lazy.

But practically, in the majority of cases they are created already in Running or WaitingToRun state. This applies to tasks returned by asynchronous APIs in the framework, tasks implemented by user-written async methods, and tasks started with Task.Run() static methods. Calling Start() on them will throw an exception complaining about the wrong task state. So, in the current versions of .NET, the tasks are eager just like in JS.

I think the lazy tasks are mostly for backward-compatibility with older .NET framework 4.0 that already had tasks but didn’t support async-await.

Post reply on HN