5 ms·
> A “Hello World” CLI written in Go compiles to around 2 MB. Nitpick but hello-world in Go : package main func main(){ print("Hello World"
by camus2 9y ago
> A “Hello World” CLI written in Go compiles to around 2 MB.
Nitpick but hello-world in Go :
package main
func main(){
print("Hello World")
}
is < 1MB on most computers (900KB on windows). No need to import the "fmt" package.
- slackingoff2017 9y agoYou can get under 200KB in Java easily by using proguard or similar to strip unused code from your dependencies.
- camus2 9y agoSure, but I didn't apply any specific code optimization or third party tool here.
- slackingoff2017 9y agoProgaurd is default on Android and some other environments, it's not anything exotic.
- pebers 9y agoBut that 200KB isn't a standalone executable. The Go example would be a lot smaller if it just distributed some unlinked object code with no runtime.
- slackingoff2017 9y agoTrue. The JVM is big. I've been meaning to try Golang one of these days, I see it as Java's spiritual successor
- eropple 9y agoI 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.)
- holydude 9y agoOk you have Nim,Crystal and / or Rust if you insist. There is actually a reason why Go is gaining momentum.
- eropple 9y agoSure, 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.
- pjmlp 9y agoNot really, unless you enjoy to program in Java 1.0 again.
- Cyph0n 9y agoI actually see Scala as Java's spiritual successor. Go is in an entirely different ballpark.
- morecoffee 9y agoprint() is a nonstandard function and will be removed eventually.
- deleted 9y ago[deleted]
- pjmlp 9y agoExcept 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." https://golang.org/pkg/builtin/ https://golang.org/pkg/builtin/
- trumpisyourdad 9y agololrekt. gofaggots are the worst.
- deleted 9y ago[deleted]
- virmundi 9y agoHey! You win the worthless example competition! See the front desk for your prize. How about comparing a full stack, monolith app in Java vs Golang? While you’re at it, don’t just compare binaries. Compare how well it handles concurrency. Compare how well it handles templates. Or how smoothly it handles DB interaction. Then look at all this and compare the population of Golang vs Java devs. Compare how well you can leverage existing language knowledge while working on a major mobile platform too like Android. Binary size for a hello world app means little to nothing. I can beat that with Bash: echo “hello, world!” Compare to real applications.
- camus2 9y ago> Binary size for a hello world app means little to nothing. I'm just quoting the original article. If you want to get mad at someone be mad at the OP. The whole point of the post is executable sizes.
- camus2 9y agoYour message is stupid and aggressive. The author of the blog post himself compares hello-world executable sizes, so what are you complaining about?
- dang 9y agoWould 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 https://news.ycombinator.com/newsguidelines.html and post only scrupulously respectful comments from now on, we'd appreciate it.
- dang 9y agoThis comment breaks the site guidelines. Please don't do flamewar things on HN, even if someone else's comment seems unfair. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- brobinson 9y agoDon'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)