Should I care about providing asynchronous calls in my go library? -

i developing simple go library jsonrpc on http.

there following method:

rpcclient.call("mymethod", myparam1, myparam2) 

this method internally http.get() , returns result or error (tuple).

this of course synchron caller , returns when get() call returns.

is way provide libraries in go? should leave user of library make asynchron if wants to?

or should provide second function called:

rpcclient.callasync() 

and return channel here? because channels cannot provide tuples have pack (response, error) tuple in struct , return struct instead.

does make sense?

otherwise user have wrap every call in ugly method like:

result := make(chan asyncresponse) go func() {     res, err := rpcclient.call("mymethod", myparam1, myparam2)     result <- asyncresponse{res, err} }() 

is there best practice go libraries , asynchrony?

the whole point of go's execution model hide asynchronous operations developer, , behave threaded model blocking operations. behind scenes there green-threads , asynchronous io , sophisticated scheduler.

so no, shouldn't provide async api library. networking in go done in pseudo-blocking way code's perspective, , open many goroutines needed, cheap.

so last example way go, , don't consider ugly. because allows developer choose concurrency model. in context of http server, each command handled in separate goroutine, i'd call rpcclient.call("mymethod", myparam1, myparam2).

or if want fanout - i'll create fanout logic.

you can create convenience function executing call , returning on channel:

func callasync(method, p1, p2) chan asyncresponse {     result := make(chan asyncresponse)     go func() {         res, err := rpcclient.call(method, p1, p2)         result <- asyncresponse{res, err}     }()     return result }