4 ms·
> but not if that same trick would shave 75% off a similar go- or c project. The question does apply to Go, but not C — because the way to reduce compile time
by eqvinox 6y ago
> but not if that same trick would shave 75% off a similar go- or c project.
The question does apply to Go, but not C — because the way to reduce compile time for C projects is to just not compile libraries & modules when you don't need to. That's the return from having a stable ABI.
(C++ might be the most interesting in this regard because there's both things - linked / ABI'd libraries as well as header-only "libraries")
[edit: "has" as in "is actually actively used" - of course you can create C-ABI libraries with Go and Rust too, but it's a rather rare practice]
- jatone 6y agouh what, go does exactly what you applaud C for, but better. go is extremely aggressive about not recompiling dependencies. you only pay a long compilation phase the first time you build something. after that its partial compilations all the way.
- berkes 6y agoRust does something similar though. Which is why OP was explicitely comparing clean(re)builds.
- eqvinox 6y ago> you only pay a long compilation phase the first time you build something I'm referring to the fact that there is no "first time build" using a library in C, since C libraries are installed as binaries.
- pjmlp 6y agoHow C++ deals with it depends on the project and OS. For example on Windows it is quite common to use binary libraries, compiled with the most common options. Additionally COM/UWP kind of work as OS ABI as well. Same applies to game consoles with their SDKs. And on other OSes, as long as you just use the official OS SDK compiler, there is a set of binary dependencies that you can just use straight away. Then the use case of using binary dependencies is so relevant for many corporations using C and C++, that the two major package managers, conan and vcpkg, both support using binary dependencies.