> Error is only returned by this function when the secret isn't 32 characters so as long as your secret is definitely 32 characters you can safely ignore the err returned by this function.Personal preference, but in this case I'd advise using panic() instead of error. Ignoring errors is rarely a good idea: APIs change, other programmers read their code and don't know about your API, wonder why they ignored the error, &c. You can now also not change your API to ever actually return meaningful errors from that function anymore.
Meanwhile, if the failure mode is so well-defined, just put that in the documentation: "panics if the secret key is not exactly 32 characters long." Let the user of your library worry about it---they will have to, anyway: if they don't, they get an error they have to deal with, and suddenly they're dealing with it after all.
EDIT: From a quick glance, it looks like master gets results back from workers using .Get(<workid>)? Is it easily possible for master to "select" a bunch of workers and get the first completed one? If you use (or at least somehow allow the use of) channels for this, you get all the built-in Go goodness for this kind of control. Even for dynamic number of channels, the reflect package has a dynamic .Select that handles it for you. I.e.: provide a channel that I can <- work results from, and let Go (and the user of your lib) handle the rest. Including timeouts :) select { result, ok := <- workchan: ... ; <-time.NewTimer(3 * time.Seconds).C : <timeout> }.
Personal preference, but in this case I'd advise using panic() instead of error. Ignoring errors is rarely a good idea: APIs change, other programmers read their code and don't know about your API, wonder why they ignored the error, &c. You can now also not change your API to ever actually return meaningful errors from that function anymore.
Meanwhile, if the failure mode is so well-defined, just put that in the documentation: "panics if the secret key is not exactly 32 characters long." Let the user of your library worry about it---they will have to, anyway: if they don't, they get an error they have to deal with, and suddenly they're dealing with it after all.
EDIT: From a quick glance, it looks like master gets results back from workers using .Get(<workid>)? Is it easily possible for master to "select" a bunch of workers and get the first completed one? If you use (or at least somehow allow the use of) channels for this, you get all the built-in Go goodness for this kind of control. Even for dynamic number of channels, the reflect package has a dynamic .Select that handles it for you. I.e.: provide a channel that I can <- work results from, and let Go (and the user of your lib) handle the rest. Including timeouts :) select { result, ok := <- workchan: ... ; <-time.NewTimer(3 * time.Seconds).C : <timeout> }.