Very cool about the SEA feature, I haven't seen that before. Thanks for sharing that
This is sort of the worst case comparison, but a hello world program in go is 1.5 MiB and the SEA node equivalent is 109 MiB. Obviously as your program becomes more complex that fixed overhead becomes less of an issue but I think it's still a useful comparison.
For the packages, the thing I prefer even more so is writing an application with 0 dependencies at all. net/http, net/http/pprof, flag, pprof, etc are all built in and high quality and you can easily build clis/servers with them. Even a really full featured CLI builder package like cobra has just a few transitive deps and gorilla/mux has none: https://github.com/spf13/cobra/blob/main/go.sumhttps://github.com/gorilla/mux/blob/main/go.mod
If I compare that with express.js or commander its a very different story (though, in fairness to commander, they all seem to be dev deps).
I actually agree, and my own Node.js web server doesn't use express.js or anything except for 'mime-types', and only because it's not built in even though it really should be. I never liked express.js's design, and pretty much every useful feature of it is now either built-in or 5 lines of code. Plus, when I dug into its source code and dependencies, I found so much outdated and unnecessary cruft. So yeah I don't disagree. But it still doesn't really push me towards Go. Plus, Go's own http route mounting concept also seems kind of overdone. So even though I can just avoid using it, it still becomes part of that 1.5 MiB that I didn't really need but am forced to bundle, even if it is smaller than the 109 MiB. So in principle it doesn't seem a huge win, just a small one. Compare that to the many TypeScript features and JavaScript features I'd have to give up, and it just doesn't seem worth it.
2. Which is better, having 70,000 packages but only 700 good ones, or only 500 packages and every one is good? I'm on the fence.