It looks like the `fluent` library is to blame for the bloat here.
I have myself made another localization library that use a simpler model and compiles quite fast when using the rust `gettext` backend: https://github.com/woboq/tr
Thoughts on Rust bloat
191–200 of 313 posts
Re: Thoughts on Rust bloat
#192Earlier quoted context omitted.
Python's standard library is where things go to die because of the terrible adhoc versioning system (the module name is the version number) and dynamic typing means they are afraid to change anything. But even then it's still better than having no standard library at all. The advantage of a standard library is that you only need to learn one API instead of a dozen different APIs for doing the same thing, which means…
> The advantage of a standard library is that you only need to learn one API instead of a dozen different APIs for doing the same thing, which means you can develop a degree of mastery over it. The rust ecosystem has done well to converge on certain crates as sort of replacement for missing std features. In practice (at least in the rust ecosystem), I only need to learn one interface for: * regex (regex) * serializat…
As a relative outsider, it’s not obvious at all that these are the right crates to choose. I appreciate the commitment to long-term stability that the standard library appears to have, but that benefit goes out the window if I accidentally rely on a third-party crate that changes its API every six months.
Looking at crates.io, regex looks pretty safe, as it’s authored by “The Rust Project Developers” and includes explicit future compatibility policies. Unfortunately, I can’t find an index of only the crates maintained by the Rust team.
Serde is obviously popular, but at first glance is a giant Swiss Army knife that will likely have lots of updates to keep track of that are completely unrelated to my project (whatever it is). If I search for JSON, I get an exact match result of the json crate, followed by a bunch of serde-adjacent crates, but not serde itself.
Request hasn’t been updated in 4 years, and has a total of less than 7000 downloads.
Re: Thoughts on Rust bloat
#193Earlier quoted context omitted.
I think a GUI app in 6MB is hugely impressive. Windows 3.11 required 4MB of RAM and the whole install took the entire OS with all of its utilities and libraries. A typical smartphone ships with around 10,000 times this much storage capacity and enough RAM to hold it 100 times over. The fact that it can hold that much does not make it right to waste resources. To contrast, video or audio is a good use of the space it…
> Windows 3.11 required 4MB of RAM and the whole install took Sure, and the moon landing used computers with less processing power than your kids calculator. That doesn't mean we should use those to put people on the moon over faster hardware. Does the fact that older, slower and smaller hardware and software once existed mean we should spend time, resources and potentially sacrifice features to... what? Hark back to…
If today's computers did things a million times better, or did a million more things than 25 years ago, I'd agree with you, but from a user perspective a modern computer is not really all that different from a Windows 3.11 machine. The screens are bigger and we have Internet now, but the experience of, e.g., writing a letter in Word is basically the same.
Re: Thoughts on Rust bloat
#194> There’s also an effort to analyze binary sizes more systematically. I applaud such efforts and would love it if they were even more visible. Ideally, crates.io would include some kind of bloat report along with its other metadata, [...] This is what I always wanted (for Rust as well as for C) but never got around to hack together myself. I dreamt it up more as a feature of cargo though, something like 'cargo stats'…
You might be looking for `cargo install cargo-bloat` $ cargo bloat Compiling ... Analyzing target/debug/mdbook File .text Size Crate Name 0.5% 1.3% 166.4KiB regex ::captures_read_at 0.5% 1.3% 165.2KiB idna unicode_normalization::tables::compatibility_fully_decomposed 0.3% 0.7% 95.0KiB ammonia html5ever::tree_builder::TreeBuilder ::step 0.3% 0.7% 92.5KiB idna unicode_normalization::tables::canonical_fully_decomposed 0…
Awesome.
Re: Thoughts on Rust bloat
#195Earlier quoted context omitted.
> The advantage of a standard library is that you only need to learn one API instead of a dozen different APIs for doing the same thing, which means you can develop a degree of mastery over it. The rust ecosystem has done well to converge on certain crates as sort of replacement for missing std features. In practice (at least in the rust ecosystem), I only need to learn one interface for: * regex (regex) * serializat…
Do they also compile and run across all platforms supported by rust compiler? Because that is the biggest asset from stuff being in the standard library.
No, but not all parts of std run on all supported platforms.
To clarify, there are different levels of support on different platforms.
Re: Thoughts on Rust bloat
#196Earlier quoted context omitted.
There's a cost to discovering the consensus choices that I think inclusion in a standard lib minimizes. But there may be other similarly good ways to accomplish this. If I'm remembering correctly, doesn't Rust have a set of libraries that aren't in the standard library but are somehow vouched for? Maybe that's a similarly good approach to solve the discovery problem, I'm not sure.
There are libraries that are maintained by the project itself, but are not part of the standard library, yes.
Ok thanks. Is the intention for that to grow, as a curated set of libraries that isn't quite the standard library? Or so you think some of those will move into the standard library if they become canonical or stable enough?
Re: Thoughts on Rust bloat
#197Do dynamic libraries really help? They only save space in the case where 1) you are running many different programs and 2) they all use the same libraries in the same versions. If you're running multiple copies of the same program, they share code, at least on Linux.
> running many different programs and they all use the same libraries in the same versions
It's distro maintainers' job to test packaged apps and converge on a known-good version of a shared lib. This is only a problem if your distro doesn't package the apps you need, and you build from upstream source ignoring the distro and using all the random versions upstream happened to test.
Re: Thoughts on Rust bloat
#198Earlier quoted context omitted.
> The advantage of a standard library is that you only need to learn one API instead of a dozen different APIs for doing the same thing, which means you can develop a degree of mastery over it. The rust ecosystem has done well to converge on certain crates as sort of replacement for missing std features. In practice (at least in the rust ecosystem), I only need to learn one interface for: * regex (regex) * serializat…
As a relative outsider, it’s not obvious at all that these are the right crates to choose. I appreciate the commitment to long-term stability that the standard library appears to have, but that benefit goes out the window if I accidentally rely on a third-party crate that changes its API every six months. Looking at crates.io, regex looks pretty safe, as it’s authored by “The Rust Project Developers” and includes exp…
That sounds like something that could be solved by having crates.io provide a curated list of common popular crates for certain features. That is, this seems to be mostly a documentation issue.
Re: Thoughts on Rust bloat
#199Earlier quoted context omitted.
There's a cost to discovering the consensus choices that I think inclusion in a standard lib minimizes. But there may be other similarly good ways to accomplish this. If I'm remembering correctly, doesn't Rust have a set of libraries that aren't in the standard library but are somehow vouched for? Maybe that's a similarly good approach to solve the discovery problem, I'm not sure.
There are libraries that are maintained by the project itself, but are not part of the standard library, yes.
Is there a list of these somewhere? Crates.io doesn’t appear to let me sort by author.
Re: Thoughts on Rust bloat
#200Earlier quoted context omitted.
As a relative outsider, it’s not obvious at all that these are the right crates to choose. I appreciate the commitment to long-term stability that the standard library appears to have, but that benefit goes out the window if I accidentally rely on a third-party crate that changes its API every six months. Looking at crates.io, regex looks pretty safe, as it’s authored by “The Rust Project Developers” and includes exp…
That sounds like something that could be solved by having crates.io provide a curated list of common popular crates for certain features. That is, this seems to be mostly a documentation issue.
It’s really a reputation bootstrapping problem, for which popularity can be a useful proxy. For me to use third-party code, I have to trust that the future behavior of the developers will be reasonable: I want my side projects that don’t get touched for months or years to still mostly work when I get back around to them.
Not everyone or every project will have the same desires, though. Sometimes, a fast-moving experimental library is the right choice. The trouble is figuring out which I’m looking at.