4 ms·

I made this: https://github.com/nkcmr/async https://github.com/nkcmr/async so I can experiment with the idea of Promises in Go. Keep in mind it's experimental a

by nkcmr 5y ago

I made this: https://github.com/nkcmr/async https://github.com/nkcmr/async so I can experiment with the idea of Promises in Go. Keep in mind it's experimental and I've only lightly played around with the pattern.

Zababa 5y ago
That's interesting, I always found Go's handling of asynchronous stuff way better than other languages, especially the ones that relies on async.
- cube2222 5y ago
  For those interested to learn more about Go's handling of async, I wrote a comment a while ago where I describe why I too think the Go model is superior: https://news.ycombinator.com/item?id=27545031 https://news.ycombinator.com/item?id=27545031 EDIT: Superior for most non-performance sensitive use cases, that is.
  - Zababa 5y ago
    I personally prefer Go's handling of async too. I'm not sure if I would call it superior, because from what I understand monadic async has its uses, especially when you don't have a runtime. But for the kind of programming that I do, which doesn't need every last bit of performance, monadic async is a pain. For people not familiar with "monadic async", it's the formal way to refer to the function coloring problem [1]. Monads offer you ways to "lift" your functions/values in the monadic world (paint the blue values red), but you can't do the opposite (paint the red functions/values blue). [1]: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
    - deleted 5y ago
      [deleted]
jerf 5y ago
Go doesn't have much use for promises, and generics won't change that, because channel covers the problem space that promises cover. It is obvious that a channel is not the same thing as a promise. They are quite different in many ways. But the problems that you solve with promises in some languages are solved with channels in Go. There's pros and cons to each, but the cons of channels aren't all that significant in the specific context of Go and there are some compelling pros to the channels in the specific context of Go, so there isn't a very fertile space left over for a promise library. I've already seen half-a-dozen go by (non-generic, but missing generics aren't the problem) and those are just the ones that get posted to reddit. I advise writing Go in Go, and not Javascript in Go. But it's your codebase. (Promises are basically an inner platform [1] for functionality not provided by the base language. Go provides the requisite functionality in the base language. I think I'm more hostile to inner platforms every year, but at least when you're adding capabilities to the base language you can't get any other way there's a debate to be had. Adding an inner platform to get functionality that already exists is just a bad plan.) [1]: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
- xiaq 5y ago
  Promises aren't inherently an "inner platform". You can certainly make them part of the "base language", like Rust. JavaScript didn't have async functions and promises in the beginning, but it integrates with the rest of the language and runtime well enough to not feel like something tacked on (well, at least by the standard of JavaScript language design :). Whether async function + promises is a better model than goroutine + channels is another issue. What you said is accurate in the context of Go though. Having promises in Go will create an "inner platform". If one wants to nitpick, there may be certain workloads that would perform better with async functions and promises, but the design philosophy of Go would happily trade a small amount of performance for simplicity.
  - jerf 5y ago
    "Promises aren't inherently an "inner platform". You can certainly make them part of the "base language", like Rust." That's fair, and I will try to update my internal mental model and stop unconditionally referring to them as such. Thank you. (My primary objection to them is the way they throw away the stack and throw away structured programming as a result, but they're at least less bad if they aren't also an inner platform. :) )

by nkcmr 5y ago

Zababa 5y ago

That's interesting, I always found Go's handling of asynchronous stuff way better than other languages, especially the ones that relies on async.

cube2222 5y ago
For those interested to learn more about Go's handling of async, I wrote a comment a while ago where I describe why I too think the Go model is superior: https://news.ycombinator.com/item?id=27545031 https://news.ycombinator.com/item?id=27545031 EDIT: Superior for most non-performance sensitive use cases, that is.
- Zababa 5y ago
  I personally prefer Go's handling of async too. I'm not sure if I would call it superior, because from what I understand monadic async has its uses, especially when you don't have a runtime. But for the kind of programming that I do, which doesn't need every last bit of performance, monadic async is a pain. For people not familiar with "monadic async", it's the formal way to refer to the function coloring problem [1]. Monads offer you ways to "lift" your functions/values in the monadic world (paint the blue values red), but you can't do the opposite (paint the red functions/values blue). [1]: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
  - deleted 5y ago
    [deleted]

jerf 5y ago

Go doesn't have much use for promises, and generics won't change that, because channel covers the problem space that promises cover. It is obvious that a channel is not the same thing as a promise. They are quite different in many ways. But the problems that you solve with promises in some languages are solved with channels in Go. There's pros and cons to each, but the cons of channels aren't all that significant in the specific context of Go and there are some compelling pros to the channels in the specific context of Go, so there isn't a very fertile space left over for a promise library. I've already seen half-a-dozen go by (non-generic, but missing generics aren't the problem) and those are just the ones that get posted to reddit. I advise writing Go in Go, and not Javascript in Go. But it's your codebase. (Promises are basically an inner platform [1] for functionality not provided by the base language. Go provides the requisite functionality in the base language. I think I'm more hostile to inner platforms every year, but at least when you're adding capabilities to the base language you can't get any other way there's a debate to be had. Adding an inner platform to get functionality that already exists is just a bad plan.) [1]: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect

xiaq 5y ago
Promises aren't inherently an "inner platform". You can certainly make them part of the "base language", like Rust. JavaScript didn't have async functions and promises in the beginning, but it integrates with the rest of the language and runtime well enough to not feel like something tacked on (well, at least by the standard of JavaScript language design :). Whether async function + promises is a better model than goroutine + channels is another issue. What you said is accurate in the context of Go though. Having promises in Go will create an "inner platform". If one wants to nitpick, there may be certain workloads that would perform better with async functions and promises, but the design philosophy of Go would happily trade a small amount of performance for simplicity.
- jerf 5y ago
  "Promises aren't inherently an "inner platform". You can certainly make them part of the "base language", like Rust." That's fair, and I will try to update my internal mental model and stop unconditionally referring to them as such. Thank you. (My primary objection to them is the way they throw away the stack and throw away structured programming as a result, but they're at least less bad if they aren't also an inner platform. :) )