3 ms·
It’s not meant to be helpful. It’s simply the truth. They’re literally talking about 15 seconds. I’m sorry, but if you’re looking for subsecond compile times,
by jonathankoren 3y ago
It’s not meant to be helpful. It’s simply the truth. They’re literally talking about 15 seconds.
I’m sorry, but if you’re looking for subsecond compile times, you’re simply not going to get it in C, C++, Java, or really any statically typed compiled language for any project that isn’t trivial —- no matter how many dynamically linked libraries you break your project up into.
They want a REPL, and they’re just not going to get one while dealing with these technologies.
Even your idea of creating a million tiny libraries to achieve less than 15 second compilation and launch time is insane, because now you’ve just “solved” developer efficiency by creating a deployment and maintenance nightmare.
It’s not a serious solution.
- lelanthran 3y ago> m sorry, but if you’re looking for subsecond compile times, you’re simply not going to get it in C, C++, Java, I always get subsecond compile times when actively working in C, until headers are changed. Single files take milliseconds to compile, and you ordinarily aren't changing multiple files at a time. A 2000 line module I was working with was compiling in about 20ms, with a clean performed beforehand. My last project, around 10k sloc in about 6 modules compiled and linked in under 1s. The exception to this is embedded environments which run cmake more often than required (specifically the ESP32 IDF) or similar.
- akvadrako 3y agoThis is not true at all in any of those languages. For example in C, With a good build system setup, modifying just one .c file means only that file needs to be compiled, then you only need to run the linker. Even if the program is very large and linking everything takes many seconds, breaking up the program into dynamic libraries should get you sub-second compiles.