3 ms·

> No Optional Arguments: Go only has variadic functions which are similar to Python’s keyword arguments, but less useful, since the arguments need to be of the

> No Optional Arguments: Go only has variadic functions which are similar to Python’s keyword arguments, but less useful, since the arguments need to be of the same type. What I like to do is to make the last arg take a struct such that you indirectly have named (and optional) arguments: type DownloadOpts struct { UserAgent string TimeoutSeconds int //... } func Download(url string, opts DownloadOpts) (io.Reader, error) { ... } //use like: contents, err := Download("https://news.ycombinator.com", DownloadOpts { UserAgent: "example-snippet/1.0", }) > Never needing to pause for garbage collection could also be a factor [in Rust's greater speed compared to Go]. Would be nice if the author had checked var ms runtime.MemStats runtime.ReadMemStats(&ms) print(ms.NumGC) to see if there was actually any garbage collection performed.

bkq 7y ago
>What I like to do is to make the last arg take a struct such that you indirectly have named (and optional) arguments: Rob Pike, and Dave Cheney both posted about this [1][2]. They summarised that using self-referential functions were a more optimal way for handling options to a function. This gives the benefit of allowing the options to be easily extensible by yourself, and any users that would be interacting with your API. [1] - https://commandcenter.blogspot.com/2014/01/self-referential-functions-and-design.html https://commandcenter.blogspot.com/2014/01/self-referential-... [2] - https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis https://dave.cheney.net/2014/10/17/functional-options-for-fr...
- nemo1618 7y ago
  Functional options were exciting when they were first discovered, and they're used in a few popular APIs (e.g. gRPC), but they haven't become as ubiquitous as you'd expect if they were truly superior. My guess is that a struct is the more direct and obvious approach for most people. Functional options also make it awkward to save and reuse a set of options later.
jpittis 7y ago
And then you get the lovely benefit of not knowing whether someone explicitly passed in zero or didn't specify an option at all. There are a lot of ways around this: Use pointers, specify default arguments, etc. I does frustrate me though whenever the language creators bless a hack approach to get around deficiencies in the base language.

bkq 7y ago

>What I like to do is to make the last arg take a struct such that you indirectly have named (and optional) arguments: Rob Pike, and Dave Cheney both posted about this [1][2]. They summarised that using self-referential functions were a more optimal way for handling options to a function. This gives the benefit of allowing the options to be easily extensible by yourself, and any users that would be interacting with your API. [1] - https://commandcenter.blogspot.com/2014/01/self-referential-functions-and-design.html https://commandcenter.blogspot.com/2014/01/self-referential-... [2] - https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis https://dave.cheney.net/2014/10/17/functional-options-for-fr...

nemo1618 7y ago
Functional options were exciting when they were first discovered, and they're used in a few popular APIs (e.g. gRPC), but they haven't become as ubiquitous as you'd expect if they were truly superior. My guess is that a struct is the more direct and obvious approach for most people. Functional options also make it awkward to save and reuse a set of options later.

jpittis 7y ago

And then you get the lovely benefit of not knowing whether someone explicitly passed in zero or didn't specify an option at all. There are a lot of ways around this: Use pointers, specify default arguments, etc. I does frustrate me though whenever the language creators bless a hack approach to get around deficiencies in the base language.