That&#x27;s an orthogonal issue. You won&#x27;t accidentally bring in something completely unrelated because you forgot to remove it from the &quot;include&quot;s, but nothing technically stops you from having a deep dependency chain. Culturally the Go community is aware of the issue, though.<p>Still, it isn&#x27;t hard to bring in a chain accidentally. I have a program than needs to do a query against the local LDAP system to extract members of a specified group. The LDAP library brings in five more libraries for parsing all the various bits of LDAP. Since this isn&#x27;t C, I&#x27;m a bit less nervous about pulling in, say, a BER decoding library, because at least Go is generally memory-safe, but, still, that&#x27;s a somewhat large stack for such a simple query. (Traditionally in C, you might as well just expect any library that decodes anything remotely binary-esque will have buffer overflows. C is a DSL for writing buffer overflows.)<p>And yet, I&#x27;d be insane to try to implement some sort of just-barely-minimal LDAP client to do it myself.<p>Looking at my local godoc instance&#x27;s full set of packages that have gotten pulled in one way or another is still sort of intimidating. Some of them are cases where I&#x27;m just pulling in a subdir and got an entire large repo (the golang experimental repos do that a lot), but, still, I&#x27;ve got a lot of stuff in there. If you&#x27;re a go programmer and you haven&#x27;t run godoc locally and had a look at the packages page, have a look. You may be surprised.