Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Rust bloat

raphlinus.github.io

Post reply on HN
Print view View original

261–270 of 313 posts

Re: Thoughts on Rust bloat

#261

Post by ChrisSD »

anp wrote: post #257
ChrisSD wrote: post #240

Earlier quoted context omitted.

But the std hashmap implementation[0] already depends on a PRNG via the rand crate[1], and thus OS random (for the initial seed). So it's in the standard library even if you can't use it directly. Which is what makes me think this is an API issue, not an implementation one. [0]: https://doc.rust-lang.org/std/collections/hash_map/struct.Ra... [1]: https://docs.rs/rand/0.7.0/rand/rngs/struct.ThreadRng.html

It does depend on this yes, but the random seed isn’t part of the public API. An RNG API in std would need to pick an algorithm and make that part of its stability guarantees.

In this case I'd quibble that it wouldn't need to guarantee a specific algorithm, just a minimal set of properties. If the user can't manually set the seed then they'll be no expectation that it's deterministic or follows any particular algorithm. So the precise implementation can change with versions or even platforms.

Javascript's Math.random and Crypto.getRandomValues works this way.

Re: Thoughts on Rust bloat

#262

Post by steveklabnik »

throwupaway123 wrote: post #255
kd5bjo wrote: post #199

Earlier quoted context omitted.

Is there a list of these somewhere? Crates.io doesn’t appear to let me sort by author.

This is the GitHub repository https://github.com/rust-lang-nursery/

We’re in the process of deprecating the nursery, so they’ll end up in the rust-lang org at some point.

Re: Thoughts on Rust bloat

#263

Post by steveklabnik »

sanderjd wrote: post #196
steveklabnik wrote: post #170

Earlier quoted context omitted.

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?

We’ll see; it’s not a simple thing.

In theory they can move into the standard library, but none ever have. The process exists though.

Re: Thoughts on Rust bloat

#264

Post by pjmlp »

floatboth wrote: post #249
pjmlp wrote: post #181

Earlier quoted context omitted.

Yes it is bloat. Just go at any iOS or Android conference discussing user monetization. APK/IPA sizes are the number one reason why consumers uninstall software and the reason behind the ongoing module format efforts from Apple and Google. I have written GUI apps that could fit in a floppy.

No way. Most people don't know the sizes of their apks. > discussing user monetization Monetization must be a much bigger reason. A lot more users would angrily uninstall an app that showed them a giant full screen ad.

There are plenty of WWDC, IO and Android Summit talks about this subject, just in case you want to improve your knowledge.

Re: Thoughts on Rust bloat

#265

Post by pjmlp »

howdydoo wrote: post #256
pjmlp wrote: post #238

Earlier quoted context omitted.

So do Basic, Ada, Pascal, C and C++ as well, and yet they have richer standard libraries, with deployment profiles.

>deployment profiles In other words, not all functions in the stdlib of Ada, Pascal, C and C++ can be used in all possible target environments? Sounds like a failure to quality gate those standard libraries.

Nice jab try there, the suble point you are missing is that a deployment profile still is a guarantee of support.

There aren't an endless number of profiles.

Re: Thoughts on Rust bloat

#266

Post by Macha »

home_project123 wrote: post #243

How many people would use a Rust cloud compiler? Suppose it cuts build time from 5 minutes to 30 seconds.... Technically, a transparently mirrored file system, a strong compiler cluster (memory, cores, etc). And some predictive ML. But you end up with a binary-equivalent (verifiable) output. Any thoughts ?

I wouldn't use it. Incremental builds aren't that bad, and I'd have a hard time trusting third party compiled libs enough to include in a release from a new service that hasn't built up trust the way that say a Linux distro has.

While you could assume any maliciousness or security compromise would be caught, as you can see from the rubygems news today this is not instant and it adds another point of failure.

Re: Thoughts on Rust bloat

#267

Post by jchw »

jacques_chester wrote: post #153
burntsushi wrote: post #98

Earlier quoted context omitted.

I like Go's standard library. It's well designed. The number of pitfalls is pretty small. I have more thoughts, but they are very hand wavy and ill-formed, so please take them with a grain of salt. One of my theories for why the Go standard library has had as much success as it has, is that it doesn't necessarily provide implementations that go as fast as reasonably possible, and that tends to give more flexibility f…

> I like Go's standard library. It's well designed. It feels to me more like code incidental to other purposes than a library-as-library. Some folks like that and extracting from a concrete use is often instructive and efficient. On the other hand, there is a truly maddening inconsistency in whether you get an interface or a physical struct. One of these lends itself to easy replacement, injection and mocking. The ot…

> On the other hand, there is a truly maddening inconsistency in whether you get an interface or a physical struct.

That’s an issue, though it’s also one with most Go libraries too.

The thing is though, unnecessary interfaces also kind of suck. It makes code harder to follow, when the concrete type is hidden behind an interface. Also, one of the things that’s common in Go is testing with real implementations, rather than mocking - and I used to do just that. Even with Redis, I had a tiny shim server that implements the Redis protocol, that I would use in tests. Not absolutely everything can be done efficiently this way, but the virtues of testing with real clients are hard to ignore. Mocks and stubs can hide a lot of bugs that you would need to hope are caught by slower integration or e2e tests... And by virtue of being slower, they generally would cover less branches, too.

> Then there's errors. But that's another day's rant.

Have you kept up with the latest? I think they’re headed in the right direction with errors. Specifically with Is and As, along with the %w directive. The %w directive is a bit weird, but honestly, it’s a clever solution, and it seems like it would work.

Re: Thoughts on Rust bloat

#268

Post by majewsky »

fnord123 wrote: post #231
majewsky wrote: post #216

Earlier quoted context omitted.

My main gripe with crates.io is that they allowed everyone to take every name. The "foo" crate just belongs to the first person who took (or squatted) that name, regardless of whether that person actually implements a nice library under that name. What they should've done is allow uploads only to " / ". So if I decide to make a regex crate, it's called "majewsky/regex" at first and Alice can make "alice/regex" and Bo…

Apparently that was done in the Ruby community and Github "helpfully" uploaded all the Ruby packages to the gems repository meaning all 217 forks of https://github.com/httprb/http became potential gems. But the underlying idea is sound: namespace and federation. Rust should ideally follow Java's solution. And it's completely forward portable: when namespacing is introduced, the crates.io/regex crates become io.crates…

I don't particularly like URL-derived package names, esp. with Go where the repo URL is auto-derived from the package name, because that makes it an absolute pita to move the repo to a new canonical location.

Re: Thoughts on Rust bloat

#269

Post by p0nies »

Freak_NL wrote: post #198
kd5bjo wrote: post #192

Earlier 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.

Anyone can search for "awesome [lang]" when they want such a thing.

Re: Thoughts on Rust bloat

#270

Post by sitkack »

weinzierl wrote: post #194
sitkack wrote: post #167

Earlier quoted context omitted.

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.

It also has a wealth of options for tracking compilation time down to the dependent crate level.
Post reply on HN