Meta-issue: ICU4X as a low-level dependency

[sffc]

ICU4X aims to be lightweight and portable, and it achieves those goals after all is said and done, but during the build process, ICU4X is fairly hefty when it comes to linker size, compile times, source code size, and number of crates.

This was observed downstream in servo/rust-url#939 (#5120, #5121), as well as elsewhere.

There are low-hanging things we can do to improve this as well as other things that might have tradeoffs that we need to weigh.

CC @Manishearth @hsivonen

[sffc]

Notes from 2024-06-20:

Issues:

servo/rust-url#937
servo/rust-url#939

original PR: servo/rust-url#923

Discussion:

• @Manishearth - rust-url is a URL parser. The idna crate was reimplemented to be on top of icu4x, using the normalizer and the uts46 data. It removed a lot of implementation code and a dep on unicode-normalization. It also simplifies idna having to maintain its own tables. But, the icu4x dependency got backed out due to various issues which I'll list out. For crates like rusturl, here are the things their users want:
  • The lower down the dependency tree, the more conservative you need to be on MSRV, more conservative than a project of our size can be.
  • Compile times, especially depending on syn.
  • Sheer number of crates; more things to wrangle.
• @Manishearth - The end result is that their users don't like getting these extra dependencies. My take is that unicode_rs exists and is fine. People could add feature-gated dependencies on icu4x from these crates. I think we should ameliorate some of these problems. We don't need as many dependencies for baked data. Maybe we could get rid of icu_locale_core in icu_properties for example.
• @robertbastian - Do these crates use zerovec-derive?
• @Manishearth - It uses CodePointTrie.
• @robertbastian - We have 30 #[make_ule] in our repo. Can we just stop using it?
• @Manishearth - That buys us nothing. Even if we do that, they still won't take us as a dependency.
• @robertbastian - But syn is the biggest chunk.
• @Manishearth
• @sffc I do think from a policy position, it's important for us to endeavor to be friendly to the rust ecosystem. This is part of henri's work to integrate with firefox, and he wants to centralize the idna data with ICU4X. This is a positive change, and should be landed behind a feature flag. No controversy on those two things? (general assent from group)
• @sffc ICU4X is a library. It's not a final end product. Library typically means kind of low level in the tree.
• @sffc The core components of ICU4X, like zerovec and things. Let's look at zerovec itself; we want it to be a core utility. We've spent a lot of time investing into that for that purpose. zerovec requires syn which makes it more difficult for certain kinds of clients to depend on. icu_properties is low level and we should endeavor to make it clean. We can't get all the way to unicode-normalization, but we can get most of the way there.
• @sffc I don't agree with Manish's statement that there's nothing we can do to get to the point where people will use ICU4X in this crate as a low level dependency. ICU4X has a bunch of things going for it: our data model, the fact that we come from Unicode, the fact that we keep our data up to date. There may be some cost to that. On all three fronts: compile times, MSRV, depcount, we can make progress. There's a lot of low hanging fruit. If we tackled this low hanging fruit, we may be able to get clients to adopt ICU4X.
• @Manishearth - People using rust-url aren't looking for zero copy deserialization.
• @Manishearth - Making a static-only properties crate seems like a win. But stopping using #[make_ule] is a cost to us and I don't see the tradeoff.
• @robertbastian - All I see on the issue is MSRV and compile times.
• @Manishearth - The others are things I expect will come up. This type of discussion has happened before.
• @sffc - The types of problems highlighted in this issue are exacerbated by rust-url being a low-level crate, but these problems are adoption problems for all types of clients.
• @Manishearth I think this should be a goal, I think this should be a goal which we are careful to sacrifice anything but developer time/prioritization for it (do not sacrifice code cleanliness or whatever)
• @sffc we can get rid of make_ule in properties with a macro probably
• @Manishearth agreed

[Manishearth]

Explicitly writing out some of the things I said during the meeting (but @hsivonen wasn't present):

In general I think serving lower-level crates is a good goal. But I want to highlight that these lower-level crates live on a spectrum, and rust-url is on the far end of that spectrum, it is used very heavily and the union of all it's users' needs can be rather precise.

I am very much in favor of identifying incremental changes that bring us closer to that end of the spectrum. There's a lot of low hanging fruit here, including getting rid of syn deps for many of our crates.

I am less in favor of treating "usable by rust-url as a default dependency" as a goal in and of itself. It's a good north star to aim for, but I want to caution us against having hope that it will happen, or treating it as a goal in service of which we sacrifice other stuff, like code cleanliness or unsafe code proliferation. I'm happy to see Henri continue to discuss the topic on the rust-url thread since there is still some chance, but I don't want ICU4X to treat this as something definitely achievable.

(The situation I really wish to avoid is that we start giving up other things in service of making rust-url a client, and then rust-url's users oppose it anyway)

[Manishearth]

Full list of low hanging fruit that comes to my mind:

• Adding macro solutions to #[derive(ULE, VarULE)]` could be more useful for simple wrapper types #2310 , Add ULE derives compatible with repr(transparent) #2778 to reduce the bulk of our derive(ULE)
• Potentially getting rid of yoke dependency for static data providers
• Getting rid of locale deps for non-locale-based data loading. Unsure how that would work.
• Better decoupling crates, normalizer may not need to depend on all of properties

[djc]

Appreciate this discussion! While I agree that url might be on the far end of what low-level dependencies require, in the end I think much of ICU4X is sort of conceptually a low-level dependency due to the subject matter, and so IMO it would be great if it was an awesome candidate across the board for all sorts of low-level crates. For one example, I'm also a chrono maintainer and I think depending on date/time internationalization stuff from ICU4X has come up, but in my perception chrono is probably even more low-level than url.

For crates that are all part of the same ecosystem, maybe it would be reasonable to expand "macros" using pre-publish codegen? This can be a pretty nice technique for moving compile-time dependencies to dev-dependencies and generally help save compile time -- I imagine a lot of the Unicode data is statically known based on data files and doesn't conceptually need to be derived/compiled by downstream projects?

See things like mattsse/chromiumoxide#80 and https://github.com/open-telemetry/opentelemetry-rust-contrib/blob/main/opentelemetry-stackdriver/tests/generate.rs.

[robertbastian]

For crates that are all part of the same ecosystem, maybe it would be reasonable to expand "macros" using pre-publish codegen?

This will put unsafe code into every crate, which people generally dislike.

[djc]

For crates that are all part of the same ecosystem, maybe it would be reasonable to expand "macros" using pre-publish codegen?

This will put unsafe code into every crate, which people generally dislike.

IMO that's just silly -- whether you publish code with derive macros that then goes to expand to unsafe or have code generating code with unsafe in it pre-publish is exactly equivalent, and I don't think you should be afraid of making this argument. It should be more about ensuring the used abstractions are safe in practice.

[robertbastian]

This makes a big difference for auditing. You have to audit the code of the derive macro once, but when it's inlined you have no guarantee where it came from, and you'll have to audit it hundreds of times.

[djc]

But if you're generating code within crates originating from the icu4x project, surely the auditing issue is solvable?