4 ms·
> A full-program, aggressive optimization step might lead to smaller binaries, but it would do so at a great cost to projects with many dependencies. Incrementa
by csande17 7y ago
> A full-program, aggressive optimization step might lead to smaller binaries, but it would do so at a great cost to projects with many dependencies. Incremental compilation is a boon to developer productivity which is also important.
Isn't the traditional way to solve this problem to have two different modes for the compiler? You can have a "development" mode that compiles quickly and supports incremental compilation, and that doesn't stop you from also having a "release" mode that produces a Hello World executable that fits on a floppy disk.
And then if you're Google and you have infinite disk space and memory but limited time to spend waiting for builds, you can just run all your builds in "development" mode. (But if you also ship smartphone apps, maybe you compile those in release mode.)
- loopz 7y agoThe Go Way ain't the traditional way. I'd argue you should want the same binary everywhere, though there's always C or you could come up with your own scheme to break production.
- csande17 7y agoI don't especially care about the binary (beyond wanting it to be as small and fast as possible on end-users' machines), but I do want the behavior to be the same everywhere. In C, this is difficult because code often accidentally relies on "undefined behavior" that changes depending on the compiler and optimizations you use. But is that still an issue in newer languages that don't have as much undefined behavior? (Is this something Rust programmers struggle with, for example?)
- loopz 7y agoSafe language implementations such as Go and Rust are specifically designed to avoid such inconsistencies. If your builds differ, you never know 100% though.
- steveklabnik 7y agoRust only has undefined behavior if you use unsafe.