Re:C meeting is over. C23 added:
by flyinglizard on Saturday February 19, 2022 @05:45AM
(#30396068)
Why does it matter if compile time is 100ms or 300ms? At even a second, that’s going to be so negligible in the context of code-compile-debug work. Especially if something like a flash download is involved.
[ Parent
| on HN ]
The compilation time difference between C and Rust for nontrivial projects is much bigger than 3x.
Are there features you can ban in your style guide to prevent serious compile time problems?
Are your rust builds really that fast? Wth am I doing wrong! I'd love to measure it in seconds.
It's slow for me, but I'm not working on a very powerful machine.
That said, cargo check is fast, and my general experience with Rust is that it generally works once it compiles. People getting into more advanced features might have different experiences.
Re:C meeting is over. C23 added:
by bruce343434 on Saturday February 19, 2022 @06:09AM
(#30396192)
0. it is a noticeable delay and impinges my momentum
1. A flash download is not involved
2. I hardly debug. I seem to be in a minority here, but my linter really does catch pretty much everything. I don't blindly write code, I always ponder my approach first.
So basically, the compile times pull me out of the flow.
Very much with you on this one. Even with 50k+ LoC a 'make clean;make' takes less than a second (with help from ccache and a RAM disk). It effectively gets the compiler out of the way and keeps the thought processes continuous.
One trick I like is to have a 2nd terminal watching the file(s) I'm editing, triggering a make/run on each save; building and running is then a single keypress away:-
while [ 1 ]; do
inotifywait -e move_self foo.c
cc foo.c -o foo && ./foo # or 'make && ./foo'
done