Is everything from the imported Go packages included in my application or is the unused code discarded? Something like Javascript's 'treeshaking'?
Eg. If I have created for myself utility functions dealing with Gin and Gorm (or with some other 3rd party functionality) - would it make sense to package my utility functions also in separate libraries or just bundle them in one?
"Tree-shaking" is for JavaScript, where you're delivering the code to the runtime in source form, and removing unused bits of the source requires active effort (and doing so in a way that the result still works requires some smart analysis).
In compiled languages, especially when using static linking (which is nearly always the case for Go), not linking in unused functions is just that... if nothing ever refers to a function, then there's no reason to emit it. It's pretty much default behavior. The linker has to know where all of the calls are to insert the correct addresses, so it doesn't have to do significant extra work to notice when a function is never called.
Eg. If I have created for myself utility functions dealing with Gin and Gorm - would it make sense to have these functions in 2 separate libraries? Or is it completely harmless to have them in 1 library and have the Gorm utility functions (and therefore Gorm dependencies) imported even if my application has no DB part?
Putting them in one library is a silly idea just from a dependencies point of view. If a program uses your library, and never uses gorm, then why should it require gorm in its build process? Why should a failure to fetch or build gorm have the potential to break the build of a program that never uses it? You're not paying a runtime or binary-size cost, you're paying a maintainability cost.
Is everything from the imported Go module included in my application or is there some 'treeshaking' involved and only used code is included?
First, you cannot import modules in Go. You can only import packages.
Second, Go is a language specification, so the question of whether or not "tree-shaking", or any other method of dead code elimination is used, is up to the implementation.
But having said that, in general, the official Go compiler, and probably any other Go compiler, is smart enough not to include things that are obviously not used. Exactly how smart it is in this regard depends on the exact implementation and version.
If I have created for myself utility functions dealing with Gin and Gorm - would it make sense to have these functions in 2 separate libraries?
Whether it makes sense to be in a single library or not depends on how you organize your libraries. Organize your libraries logically, not according to compiler optimizations. Trust the compiler to do its job.
I probably would not put utility functions for Gin and Gorm in the same library, simply because they're not at all related to each other, though. But that's completely unrelated to dead code elimination of the compiler.
