Most of what you'd use promises for in Javascript would be better done
with channels & goroutines in Go, e.g:
resultChan := make(chan SomeType, 1)
go func() {
// do stuff
resultChan <- result
} ()
// do other stuff
result := <-resultChan // wait for the result.
The buffer size of 1 is a common pattern that makes sure that the
sending goroutine can exit without waiting for the result to be picked
up.
Sometimes though, promises are just used to not block other threads,
even when the thread waiting on them doesn't want to do anything in the
meantime. In this case you don't even need an analogue of a promise,
just launch the work to do in a separate goroutine:
go func() {
// do stuff
}()
// do stuff
..no need for promises or other machinery.
-Ian
Quoting clementauger...@gmail.com (2019-03-08 11:48:39)
> hi,
> i might be wrong, it looks likes to me that you want promise in go.
> something like this https://github.com/chebyrash/promise
> I personally don t like this pattern, even in javascript. but anyways,
> example below looks really weird to me and difficult to figure out what
> means to
> "reject but not to return, so the execution continues?"
> https://github.com/Chebyrash/promise/blob/master/examples/http_request/
> main.go
> in this version https://github.com/fanliao/go-promise
> same reject with naked return code that does not speak to me,
> but this https://github.com/fanliao/go-promise#promise-pipelining
> seems to answer one of your request, to quit early before step2.
> by wrapping step1 and step2 in order you might get the expected result.
> I have my own answer, not a promise, to the question, example
> https://github.com/clementauger/st/tree/master/http
> which i like because it helps to eliminate all this dead code that goes
> into my way.
> in the given example i have only one err variable to manage,
> the early return is managed by the pipeline and with all the
> reflections involved,
> the type assertions are gone and I just have to plugin the right func
> types et voil� .
> its not perfect because type errors are runtime fatal but when it is
> setup, i like it.
> in any cases, if i were beginner today, i would start by learning chan
> and go style at first
> before i import patterns from other languages.
> my 2 satoshis.
> Le vendredi 8 mars 2019 14:02:31 UTC+1, whiteh...@googlemail.com a
> écrit� :
>
> I'm really liking in Go that I can easily pass bits of code around,
> 'closures'?� Apologies if I have terminology wrong, since I'm new
> here.
> For a typical asynchronous bit of code I like to pass in a 'func' for
> what to do with the result, and also a 'func' to handle any errors.�
> I'm struggling to find a clean way to achieve a 'non-local return' i.e.
> return from these closures and return the enclosing function too.
> [1]https://play.golang.org/p/_ANPXKRzibq
> I had a look at the plan9 assembly stuff, and starting to suspect that
> it's probably not possible?�
> So I'm wondering how readable my attempt is.� In Objective-C I would
> use named parameters here of 'thenDo' and 'elseDo' to help the
> readability.� And I'm reluctant to try and duplicate that approach
> using a struct in Go.� But I suppose it's the dangling return that I
> least like...
>
> --
> You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [2]golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> Verweise
>
> 1. https://play.golang.org/p/_ANPXKRzibq
> 2. mailto:golang-nuts+unsubscr...@googlegroups.com
> 3. https://groups.google.com/d/optout
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
