Whole program dead code elimination doesn't have to be slow. Nim does that by default (it's not possible to turn it off since a couple releases actually) and it still compiles quite fast.
Again, my recommendation wasn't that, it was that the core team consider releasing "core" language features like Unicode support as first-party crates when they don't make sense as part of 'stdlib' not that I think they will. Feels weird to me that I have to rely on the goodwill of third parties to provide core language functionality like complete string handling.
As soon as you have to add a crate, you are in for extra review and pain.
> it was that the core team consider releasing "core" language features like Unicode support as first-party crates
what you were asking for?
Side-note I really appreciate all the work you folks are doing. Rust has changed the way I write software even when I'm not writing Rust, which is about the highest praise I can offer.
I'd love to pitch in.
Thanks :)
... how would you like to pitch in? I can point you to the right people. We're always happy to have more help.
In fact, LTO/WPO have nothing to do with the ability to link whatever is needed.
The only one that can strip is the end user compiling a final binary, and the compiler often cannot do this for you because that requires whole program optimization and full LTO, which is super super slow.
Also, just because the final binary doesn't use a symbol, doesn't imply that the symbol isn't used. You can ship a library with a main function that can be run as an executable, or linked as a library. The linker doesn't know.
You would really need to go out of your way to strip your binary for your particular application. This is possible, and not that hard.
But the point remains: why should 99% of Rust users have to go through the trouble just so that those who need this don't have to write `cargo add unicode-segmentation` ?
Rust philosophy is "don't pay for what you don't use", so if your organization doesn't support third-party dependencies, they need a language with "batteries included", and not a language like Rust that comes without batteries by design.
Proposing to make Rust come with batteries included is proposing to change one of Rust's core values. Go ahead and write an RFC for that. I'll get my popcorn.