If only service-discovery features are used from the entire SDK, then the real story here is that Go's DCE passes aren't strong enough - or the SDK is coupled in a way that makes DCE not work (overuse of reflection?).
Reflection in general isn't the problem, but if you specifically use reflection to look up a method in your program, then dead code elimination gives up. https://go.dev/src/cmd/link/internal/ld/deadcode.go
Interesting detail, didn’t realize go dead code analysis was this easily made ineffective. 52MB for ec2 SDK is a big chunk of code that must be mostly dead/unused.
Seems like eventually this should become a priority for library writers to support dead code analysis, otherwise going to get worse and worse..
These SDKs typically hang everything off of the same Client type, and since methods can be reached via reflect I'd guess none of the exported API is safe to drop. The SDKs would need to be written to be much more modular.
Those organizations also tend to spew a lot of code, most of it quite tangled together. They're definitely the largest dependencies I regularly see.
Not only are they spewing out a lot of manual code. Additionally they include a lot of auto generated and versioned code. Azure python for example has a duplicate of every method for every version of the api.
