In recent history I have worked a lot with Golang and also encountered the tendency towards globals being the recommended path.
Specifically, I encountered it with logging, frameworks( Gin ), and DBs. It is interesting to me that you called out these three things specifically having encountered them all myself.
I agree also that it is a result of having poor DI support from the language.
I also like your point about PHP users using Golang. The approach Golang uses towards serving web content is very similar to me to how initial PHP frameworks did it.
Go tends to make it easy to setup concurrent things occurring, and so I've found myself spending a fair amount of time speculating on what is thread safe and what isn't.
No matter how much I see it I still do a double take when I see globals in Go modules. Seems like a bad practice to me.
Specifically, I encountered it with logging, frameworks( Gin ), and DBs. It is interesting to me that you called out these three things specifically having encountered them all myself.
I agree also that it is a result of having poor DI support from the language.
I also like your point about PHP users using Golang. The approach Golang uses towards serving web content is very similar to me to how initial PHP frameworks did it.
Go tends to make it easy to setup concurrent things occurring, and so I've found myself spending a fair amount of time speculating on what is thread safe and what isn't.
No matter how much I see it I still do a double take when I see globals in Go modules. Seems like a bad practice to me.