So, indeed, it's not that much that Rust is a slow compiler, but rather that Rust projects end up compiling a lot of code: far more code than the equivalent counterparts written in other languages. And of course the issue is that this can very easily transitively scale up out of proportion: if the dependency pulled decided itself to also pull a convenience dependency, we suddenly end up with a cascade of dependencies. Which does come with its lot of problems, but does avoid having to pull and compile a full-featured dependency. Or to delegate to other command-line invocations / utilities ( Example. The difference between a standard C / C++ project and a Rust one, is that pulling a dependency within the former(s) is so painful that people will often prefer to:Įither quickly reimplement the logic for their reduced use-case ( e.g., your mentioning using iterator logic instead of a regex) This is so true: I've seen big C or C++ projects that also take astonishingly long to compile. So if the compiler is actually quite good already and has a team dedicated to making it faster, why does it seem so slow to so many Rust developers? My suspicion is that this conception is mostly self-imposed by developers who are quick to take advantage of just how effortless it is to bring in dependencies. It's just not possible to write your own tokio or tonic so there's no other option than taking the compile time hit (in my case, 30 dependencies to ~250, with a full build going from about 20 seconds to 3 or 4 minutes). Of course, this all goes out the window the moment you pull in any sort of web server or asynchronous runtime. a library could be discontinued and we're stuck with something that'll never get bug fixes or improvements, or it could have mission-critical issues like a security bug). Not only does this help keep compile times down, but it also reduces the amount of risk we're exposed to (e.g. When I use Rust at work I make a conscious effort to minimise the number of dependencies I pull in. What I've tried to show here is that a lot of what some might consider to be a "slow compiler" can be traced back to a developer not being diligent with dependency management, or preferring runtime performance over compile time, or even "developer velocity" over compile time (whatever that means!)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |