| ▲ | steveklabnik an hour ago | |||||||
Yes, this idea is sort of similar, just like, more complicated in a sense than the clean design, which is what Zig does. Incidentally, you might want to look at gc-sections, which Rust already does. As well as https://rust-lang.github.io/rust-project-goals/2025h2/relink... which is kinda related. The sort of key here is understanding that "produce a library" means that every public item is "used" in the sense of "do we need to compile it." The real trick is to do demand-driven compilation starting from the actual final program's needs, and this is inherently at odds with the idea of producing standalone libraries and combining them into the final artifact. | ||||||||
| ▲ | saghm an hour ago | parent | next [-] | |||||||
Makes sense! I think what's most surprising to me about the library compilation model is that for the most part, it doesn't seem like it's actually that useful to how Rust does things by default. Without something like sccache, the intermediate libraries aren't going to be reused across all of my projects, so unless I'm compiling multiple binaries in the same project, I'm not really getting much out of having the entire library sitting there in my target directory rather than just the subset that I'm using. I'm guessing this is related to what you mean by potentially being able to do something differently if there were more time before 1.0? | ||||||||
| ||||||||
| ▲ | skavi 31 minutes ago | parent | prev [-] | |||||||
> The real trick is to do demand-driven compilation starting from the actual final program's needs this is not so far off from hint-mostly-unused, no? | ||||||||
| ||||||||