5 ms·
>> Zig manages to provide many of the same features with a single mechanism - compile-time execution of regular zig code. > This is a huge one for me, and I re
by lifthrasiir 6y ago
>> Zig manages to provide many of the same features with a single mechanism - compile-time execution of regular zig code.
> This is a huge one for me, and I really don't understand why Rust didn't jump on this earlier.
I believe this outcome was mostly defined by the history. Here is my reasoning:
Rust, at least since 0.5, was undoubtly designed as a replacement for C++ (of course that doesn't necessarily mean that it only appeals to C++ programmers), and C++ was notable for its unexpected sophiscation and problems with its primary compile-time mechanism, templates in the other words.
Rust replaced templates with two other features: traits and reimagined syntactic macros. The former formalizes C++'s long-waited concepts feature and avoids issues with C++'s "ad hoc" polymorphism, while the latter deals with code generation, the remaining use of templates.
Traits (and lifetimes) required a complex type system, which takes time to compute and ideally the result for some file should be intact when other files have been changed. This constraint makes most additional compile-time mechanisms undesirable for addition because they can create unexpected dependencies between files, so recompiling one can trigger others. Note that the compile-time code is still a code, with states and everything attached, so this is far from trivial. (What if your compile-time code needs an external input?)
Zig and Nim show what the different starting point might result in: they didn't have to solve problems with C++ templates (among others), and could retain ad hoc polymorphism. This limits an ability to incrementally compile, and what's common with those languages? Much simpler type system, which compiles fast and makes the incremental compilation less concern for them. Rust needed a complex type system for its goals, which unfortunately limited its options for compile-time mechanisms.
- higerordermap 6y ago> Much simpler type system, which compiles fast and makes the incremental compilation less concern for them. Where is this "complex type system -> long compilation times" meme comes from? Most of rustc's time is spent in llvm. And bottlenecks are identified as monomorphization, producing large amount of LLVM IR and lack of binary dependencies. Type checking is a small portion of time, and not a bottleneck, IIRC.
- lifthrasiir 6y agoYou are absolutely true for the release build (sharing the same backend, Zig is also significantly slower in the release build). For the debug build however there may be multiple answers: typing, borrow checking (broadly this is a sort of typing), codegen and LLVM all can contribute significantly to the compilation time [1]. The situation may have been improved since the last time I've checked though. [1] https://wiki.alopex.li/WhereRustcSpendsItsTime https://wiki.alopex.li/WhereRustcSpendsItsTime (2019)
- higerordermap 6y agoDidn't know this. Thanks.