► Join my Discord community for free education 👉 discord.com/invite/bDy8t4b3Rz ► Pre order (get 30% off) my Golang course 👉 fulltimegodev.com Thanks for watching

This pattern is commonly known as the "Functional Options" pattern. The Functional Options pattern is a design pattern in Go where you pass in functions that alter the state of a type. These functions are often called "option functions". They provide a way to cleanly design APIs and offer a more flexible and readable way to interact with a function or type. Nice demonstration on how to implement them. Thanks.

Functional Options Pattern... popularized by Dave Cheney

Perfect timing! I am doing something right now that can use this pattern. Thanks!

1. Make the config elements private 2. Make the options type a public interface, with a single private method (apply(config) config) 3. Expose public functions returning this interface 4. Add a function type that complies with the option interface, make that type implement the apply method by calling itself. 5. Add a no-op type for validation when needed. 6. Validate input before returning a config type. Boom, functional options with a restrictive builder pattern, for your constructors. You can make it generic too.

Love these pattern videos man!!

This channel is amazing, you're making my Go code better and better for every video!

The way you make any concept understand is just amazing !!

Thank you for posting this Anthony, very nice pattern and will be trying to incorporate it with my starter projects

This is a great video. I stumbled onto using this pattern by accident, it was very useful for a previous project I was working on

Really helpful, you can see the benefit right away! Awesome stuff

Just love this man !! More like this brother, these r the stuff which really play with the Dopamine !!

This is amazing and used in a lot of places tbh. This is very true that it's used in gRPC, also ssh package if I am not wrong because ssh connection has a lot of options. While putting this in a library the "withXYZ" functions can also be a method where it can have the server receiver methods. This is so so so amazing!!!

Awesome video as always! ❤

Thanks, I think you also talked about a bit of functional programming in Golang in this video, which is very nice.

Meanwhile in TypeScript: mergedOpts = { ...defaultOpts, ...opts } as Opts But its a cool pattern. Go doesn't have "map spread operator" and thats a good thing probably. But sometimes it would be so handy to have more syntactic sugar

This is so useful, thank you so much!

As always very advanced content

Nice one. Really enjoy this pattern.

Does feel like a take on the builder pattern. Incredibly handy pattern a lot of Elm libs use as well.

Amazing video, thanks for sharing your knowledge!

Nice clean pattern to understand too

Top notch stuff 👌🏽

Thanks for yours lessons. One of the best video lessons for go.

Watch this video for some time ago, remember. And return now to implement this in my project)) Antony is gigachad, thx for the video

I wish you would upload this amazing tutorial when I first learnt Go.

It looks fancy but a bit of a hassle. A simple builder pattern is much more readable I think. The default values are nice. Then just put methods onto the ServerOpts type which return *ServerOpts. type ServerOpts struct {...}, func NewServerOpts() *ServerOpts {...set defaults...} , func (s *ServerOpts) Id(id string) *ServerOpts {... set id ..}, func (s *ServerOpts) MaxConn(maxconn int) *ServerOpts {...set maxcon..} Then you can use it like this: s := NewServer(NewServerOpts().Id("my-server").MaxConn(100))

Thanks for diving into design patterns Anthony ! This is what separate starting devs to more advanced ones, that we all aspire to be, and that is understanding design patterns. Looks more like the Builder pattern than the Visitor one.

Hi Antonio, how are you? I'm migrating from nodejs to Golang thanks to you and your videos, always amazing! I don't know if it's asking too much, but could you make a video/tutorial for developing web crawlers with golang, please? I was googling about it but I didn't find any good content about it. Thank you so much my friend, you are amazing!

Reinventing the wheel of named function parameters with default values))

This is great!

This pattern is so good !!! I guess you can use it in TS/JS too

nice pattern, seems very helful

Thank you, perfect

Quality Content

Beautiful ❤️

Hey big boss, two questions: 1. How to make an efficient cron job scheduler from scratch? 2. How to make realtime subscriptions to database values - for example we have key value store but then we build realtime subs that can subscribe to changes of a key and its data? Another quality video for the fans homie, love this channel. Bests, Super fan.

Thanks for the explainer, I'd have been searching docs for a standard way to do this without realising it requires a pattern. In JS I'd just use a default arg param and a spread operator to override

Good stuff. Aws' sdk has this pattern in every client (that I've used).

That's a beautiful pattern

only real world shit in the channel 💪🏼 love your content as always ❤

This is pretty cool.

This is honestly really cool, I always hated how there is no way to do kwargs in go

Looks to be a variation of the builder pattern. (I come from OOPS)

Clever. I like it.

