Reusable and type-safe options for Go APIs
derekchiang.com
Reusable and type-safe options for Go APIs
1–10 of 36 posts
Re: Reusable and type-safe options for Go APIs
#2I've been using Go as my preferred language for almost a decade now. Hackish "clever" solutions like these coming from designers of the language like Rob Pike and Dace Cheney simply indicate that the language is hitting its limits of expressivity and needs to start thinking hard about overloading which is the right solution to problems like this.
Re: Reusable and type-safe options for Go APIs
#3Once you accept that the golang type system can't enforce everything your life will be easier.
Use rust or Haskell if you want a powerful type system that can do fancy things.
golang is great, but you have to accept that some things are runtime errors, and that's fine, it keeps things simple. How often are options given conditionally anyways? Simple tests will cover this in most cases.
Re: Reusable and type-safe options for Go APIs
#4I've been using Go as my preferred language for almost a decade now. Hackish "clever" solutions like these coming from designers of the language like Rob Pike and Dace Cheney simply indicate that the language is hitting its limits of expressivity and needs to start thinking hard about overloading which is the right solution to problems like this.
Why do you find this hackish? I find that pretty straight forward given the constraints. You might prefer a more expressive language but that comes at a cost.
Re: Reusable and type-safe options for Go APIs
#5I've been using Go as my preferred language for almost a decade now. Hackish "clever" solutions like these coming from designers of the language like Rob Pike and Dace Cheney simply indicate that the language is hitting its limits of expressivity and needs to start thinking hard about overloading which is the right solution to problems like this.
Rob Pike and Dave Cheney know way better than me, but I can't help to think they're trying to be "easy rather than simple", here.
Rob doesn't explain why a config struct is not good for him in his reference article, and Dave is saying that's because 1/ it needs to be passed even when it's empty and 2/ its zero values may be a trouble, giving the example of explicitly setting `Port` to 0 to let OS selecting first free port available.
I would say that I have absolutely no problem with passing an empty option struct : that's simple. I know what is going on, I don't have to check sources for three methods to understand it.
Regarding the zero value problem, the example of port selection seems incredibly an edge case. Most of the time, if some option is numeric and can have a special feature, -1 will be used rather than 0 (like it's often the case when passing a limit to specify "no limit"). For the port problem, I would have no problem passing an `AutoselectFreePort bool` option.
But then again, maybe the pattern seems complicated to me because it's new. We'll see with time.
Re: Reusable and type-safe options for Go APIs
#6Once you accept that the golang type system can't enforce everything your life will be easier. Use rust or Haskell if you want a powerful type system that can do fancy things. golang is great, but you have to accept that some things are runtime errors, and that's fine, it keeps things simple. How often are options given conditionally anyways? Simple tests will cover this in most cases.
[deleted]
Re: Reusable and type-safe options for Go APIs
#7I've been using Go as my preferred language for almost a decade now. Hackish "clever" solutions like these coming from designers of the language like Rob Pike and Dace Cheney simply indicate that the language is hitting its limits of expressivity and needs to start thinking hard about overloading which is the right solution to problems like this.
Publicly released in an unstable state November 2009, meaning (almost) 8 years ago. Which is right where I personally draw the line for "almost a decade".
It's been your preferred language from the moment it was available as a preview, three years before it hit 1.0?
Re: Reusable and type-safe options for Go APIs
#8Once you accept that the golang type system can't enforce everything your life will be easier. Use rust or Haskell if you want a powerful type system that can do fancy things. golang is great, but you have to accept that some things are runtime errors, and that's fine, it keeps things simple. How often are options given conditionally anyways? Simple tests will cover this in most cases.
No languages are perfect.
Yes Go type system can't enforce everything, but it enforce many things.
And Go is still language in evolving.
Re: Reusable and type-safe options for Go APIs
#9I've been using Go as my preferred language for almost a decade now. Hackish "clever" solutions like these coming from designers of the language like Rob Pike and Dace Cheney simply indicate that the language is hitting its limits of expressivity and needs to start thinking hard about overloading which is the right solution to problems like this.
Rob Pike and Dave Cheney know way better than me, but I can't help to think they're trying to be "easy rather than simple", here. Rob doesn't explain why a config struct is not good for him in his reference article, and Dave is saying that's because 1/ it needs to be passed even when it's empty and 2/ its zero values may be a trouble, giving the example of explicitly setting `Port` to 0 to let OS selecting first free…
The zero value problem would be a non-issue if Go had a built-in ?T type ("option T").
Re: Reusable and type-safe options for Go APIs
#10Earlier quoted context omitted.
Rob Pike and Dave Cheney know way better than me, but I can't help to think they're trying to be "easy rather than simple", here. Rob doesn't explain why a config struct is not good for him in his reference article, and Dave is saying that's because 1/ it needs to be passed even when it's empty and 2/ its zero values may be a trouble, giving the example of explicitly setting `Port` to 0 to let OS selecting first free…
The zero value problem would be a non-issue if Go had a built-in ?T type ("option T").
That's problematic, thanks to golang choosing to have always-nullable reference types. "option T*" would therefore be a tristate type, unless it was somehow specialised into representing nullability (obviously a major breaking change).