I have seen how Promises' concept was abused in a project at work. All the promises were just returning Future objects, and they were exposed everywhere. And, in case a future fails for some reason, there was no way to have a new Future: all users were doing future.get, resulting in an exception thrown to the caller.
What a mess.
How do Promises Work?
11–20 of 91 posts
Re: How do Promises Work?
#12Earlier quoted context omitted.
i love elixir actors / golang goroutines, since i don't have to give any special treatment to async operations.
Does elixir solve this problem? http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
Can you clarify?
In golang, by convention, you only ever use asynchronous functions that return values. So there is "only one color." (You also have the option of writing callback spaghetti or implementing promises, but why would you do that?)
In elixir, you have the option of blocking on a Task. So you can do the same thing you do in golang, if you want. I don't know enough about elixir to say what the culture is like around this.
Re: How do Promises Work?
#13Earlier quoted context omitted.
i love elixir actors / golang goroutines, since i don't have to give any special treatment to async operations.
Does elixir solve this problem? http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
Yes. In elixir and erlang, you can call a function without knowing whether it will wait on an asynchronous message. The function you called will not return until the message is received or a timeout is reached.
Re: How do Promises Work?
#14Nicely done, thanks! Still, having to explain a concept as simple as eventual computation reinforces my belief that promises as a whole is broken, and should be done in something that looks like synchronous code with some help of the underlying runtime. (And no, ES7's async is not good enough for me here)
NodeJS: you needed 5% of your code to be async, so we made everything async so you get to write awkward async-but-not-really code for the other 95%, too. That's better, right? At least that's how it's always felt when I've used it for anything non-trivial yet well within its typical set of use cases.
In a typical web API in node that I've seen, by function count I'd say around 60-70% of code is asynchronous.
Re: How do Promises Work?
#15Nicely done, thanks! Still, having to explain a concept as simple as eventual computation reinforces my belief that promises as a whole is broken, and should be done in something that looks like synchronous code with some help of the underlying runtime. (And no, ES7's async is not good enough for me here)
Sounds like a leaky abstraction. Easier to get started with maybe, but woe betide the legion of programmers who make assumptions based on the appearance of synchronous execution only to be left stranded when those assumptions don't hold. Asynchronous execution isn't an unfortunate design choice to be papered over; better to make it as easy as possible to learn and work with.
I am not calling to ignoring the async nature of computing in general, I am calling for better tooling.
The Linux (and other OS'es) kernel handles I/O asynchronously, yet processes using open(2) + friends work quite well and are usually written in synchronous style. That the actual asyncness is hidden in kernel space does in general not lead to bad programs; and whoever needs async in the space of a single process can still use async tools provided by the kernel when needed. That tooling is much better as it leads to simpler code.
I don't see ES7's async support being there yet. Elixir, Go, a number of others: much more.
Re: How do Promises Work?
#16I have seen how Promises' concept was abused in a project at work. All the promises were just returning Future objects, and they were exposed everywhere. And, in case a future fails for some reason, there was no way to have a new Future: all users were doing future.get, resulting in an exception thrown to the caller. What a mess.
Hmm, I never got into using Promises. Jumped directly into Rx* and Observables.
Re: How do Promises Work?
#17I have seen how Promises' concept was abused in a project at work. All the promises were just returning Future objects, and they were exposed everywhere. And, in case a future fails for some reason, there was no way to have a new Future: all users were doing future.get, resulting in an exception thrown to the caller. What a mess.
Hmm, I never got into using Promises. Jumped directly into Rx* and Observables.
...okay?
Re: How do Promises Work?
#18Earlier quoted context omitted.
Sounds like a leaky abstraction. Easier to get started with maybe, but woe betide the legion of programmers who make assumptions based on the appearance of synchronous execution only to be left stranded when those assumptions don't hold. Asynchronous execution isn't an unfortunate design choice to be papered over; better to make it as easy as possible to learn and work with.
I am not calling to ignoring the async nature of computing in general, I am calling for better tooling. The Linux (and other OS'es) kernel handles I/O asynchronously, yet processes using open(2) + friends work quite well and are usually written in synchronous style. That the actual asyncness is hidden in kernel space does in general not lead to bad programs; and whoever needs async in the space of a single process ca…
Apples and oranges. You're describing a platform where it's considered acceptable for programs to block on IO and jump through hoops in rare cases where that's absolutely not ok. A set of assumptions that maybe still made sense 30 years ago, and also a leaky abstraction, but one we've become accustom to working around.
If you want that in JavaScript, you can have it; promises were created on the assumption that asynchronous logic is desirable as a matter of course.
Re: How do Promises Work?
#19Nicely done, thanks! Still, having to explain a concept as simple as eventual computation reinforces my belief that promises as a whole is broken, and should be done in something that looks like synchronous code with some help of the underlying runtime. (And no, ES7's async is not good enough for me here)
NodeJS: you needed 5% of your code to be async, so we made everything async so you get to write awkward async-but-not-really code for the other 95%, too. That's better, right? At least that's how it's always felt when I've used it for anything non-trivial yet well within its typical set of use cases.
Despite the downvotes, you are absolutely correct. My feeling, after working on a moderately complex server application in Node is that it was designed for only very simple applications that can be done with one level of callback. I find the "it works this way because its better" cult quite irritating. It works that way because the #*(^#$&^ JS interpreter isn't multithreaded.
Re: How do Promises Work?
#20I have seen how Promises' concept was abused in a project at work. All the promises were just returning Future objects, and they were exposed everywhere. And, in case a future fails for some reason, there was no way to have a new Future: all users were doing future.get, resulting in an exception thrown to the caller. What a mess.
What is the difference between "Promise" and "Future"?
From what I read, it is basically the same thing.