Golang: channels are not enough
Given the generalized complexity of getting sync stuff done correctly, I&#x27;m not going to try to bash this out fully in an HN comment, but you can do less-boilerplate Promises (in the sense the term is used in the blog post) by using composition instead:<p><pre><code>    type Promise struct {
        *sync.Condition
        err error
        finished bool
        &#x2F;&#x2F; note no &quot;payload&quot; here with interface{}
    }

    func NewPromise() *Promise {
        &#x2F;&#x2F; return a new promise
    }

    func (p *Promise) Wait() error {
        &#x2F;&#x2F; code here to use the condition and bool to wait, or get the error
    }

    func (p *Promise) Finish(err error) {
        &#x2F;&#x2F; code here to mark the promise as finished or errored
    }

    type AccountPromise struct {
        *Account
        *Promise
    }

    func GetAccountPromise(f func() (*Account, error)) *AccountPromise {
        promise := &amp;AccountPromise{nil, NewPromise()}
        go func () {
            var err error
            promise.Account, err = f()
            promise.Finish(err)
        }()
        return promise
    }
</code></pre>
The boilerplate would only be that last function. The promise is used as:<p><pre><code>    err = accountPromise.Wait()
    &#x2F;&#x2F; accountPromise.Account is now valid if err is nil
</code></pre>
That&#x27;s the reflect-free version. If you&#x27;re still feeling crabby, I believe you could safely reduce the boilerplate even farther with some reflect usage. (By &quot;safely&quot; I mean that you can statically guarantee the loosely-typed reflect usage would still be correct.) That can be used with arbitrary callers of .Wait(), without an explicit queue (shared lock for the condition functions as the de facto queue).<p>Though I still would ask serious questions about Go code that has extensive use of &quot;promises&quot;. Generally I&#x27;d expect there&#x27;s somewhere that sync.Once could be used, or some other solution native to Go rather than porting in promises. You don&#x27;t really need promises in Go; for instance, to head off the objection that I&#x27;m not showing how to do any sort of &quot;.Then()&quot; function so this isn&#x27;t &quot;real&quot; promises, Go&#x27;s code &quot;color&quot; [1] is already fully asynchronous, so you don&#x27;t need the usual array of Promise combiners to create a new function color. Go is already basically promise-colored itself.<p>Not that it&#x27;s perfect. Generics to put together useful channel patterns would be legitimately useful. I&#x27;ve missed that several times.<p>But the composition is generally underrated in Go. The programming community has decades of experience in inheritance-primary language, but composition-primary languages afford a different style, even if both are OO in some sense.<p>[1]: <a href="http:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-your-function&#x2F;" rel="nofollow">http:&#x2F;&#x2F;journal.stuffwithstuff.com&#x2F;2015&#x2F;02&#x2F;01&#x2F;what-color-is-y...</a>