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

81–90 of 133 posts

Re: Promises are not neutral enough

#81

Post by naasking »

woah wrote: post #65
_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…

I have to agree. This blog post comes from a place of judging what is "better" by some arbitrary abstract metrics (hint: the author's own library wins this contest). It doesn't consider what programmers use them for. Promises are meant to semantically (and with async/await, syntactically) resemble a function call as closely as possible, while minimizing confusing errors. The author's "improvements" would ruin this. I…

> This blog post comes from a place of judging what is "better" by some arbitrary abstract metrics

Or you could consider the possibility that they aren't arbitrary at all. Perhaps these properties are well motivated by, for instance equational reasoning, which is a cornerstone of extensible and maintainable programming.

> Promises are meant to semantically (and with async/await, syntactically) resemble a function call as closely as possible, while minimizing confusing errors

Why? What purpose does that ultimately serve given we already have functions? The whole point of an abstraction is to provide sophisticated semantics to do an important job you would otherwise have to do by hand.

Re: Promises are not neutral enough

#82

Post by fiatjaf »

codedokode wrote: post #77
fiatjaf wrote: post #69

Earlier quoted context omitted.

In Go there are two ways you can handle wrong things happening: - return an error - panic What is the recommended, best, pretty, beautiful way? Return an error. Nobody uses panic. Javascript Promises are equivalent to that. If you want to stop the main program, call process.exit(). That would be the equivalent of panic.

I don't think it is beautiful. This fills program with lots of unnecessary `if`s for checking results of each call. Also, it prevents one from chaining functions like a(b(x)).

Yeah, you're right. Not beautiful and prevents chaining. But works like a charm, don't you think?

Chaining functions is for functional people. Go is proudly imperative.

Re: Promises are not neutral enough

#83

Post by tonyg »

rictic wrote: post #23
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 is a fundamental issue with multitasking, in that an independent task will have its own stack, so errors can't propagate up the stack of the function that started the task. e.g. consider this python code: def start_task(): Thread(do_task).start() What happens if do_task throws an exception? The exception can't propagate up from start_task because start_task may have returned when the exception is thrown. At some…

Erlang's links http://erlang.org/doc/reference_manual/processes.html#id8861... are an interesting approach to this problem of failure signalling in a concurrent system. Stack-oriented exception handlers certainly don't work properly with concurrency.

Two Erlang processes (~actors) can be linked together. If one then crashes (uncaught exception), the other one is automatically killed - unless it takes special steps to "trap exits", in which case it is sent a message describing the failure in its linked peer.

Re: Promises are not neutral enough

#84

Post by noobermin »

_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…

Whenever some calls something else opinionated, you have to be aware they probably mean it just doesn't square with their opinion.

Re: Promises are not neutral enough

#85

Post by kazinator »

The whole idea of cancelation is poor; it shouldn't even be a feature.

The way you avoid unnecessary computation, when you have laziness, is to just roll it into the lazy semantics.

Have it so that if the promise generates something complicated, like a sequence, that the promise only generates as much of that something as is accessed (and maybe only a little bit beyond that).

In other words, the async promises should perhaps behave not so differently from synchronous lazy mechanisms.

The two are flipsides of the same coin. Say I have a synchronous lazy list (of strings). The strings come from reading a file. Ah, but reading a file is asynchronous at the OS level. So actually the list is asynchronous, in a sense. When we access the first element in the list, a line is read from the file. The underlying stream object reads an entire buffer-sized chunk, though: still synchronously. Moreover the OS behaves asynchronously and reads ahead in the file, caching more of it than the stream library asked for. Of course, the OS doesn't read the whole file (unless it's small). Just a little bit ahead. Enough ahead not to hammer the I/O subsystem with lots of small operations.

We can create this list over a log file that has 100 million lines, then read just the first 100 lines and stop using it. The underlying stream library might read 16K of the file, of which the 100 lines occupies only the first 8. The OS might have read ahead by quite a bit more than that and cached more of the file, and the hard drive's firmware might have buffered an entire track. If we don't read anything more from that list, then the operation is effectively canceled. The OS won't cache any more from the file; the stream library won't buffer more of text stream.

Re: Promises are not neutral enough

#86

Post by lilactown »

lugg wrote: post #13
IIIIIIIIIIIIIII wrote: post #5

This may get me in hot water here but... I started working with JS promises specifically when they were barely available in a beta runtime. It took me over a year of working with them to really get a feel for them, now it's been far longer. That's because while you can "understand" the description and use it just fine, but a deeper comprehension and intuition takes much more time. I experimented a lot and insisted on…

Post sounded like they picked up promises over the weekend and didn't like how it broke their C# mold. Quite a few points didn't make any sense or simply showed misunderstanding around how and why promises are what they are. > Eager, not lazy Why does this even matter? It's an implementation detail that optimises for performance. The outcome, eventual resolution, is all that really matters. > No cancellation These ar…

The author is the original author of the streaming library xstream (similar in functionality to RxJS) and Cycle.js.

I believe he's thought a lot about this problem.

Re: Promises are not neutral enough

#87

Post by mstade »

yuchi wrote: post #79
roguecoder wrote: post #41

This article doesn't even touch on the worst sin of JavaScript Promises: they swallow errors and exceptions, which makes them nearly impossible to test correctly and makes debugging horrifying (if you even notice anything is wrong.) Promises are a great example with the problems of believing that something good in one language will be good in another. Promises in JavaScript are fighting the language, because JavaScri…

Promises don‘t swallow errors (sorry to be pedantic but there’s no concept of Exception in JS). They just propagate it to the rejection channel. What was your precise experience?

If there’s no logic to catch the rejection it will be silently ignored, which is effectively the same as “swallowing exceptions” – your distinction is correct but it’s academic at best.

In practice, this behavior causes very real problems and in node land they made the sane decision to kill the process whenever an unhandled promise rejection comes about. I don’t know if this has landed yet, but you’ll see a warning about it if you run a node process in which you reject a promise.

Re: Promises are not neutral enough

#88

Post by strken »

noobermin wrote: post #84
_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…

Whenever some calls something else opinionated, you have to be aware they probably mean it just doesn't square with their opinion.

I think there's a similar but stronger form of opinionation where a choice prevents you from ever implementing something.

In this case, not being able to synchronously resolve a promise prevents you from using them in certain ways. You can attach flatMap to the prototype or build a better way of doing cancellations, but you'll need to make additions to the language itself to turn a promise synchronous, which is what await/async were all about.

Having said all that, the bar for promises isn't set by RxJS, it's set by callback(err).

EDIT: also, promises were very much discovered. They're an opinionated solution to the very specific problems of callbacks. They're chainable because of callback hell. Errors propagate because that's a problem with callbacks. Their execution is always delayed because callbacks made it hard to reason about execution order. They don't handle cancellation because callbacks don't handle cancellation.

Post reply on HN