Greate video, I didn't know this Fx library until now. As a C# developer. I remark a difference between this "Go Fx/DI" and "C#/DI". In C#, Java, we also use the DI framework to manage the "objects life cycle". For eg, when you "register" (or "provide") a "NewUserStorage", you will have to declare the "life time scope" of the "UserStorage" object after it is created. In C# the life time can be "singleton", "scoped" or "transient". * When you provide(NewUserStorage, "singleton") then the NewUserStorage() function would be called only once, then the created object "UserStorage" is re-use until the end of the application. * When you provide(NewUserStorage, "transient") then the NewUserStorage() function would be called each time a consumer need to resolve a "UserStorage" The Fx docs did not mention what is the life time scope of the provided object (I suspect that they are all transient?..)
Hey Ben first of all, thank you about the video, I had some experience using the FX and for the specific project that I was working this looked like a Bazooka because behind the scenes it's using signals in a pool of objects inside the Context.
nice video :) I have a career in Python and Java, and I honestly prefer the DI (Dependency Injection) pattern. Recently, I've been studying Go and it seems there's a lot of discussion about the DI pattern in the Go community. I have a question regarding this. When using frameworks or libraries that support the DI pattern in runtime environments like fx, dig, as far as I know, it involves using reflection, which I heard is an expensive resource in Go. I'm curious about what advantages you've gained using fx, compared to the aforementioned disadvantages.
Hi Ben, I have question? What backend technology would you recommend for me? I am from NYC so I have a good selection. I have about 1 year and a half experience in programming. Did 8 months in web development with HTML, CSS and JavaScript and very little experience with React. But I also have experience with Django and I am already making API's and I made 2 CRUD apps. But I am thinking about switching from Django to something else, there are hardly no jobs for Django. I check on indeed and I only see 2 or 8 jobs tops on a good day. Is Golang easy to pick up? I am assuming if I have already some very basic skills in a backend framework I hope learning another backend framework or library won't be as difficult. I would appreciate any recommendations, thank you.
Its a borderline impossible question to answer, but I would say that if you are looking for a job TypeScript is gonna be your best bet. While I personally prefer Go, it has less jobs, and a smaller ecosystem, making TS both easier to pick up, and easier to get hired for. Once you learn TS though it is VERY easy to learn Go, C#, or any other high(ish) level language for BE. The concepts carry over nicely (REST, HTTP, SQL, etc)
do not use fx, please no. Dependency injection is a terrible idea. It breaks golang in so many ways. First you lose the compile time dependency checks, so it might compile and still not run. You might have code that is not even used. Go would usually catch that because you’d be initialising something and not using it. With fx you also lose that. Everything is a singleton, so to instantiate more than one object of the same type you have to wrap it in some bullshit.. You totally lose sight of where your dependencies are coming from for your other constructors. I think it’s embarrassing for uber to put their name behind this shitty library. Just use plain go if possible. So much easier to just walk through your entrypoints, just a map from URL to handler and you build the app from there.. simple
Even if I agree with you with the idea of "keep it simple", you are totally misunderstanding the idea behind dependency injection. Dependency injection is all about "passing dependencies (often via interfaces) instead of constructing them directly within a class or function". That's it! And this pattern is super maintainable, readable, and last but not least, testable. You cannot mix the concept of DI with a tool like fx or wire which implement this pattern in fancy ways.
@@AndreasLimoli fair enough, just venting here because I have to deal with fx on the daily and its nothing but magic and problems, and magical problems
![[Golang] Dependency injection with Fx](/img/1.gif)
tech school has a really good series on microservices. I use that structure for all my go projects
Greate video, I didn't know this Fx library until now. As a C# developer. I remark a difference between this "Go Fx/DI" and "C#/DI".
In C#, Java, we also use the DI framework to manage the "objects life cycle". For eg, when you "register" (or "provide") a "NewUserStorage", you will have to declare the "life time scope" of the "UserStorage" object after it is created. In C# the life time can be "singleton", "scoped" or "transient".
* When you provide(NewUserStorage, "singleton") then the NewUserStorage() function would be called only once, then the created object "UserStorage" is re-use until the end of the application.
* When you provide(NewUserStorage, "transient") then the NewUserStorage() function would be called each time a consumer need to resolve a "UserStorage"
The Fx docs did not mention what is the life time scope of the provided object (I suspect that they are all transient?..)
Been using this for quite some time, and I would say that’s the way to scaffold servers or anything else in golang. Uberfx ftw
Hey Ben first of all, thank you about the video, I had some experience using the FX and for the specific project that I was working this looked like a Bazooka because behind the scenes it's using signals in a pool of objects inside the Context.
Nice 👌 never seen FX in use actually. Agreed though, lack of convention/opinion in Go is both a blessing and a curse
Interface closures are nice as well.
been using fx for a few months, i think it is great for dependency injection, although i wish it wouldn't log as much as it does by default.
Top quality video Ben
This is dope, very C#-esque
As an ex-C#er any time I see something like this I am remind of the talk by Dave in Gophercone on " Clear is better than clever "
nice video :)
I have a career in Python and Java, and I honestly prefer the DI (Dependency Injection) pattern.
Recently, I've been studying Go and it seems there's a lot of discussion about the DI pattern in the Go community.
I have a question regarding this.
When using frameworks or libraries that support the DI pattern in runtime environments like fx, dig, as far as I know, it involves using reflection, which I heard is an expensive resource in Go. I'm curious about what advantages you've gained using fx, compared to the aforementioned disadvantages.
Thanks which software you use for drawing ? I mean the online app that can write like handwriting :)
excalidraw
Thanks and nice channel . keep going @@bmdavis419
hey nice video mate, I was just wondering what is your vscode theme? i kinda like it
GitHub dark
You earned a sub man, thanks alot and please whats the name of the vscode font please, thank you!
Hi Ben, I have question? What backend technology would you recommend for me? I am from NYC so I have a good selection. I have about 1 year and a half experience in programming. Did 8 months in web development with HTML, CSS and JavaScript and very little experience with React. But I also have experience with Django and I am already making API's and I made 2 CRUD apps. But I am thinking about switching from Django to something else, there are hardly no jobs for Django. I check on indeed and I only see 2 or 8 jobs tops on a good day.
Is Golang easy to pick up? I am assuming if I have already some very basic skills in a backend framework I hope learning another backend framework or library won't be as difficult.
I would appreciate any recommendations, thank you.
Its a borderline impossible question to answer, but I would say that if you are looking for a job TypeScript is gonna be your best bet. While I personally prefer Go, it has less jobs, and a smaller ecosystem, making TS both easier to pick up, and easier to get hired for. Once you learn TS though it is VERY easy to learn Go, C#, or any other high(ish) level language for BE. The concepts carry over nicely (REST, HTTP, SQL, etc)
What's the font you are using?
Jetbrains nerd font mono
do not use fx, please no. Dependency injection is a terrible idea.
It breaks golang in so many ways.
First you lose the compile time dependency checks, so it might compile and still not run.
You might have code that is not even used. Go would usually catch that because you’d be initialising something and not using it. With fx you also lose that.
Everything is a singleton, so to instantiate more than one object of the same type you have to wrap it in some bullshit..
You totally lose sight of where your dependencies are coming from for your other constructors.
I think it’s embarrassing for uber to put their name behind this shitty library.
Just use plain go if possible. So much easier to just walk through your entrypoints, just a map from URL to handler and you build the app from there.. simple
Even if I agree with you with the idea of "keep it simple", you are totally misunderstanding the idea behind dependency injection.
Dependency injection is all about "passing dependencies (often via interfaces) instead of constructing them directly within a class or function".
That's it! And this pattern is super maintainable, readable, and last but not least, testable.
You cannot mix the concept of DI with a tool like fx or wire which implement this pattern in fancy ways.
@@AndreasLimoli fair enough, just venting here because I have to deal with fx on the daily and its nothing but magic and problems, and magical problems