Eventually, any interesting software project will come to depend on another project, library, or framework. Packages provide a namespace or a firewall for your code. By firewall I mean, insulate the code in the package from changes in other parts or packages. Entities inside a package (types, functions, variables, and so on) can be exported (public—visible outside the package) or unexported (private—not visible outside the package). The way to control visibility is exactly like the mechanism described for classes: if the identifier name starts with a capital letter, and it is exported from the package, otherwise, it's unexported.

This is an example of a convention over configuration paradigm and is one of the key enablers of encapsulation in Go. The rule of thumb is this:

Go's standard library comes with a lot of useful packages that can be used for building real-world applications. For example, the standard library provides a net/http package that can be used for building web applications and web services. Besides the standard packages, it is idiomatic in Go to use third-party packages. You can literally pick any third-party package on GitHub and use it in your code, after a simple go get command.

While this flexibility is good, it is important to have a packing philosophy and guidelines so that developers know exactly where to put and find code.