I have misused this pattern. Quite useful

Great work around. Though I would not use it, as I cannot use an existing config to initialize the state. Instead I would just use merge function to join default config with provided config.

3:50 to 3:53 Witch Craft and Woo Doo ! . My man's a part-time wizard

amazing.

that was really cool trick i like it

very good thx bro

this is unbelievable

I guess this could also be combined with builder pattern, and then you can just can chain those withX on the builder and build will return the instance

Is there an advantage over the builder pattern? It seems to be equivalent in usage but I'd guess harder to optimise.

oh snap cool man

Isn't this kind of a limitation on the language? If you could specify default values when you declare structs, then this would go from 50 lines down to 10? You mentioned doing this function approach if you were building a library. How would you do this in a way that's easy for consumers of the library to use and know which functions are available to be used for configuration? Would you put them together into a "configuration" package? (I'm not a Go user, just interested)

Opts (Opts, opts), opts Opts Opts opts😅 Thank you Op for the video ; I appreciate your talent and time

This pattern is just an adptation from the Fluent Interface Pattern existing in OOP languages, is nice to see it in go though.

Cool approach! Just wondering, why did you go back to VS Code?

I think it's a Go version of the Builder pattern, but not sure.

how inner function (the one that you retuen in options functions) gets the pointer which it has as input when higher lexical scope doesnt provide it

It is called 'Functional options pattern'

This is a good pattern, I've been using it for years, but why not make an option function that returns the same option function with the previous value? That way you can change and reset options on the fly. An example could be to elevate debug logging temporarily for some very complex code segment. Rob Pike wrote an article about this for some years ago. type Option func(*Some) Option type Some struct{ ... dLevel int } func Debug(d int) Option { return func(s *Some) Option { t := s.dLevel s.dLevel = d return SetOption(t) } }

It's like Visitor pattern, but in a functional way

will this thing not make established Go features convoluted? aren't you not reinventing the wheel here?

Interesting

AWS SDK uses this pattern too.

This was really informative. A side question. Any particular reason for using int instead of uint in maxConn? I noticed most people use int where a uint makes more sense. In this case, we cannot have negative maxConn.

Is this pattern used in go starndard lib?

This is essentially a builder pattern written in Go.

We use to call this the Option pattern. Would you have a nice one for Mandatory config where you cannot provide a reasonable default, like a sql.Conn?

docker compose v2 uses this pattern

Cool fancy< stuff. What about toi make a fluent api with that style?

This is like a functional builder pattern...?

why not create a builder pattern, which will do the same as what you are doing, with more readability.

That looks like function as parameter that was introduced in java 8 with lambdas xD

Hi Anthony, what theme do you use?

Hello. Where does download your vscode config?

The only problem with this pattern is that you lose info from the LSP. Working with the AWS SDK, I often have no idea what is possible or what the opt functions do without reading the documentation. It’s a trade off, especially when you have a lot of config options

Go can easily resolve this issue by providing the option of built in default parameters similar to Python during the definition of the function

Looks like some sort of builder pattern

Start: 1:03

What is the advantage of this pattern over a builder pattern?

👍

Can somone please rephrase what's happening at 6:15 with fn(&o) ? It's not clear to me how everything works together

This looks very oop

Why not just take configuration data from a JSON file, like config.json?

I did something with this .... But my approach was quite different,

I think more easier like this one below ```go type Config struct { Env "string" } func getConfig() (config Config){ env, ok := os.LookupEnv("ENV") If !ok{ env = "your default value of ENV here" } config.Env = env return } type Data struct { pool *pgxpool.Pool } func NewData(pool *pgxpool.Pool) (*Data, error) { if pool == nil { return nil, errors.New("no pool ready") } return &Data{ pool: pool }, nil } func main(){ config := getConfig() data, err := NewData(config.Env) } ```

The only problem i have with this pattern is that it is not obvious which methods/func you can use as options.

Why not just make your config a .yaml file and parse it into a Config struct? Then you give your library users a defaults.yaml and they can copy and modify it at their will?

the ‘…’ is called variadic.

How to code??

Builder pattern.

Suggestion: Buy a pop filter.

I'll be honest. The accent makes it a little hard for me to understand you at times; HOWEVER, your content is SOO VALUABLE that I don't mind rewatching parts a few times to get better at Go.

I think I have seen this pattern in google youtube package

Do Golang jobs even exist?

Efficient, how? You have a lot of superfluous machinery going on there, including varargs, *many* closure creations, and *many* extra function calls.

I hate functional options pattern. It just so much worse compared to just passing a pointer to a structure with options.