4 ms·
Whenever I'm reading through Go code and come across something that uses this sort of abstraction library, I usually just close it and move on. The stdlib is re
by shawnps 11y ago
Whenever I'm reading through Go code and come across something that uses this sort of abstraction library, I usually just close it and move on. The stdlib is really nice and I find code that stays as "vanilla" Go as possible to be the easiest to read.
- Rezo 11y agoIt's not the first time I've heard this sentiment around Go. I find it a fascinating difference in mindset to for example Node.js where in my experience even the smallest application will pull in dozens of dependencies and there's a package for absolutely everything imaginable. Because of the way dependencies are hierarchically scoped, there's no version conflicts in Node and a project may end up with 3 different Requests modules with only disk space as the cost. What do you consider to be the downsides to liberally using libraries that reduce the amount of code by wrapping the standard lib or that build on top of other libraries? Personally, and I may be wrong as someone still new to Go, it seems to me that the single monolithic repository model that Google uses permeates the whole community and has made adding an external dependency a Big Deal and something you have to carefully consider instead of something you instinctively do.
- pcwalton 11y ago> What do you consider to be the downsides to liberally using libraries that reduce the amount of code by wrapping the standard lib or that build on top of other libraries? Personally, and I may be wrong as someone still new to Go, it seems to me that the single monolithic repository model that Google uses permeates the whole community and has made adding an external dependency a Big Deal and something you have to carefully consider instead of something you instinctively do. Because there's no equivalent of npm in Golang, culturally speaking.
- tedsuo 11y agoSimply put: dependencies are code, and code comes at a maintenance cost. Thin abstractions, such as a this library, can be replaced by a function or two, which is a lower maintenance overhead because there is less code, you wrote the code, and all the code is being used. IMHO, dependencies should be pulled in for things that would take you weeks to do correctly. Avoid pulling in a dependency for something you can do yourself in 5 minutes. So I would pull in an http library if it actually did the mechanics of http better than the one in the stdlib, but not one that just wrapped it up for me a bit. For me, that's not a Go thing, that's just an I'm Older Now thing. Also, snarkily, dependency management is a mess in Go right now; none of us have any dependencies because we can't figure out how to do it. :P That is definitely a hole right now (though it's starting to get plugged in 1.5 with the /vendor directory) and is definitely exacerbated by the core team not being able to use any solution they could provide for the community.
- levigross 11y agoI agree with you. I wrote this library because I didn't want to rewrite those functions every time I started on a new project. I put it online because I figured that I would be useful to others as well.
- tedsuo 11y agobtw for the record I don't think there's something wrong with making small packages like this, just that I'm more likely to copy over a function or pattern that I like into my codebase, rather than bring in a dependency.
- levigross 11y agoI know... But as you said (and I agreed) :) dependencies add complexity...