Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Simply 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.



I 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.


btw 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.


I know... But as you said (and I agreed) :) dependencies add complexity...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: