It might include a C parser, but it isn’t just a C parser. More importantly, it’s infrastructure within the Go compiler to handle calling C code from Go and vice-versa. The Go compiler knows about the C pseudo-package and wraps calls to C functions to make it look almost seamless in the source code even though there’s a lot of “magic” going on to make that happen.
I can’t tell what this is, so I’m not sure.
libgnutls28 seems to be a TLS library. I’m not sure if there’s anything this package does that’s special but Go does have its own net package that works with TLS.
libboost seems to be the C++ Boost library. I’m not sure what you need it for, but you could use cgo to wrap functionality you need if you can’t find the same functionality in a Go package somewhere.
If I understand python3-setuptools correctly, it is about embedding static files and accessing it within code.
So google for “golang emebed static files”.
Be very careful about add-ons and extra tools. Go has a comprehensive Standard Library that enable one to build pretty much any type of application without resorting to add-ons, third party code and or frameworks.
Before installing something that appears to help you, dig into the Standard Library first so see if you can solve the problem, then move slowly outward in the go eco-system to find go-like tools that help. Just banging a library in that looks like Python, or Java or C obviates the point of using Go
Whilst this is a personal opinion i often find that instead of solving the problem using Go, helpful devs will build a solution that looks like another language they are familiar with to circumvent Go rather than go (no pun intended) with the grain of the language. This is also the case with development of the language where we now have the “Generics” camp trying to make Go look like Java & C++ etc. (Gawd help us).