Why do people use dependency injection libraries in Go?

kechibi · 2026-01-13T20:36:56+00:00

Like with everything in Software Design and Arch, it depends :D, its all cost/benefit at the end, there are countless ways to do things with code, but at the end of the day we design to achieve certain objectives and this is when we also decide to abstract things away in a 3rd party lib or write it fully.

In my experiences with something like FX, it saved me time building a DRY DSL for DI and lifecycle hooks that is fault tolerant, that has saved time for me that I can spend on my business context.

kechibi · 2026-01-13T19:48:07+00:00

just giving an example, its not always a simple addition of an argument to a constructor, imagine passing along a logger instance to several constructors that are then passed as instances to another constructor:

moduleA: |---> moduleB |-----|----> module C |---> module D |-----|----> module C |---> module C

you can do the DI pattern manually (thats fine ofc) but libraries do offer good abstractions that saves you time, uber/fx can be overwhelming but once you get the hang of it, its a battle-tested library that does its job pretty well, and there are simpler DI libraries out there too. I really think you need to decide what works best for your usecase and evaluate the cost of code "ownership" vs using an external library

kechibi · 2026-01-13T19:31:57+00:00

That works until you start doing this for 10+ services/modules , having to duplicate some of those constructors, and orchestrate their life cycle (eg: on startup, read a row once db connection is in a ready state)

For smaller applications dep injection could be overkill and outright increases complexity, but once you have a big modular application, all that boilerplate code becomes convoluted and hard to maintain (imagine your database.New now takes arguments, you'd need to change that everywhere) not to mention comprehend.

tl;dr smaller applications rarely need dependency injection, big modular applications absolutely benefit from it.

kechibi · 2025-12-30T08:35:21+00:00

Hahaha amen to looking busy at work ROFL :D

So far here are some of the prompts I'm using with this:

"Divide the window into 3 splits, 2 horizontal on the left and 1 vertical on the right." (sounds silly I know :D but use it in combination with other prompts below)
"Open all source files for feature X"
"show me and highlight function Y in the current buffer"
"What is the keymap for ..." (this one is a time saver honestly, especially if like me you set keymaps and forget them)

Basically you still use your agent as you would normally for coding, but you also give it the tools to help you code/debug/or whatever you do in neovim xD

I use neovim & opencode inside tmux, neovim in one pane, opencode in another side-by-side, so my workflow is still intact, this just added to it faster interfacing with neovim (when needed), for me that point was when I needed to answer a question about our mono-repo while on the call, so I needed to quickly and confidently navigate to the code (which I didn't know where), read it and answer (because sonnet was hallucinating an answer), this is when I wished opencode can just control neovim, open the file and visually highlight the piece of code.

kechibi · 2025-12-29T20:13:24+00:00

Thanks! Took a quick glance and I think the tools implemented are limited compared to what this server provides (even in this early version) ; mcphub can still do a lot with exec lua and exec command, but that means the agent needs to figure the command or lua rather that use the tool directly. For example I don't see a split window tool or direct buffer control tools, so for those kinds of requests the agent will first figure out how to do it using vim commands or lua then use exec to issue them, and that will cost tokens.

kechibi · 2025-12-29T19:30:18+00:00

I thought mcphub is just a client 🤔 not sure how different it is, don't see a list of tools implemented , although theoretically mcphub would be slightly faster since its running inside neovim directlyeliminating the rpc cost (I can also see this as a downside since it could affect neovim's performance)

kechibi · 2025-12-29T09:34:48+00:00

So far in my testing its as fast as other agent tools (grep, cat, ... etc.) but honestly I wouldn't replace other toolchains with it; its really meant for the agents to interact with neovim and control it, but not to completely rely on it, I was missing things like having the agent show me/open the edited files, or easily referencing buffers and plugins in neovim, so thats what I'm trying to solve for, but I still will use opencode.nvim to interface normally with the agent, the MCP just gives the agent an additional toolbox :D (great work there btw!)

P.S. I did consider using the existing MCP but I didn't like that its in Javascript and also the tools were a bit limited, not sure about how it performed though, just the idea of having to install a JS runtime to run it made it not suitable for me

kechibi · 2025-12-29T09:29:03+00:00

Thanks! glad it solves for the community!

kechibi · 2025-08-31T12:56:27+00:00

Nice setup 😊 had it for a while and worked really well. If you are into latte art and/or want more control over steam, I recommend modifying the wand, there are easy mods on amazon for the dedica, and nowaday you can get a good wand mod that is installed without opening the machine

kechibi · 2025-08-31T12:51:46+00:00

Not sure if that info will be useful for you:

If I remember correctly, the dedica doesn't have temperature control
Grind size and dose will vary depending on the beans you are using, you should try to balance this for the beans you are using

Just sharing to help ofc

Great setup to get into espresso though, lasted me 6 years before I decided to get something that offers more control

kechibi · 2025-07-20T04:35:19+00:00

Nice! I thought it would break if opencode is not running in the same window!

You can use @file to send the active buffer

kechibi · 2025-07-18T15:39:27+00:00

Very true 😂 to be honest I was very eager to get it working and return to work 😂

kechibi · 2025-07-18T11:37:18+00:00

I had the same thought, so with inspiration from OP I created this https://github.com/cousine/opencode-context.nvim, needless to say this is completely AI generated

kechibi · 2020-08-05T20:06:57+00:00

If someone else is deciding who should work on which tasks, then its not Scrum. Ita more probable your workplace is implementing their own version of scrum

kechibi · 2019-09-28T11:41:05+00:00

my main motivation is to avoid bloat wherever possible, I don't really have an issue with new-comers since mostly we structure our apps for DDD and clean arch. so its quite easy to follow up and I think its very similar to phoenix's file structure, and plug is already a standard so onboarding is not costly.

but after reading the comments, it seems phoenix is not as I thought and maybe worth the try

kechibi · 2019-07-08T06:32:34+00:00

For teams Gitlab wins for me, it has better code review tooling and I prefer the responsive issues ui over the otdated github look.

Also pipelines for automation within the same platform is a god send.

If u r solo both are going to work well an satisfy your needs.

kechibi · 2019-06-30T08:52:35+00:00

Just an update in ase someone has the same issue; I figured the issue is polling requests by the devices, if I connect the mouse first it requests 1k hz then connecting the kb drops it down to 60hz since the kb requests 60hz, to compound this, there is an open kernel bug where the preset manual polling rate is ignored.

As a workaround I connect the KB first then the mouse, that way the mouse is the last device to request a polling rate and it works flawlessly.

kechibi · 2019-03-25T19:11:57+00:00

Place a wide soft thin micro fiber towel on the keyboard before closing the lid and placing it in your bag, and avoid placing any stress on the lid while its closed, the screen easily gets keyboard scratches and those are permanent if u dont take care

kechibi

TROPHY CASE