I don’t feel like rust compile times are that bad, but I’m coming from C++ where the compile times are similar or even worse. (With gcc at work a full debug build takes 40 minutes, with clang it is down to about 17.)
Rust isn’t an interpreted or byte code compiled language, and as such it is hard to compete with that. But that is comparing apples and oranges really. Better to compare with other languages that compile to machine code. C and C++ comes to mind, though there are of course others that I have less experience with (Fortran, Ada, Haskell, Go, Zig, …). Rust is on par with or faster than C++ but much slower than C for sure. Both rust and C++ have way more features than C, so this is to be expected. And of course it also depends on what you do in your code (template heavy C++ is much slower to compile than C-like C++, similarly in Rust it depends on what you use).
That said: should we still strive to optimise the build times? Yes, of course. But please put the situation into the proper perspective and don’t compare to Python (there was a quote by a python developer in the article).
Agreed. I have not asked myself dozens or hundreds of times why Rust compile times are slow. I have, however, asked myself why so many people consider Rust compile times as slow, especially people who might have fast compiles but then waste lots of time testing things manually or automatically that I don’t even have to worry about if my Rust code compiles.
That’s kind of true, but I came from Go, which has really fast compile times, which makes it really productive.
That said, I don’t use Go much anymore, so I’ve obviously found some value in Rust. I would like to see improvements though, but it’s fast enough for me to stick with it.
On the other hand in Go you have to literally implement every other standard library function inline yourself because of its lacking expressiveness and it is total cancer to read, at least in the cases of the Go programs I looked at to debug some things which I wouldn’t really consider productive.
I don’t feel like rust compile times are that bad, but I’m coming from C++ where the compile times are similar or even worse. (With gcc at work a full debug build takes 40 minutes, with clang it is down to about 17.)
Rust isn’t an interpreted or byte code compiled language, and as such it is hard to compete with that. But that is comparing apples and oranges really. Better to compare with other languages that compile to machine code. C and C++ comes to mind, though there are of course others that I have less experience with (Fortran, Ada, Haskell, Go, Zig, …). Rust is on par with or faster than C++ but much slower than C for sure. Both rust and C++ have way more features than C, so this is to be expected. And of course it also depends on what you do in your code (template heavy C++ is much slower to compile than C-like C++, similarly in Rust it depends on what you use).
That said: should we still strive to optimise the build times? Yes, of course. But please put the situation into the proper perspective and don’t compare to Python (there was a quote by a python developer in the article).
Agreed. I have not asked myself dozens or hundreds of times why Rust compile times are slow. I have, however, asked myself why so many people consider Rust compile times as slow, especially people who might have fast compiles but then waste lots of time testing things manually or automatically that I don’t even have to worry about if my Rust code compiles.
That’s kind of true, but I came from Go, which has really fast compile times, which makes it really productive.
That said, I don’t use Go much anymore, so I’ve obviously found some value in Rust. I would like to see improvements though, but it’s fast enough for me to stick with it.
On the other hand in Go you have to literally implement every other standard library function inline yourself because of its lacking expressiveness and it is total cancer to read, at least in the cases of the Go programs I looked at to debug some things which I wouldn’t really consider productive.