3 ms·
- On the "damnable use requirement", I see his point. If anything, it means that Go will be better used with IDEs than text editors that'll do this for you auto
by Locke1689 14y ago
- On the "damnable use requirement", I see his point. If anything, it means that Go will be better used with IDEs than text editors that'll do this for you automatically;
The lack of partial/incremental/parallel compilation make this a lot less attractive. A lot of IDE technology (e.g., "intellisense," syntax errors, missing imports) are built off of rapid recompilation.
In fact, doing it any other way seems pretty stupid. If your compiler doesn't offer that information then the IDE has to re-implement those codepaths just to provide that information.
- saljam 14y agoGo generally compiles so quickly, incremental compilation is unnecessary.
- sirclueless 14y agoActually, incremental compilation is the main reason Go compiles so quickly. Super-fast incremental compilation is the reason they never bothered with parallel compilation.
- luriel 14y agoGo does incremental compilation just fine. Nobody has bothered to add parallel compilation because building Go code is already so ridiculously fast.
- danieldk 14y ago...under the assumption that something does not depend on too many cgo packages.
- rogpeppe1 14y agoactually, the Go tool compiles packages in parallel by default.
- slurgfest 14y agoFast is relative to purpose. Maybe could afford to be faster in the context of an IDE checking your code on the fly, for a large project. I wouldn't know, since I have not attempted to write it.
- Locke1689 14y agoSource? That's not what the article says.
- cmccabe 14y agoThe 8g, 6g, etc compilers operate on a single .go file at a time. You're welcome to invoke them directly if you want.