Except that isn't actually portable Go code, because you are using an unsupported function that can be removed at any time.
"The print built-in function formats its arguments in an implementation-specific way and writes the result to standard error. Print is useful for bootstrapping and debugging; it is not guaranteed to stay in the language."
Don't forget to pass -ldflags "-s -w" to `go build`.
Debugging symbols are over 50% of most Go binaries I see, and you don't even need them to get stack traces from panics.
Combined with `upx --ultra-brute`, you can get static Go binaries down to about 12-15% of their plain `go build` size in my experience. (This also assumes CGO_ENABLED=0)
I tend to view it more as a regressor. Golang is a conservative retrenchment towards Java pre-1.5 in a lot of ways. (And that may be fine for some use cases; I get the appeal even if I think it's misguided.)
Sure, there certainly is: it looks easy at first blush and scales moderately well. And that's fine, if you understand its drawbacks, and what Go aficionados try hard not to address is that Golang has a severe complexity wall. It is a large reason, along with faddish trendiness, why the Go universe clings so heavily to microservices: because the Golang is structured lends itself to writing messy code that is more easily combated by splitting into different systems rather than just writing modular code that respects encapsulation (in part because its type system is lousy, in part because error handling with deeply nested trees is harder than it needs to be, etc.). That this also creates additional problems--request tracing is an ongoing tire fire--is often elided a little bit, too.
In my experience, Go exhibits human-scaling problems long before even dynamically typed languages and significantly before Java, Kotlin, or the like. And the arguments to deployment are defanged both by Docker and by that it's usually not the developer who picks it who ends up building the CM around it in the first place (that's why they hire people like me, and why I have had to become uncomfortably familiar with Golang, its ecosystem, and the habits of your average Golang developer: because the person running the systems it runs on is inevitably the backstop for when those programs spit the bit).
But in the five-minute-demo-to-make-production-decisions universe, it plays really well.
Would you please not reply to a bad HN comment by making the thread even worse? The site guidelines explicitly ask you not to do this.
Your account unfortunately stands out in my mind as one which has posted many nasty comments to HN over the years (as well as many good ones), so glass houses and all that. If you would read https://news.ycombinator.com/newsguidelines.html and post only scrupulously respectful comments from now on, we'd appreciate it.
Nitpick but hello-world in Go :
is < 1MB on most computers (900KB on windows). No need to import the "fmt" package.