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

141–150 of 313 posts

Re: Thoughts on Rust bloat

#141

Post by pcwalton »

spieglt wrote: post #121
ajxs wrote: post #40

At the risk of being slightly tangential, I've been sorely wanting to air this particular grievance with Rust for some time. It's somewhat related, since the author mentions their package system. Its package ecosystem isn't nearly in the horrible state that node's is, but having a package system shouldn't be a substitute for designing a useful standard library for a language. I think that the attraction to 'small lan…

If Rust had a standard library like Go's I'd love it even more.

Even if that library had slow serialization like that of Go, forcing the use of packages to make it faster?

Re: Thoughts on Rust bloat

#142

Post by pcwalton »

ajxs wrote: post #40

At the risk of being slightly tangential, I've been sorely wanting to air this particular grievance with Rust for some time. It's somewhat related, since the author mentions their package system. Its package ecosystem isn't nearly in the horrible state that node's is, but having a package system shouldn't be a substitute for designing a useful standard library for a language. I think that the attraction to 'small lan…

Rust used to have getopt in the standard library. It was removed because it was bad. Clap only came later. I don't think Rust would have been a better language if the old getopt were kept around.

Re: Thoughts on Rust bloat

#143

Post by Jasper_ »

pcwalton wrote: post #139
Jasper_ wrote: post #47

Earlier quoted context omitted.

Fiora refactored the MMU code emitted by Dolphin to a far jump, which had significant performance improvements over inlining the code [0]. She had an article about it in PoC || GTFO [1]. [0] https://dolphin-emu.org/blog/2014/09/30/dolphin-progress-rep... [1] https://github.com/angea/pocorgtfo/blob/master/contents/issu...

Interesting, that's a good case. Though it's a bit of an extreme one, because it's jitcode for a CPU emulator. I'm not sure how relevant that is to Rust, though it's certainly worth keeping in mind.

In my experience, i$ is much bigger than everyone thinks, and they over-emphasize optimizing for it whenever someone brings up code size. It can soak up a lot. That said, for JITs, where code is not accessed very often and in weird patterns, it can matter quite a lot.

Re: Thoughts on Rust bloat

#144

Post by giancarlostoro »

ajxs wrote: post #40

At the risk of being slightly tangential, I've been sorely wanting to air this particular grievance with Rust for some time. It's somewhat related, since the author mentions their package system. Its package ecosystem isn't nearly in the horrible state that node's is, but having a package system shouldn't be a substitute for designing a useful standard library for a language. I think that the attraction to 'small lan…

> but having a package system shouldn't be a substitute for designing a useful standard library for a language.

Completely agree. I hold firm to the believe that a strong standard library that considers modern software development goals will drive the success of a language.

Look at Go. Which is usually my example since not many do what Go does. You can do a whole web application in Go with minimal use (if any) of external libraries.

Back to Rust and their defense: they intend to adopt popular / quality packages from Cargo into the standard library or fill the gap between packages.

I secretly wish D had similar things to Go in the standard library. HTTP and SMTP etc which Python seems to have at least HTTP and sadly Go ditched their SMTP package for whatever reason making it awkward.

I hate having to learn a new package manager per new language. I love programming so I try a lot of languages out of love. Package managers and build systems are horrible UX in every language. I prefer to not rely on third party oh look now deprecated packages and start out with whats out of the box.

Re: Thoughts on Rust bloat

#145

Post by leshow »

nerdponx wrote: post #2

It's a little unfortunate that some of the cool features of Rust need to be put into the "use sparingly" category. I know that polymorphism, async, etc. should be used judiciously anyway, but still. One recent case we saw a similar tradeoff was the observation that the unicase dep adds 50k to the binary size for pulldown-cmark. In this case, the CommonMark spec demands Unicode case-folding, and without that, it’s no…

> I know that polymorphism, async, etc. should be used judiciously anyway, but still.

I don't really see this recommended anywhere, especially re: polymorphism. Async _maybe_, but it's pretty situational.

Re: Thoughts on Rust bloat

#146

Post by leshow »

userbinator wrote: post #66
mapgrep wrote: post #20

>the release binary is now 5.9M A typical smartphone ships with around 10,000 times this much storage capacity and enough RAM to hold it 100 times over. This is bloat? I mean, I get it, the binary used to be only 2MB, 1/3rd the size. But are numbers this low really worth worrying about? I think a GUI app in 6MB is hugely impressive. I genuinely thought he was going to say it was 100MB or something higher.

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…

It's an apples to oranges comparison, you can't really say that one is "wasting" resources or not.

If you want to use windows as an example. Why not take the current version? It uses what like 16GB for a basic install (I wouldn't know, I don't use it)? Compare the 6Mb GUI framework to that.

Re: Thoughts on Rust bloat

#147

Post by raphlinus »

Animats wrote: post #118

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

Depends on the use case. I'm thinking about GUI, where on Linux you can write code that links against (say) Gtk, and thus can pull in lots of libraries while the executable itself is tiny. With the current state of the Rust ecosystem, you basically have to build the GUI toolkit and bundle it with your app.

Re: Thoughts on Rust bloat

#148

Post by roca »

ajxs wrote: post #40

At the risk of being slightly tangential, I've been sorely wanting to air this particular grievance with Rust for some time. It's somewhat related, since the author mentions their package system. Its package ecosystem isn't nearly in the horrible state that node's is, but having a package system shouldn't be a substitute for designing a useful standard library for a language. I think that the attraction to 'small lan…

This issue gets discussed over and over again.

Rust does need a better package curation story, a Rust "expanded universe" of recommended packages whose provenance is more carefully tracked than the average package and whose APIs are stable. The Rust community needs to encourage other packages to depend on stable versions in that recommended set to reduce duplication.

But going further and actually making that set to be part of the "standard library", and thus released at the cadence of the Rust language itself, and managed under the same umbrella, would be harmful.

Re: Thoughts on Rust bloat

#149

Post by ninkendo »

pcwalton wrote: post #141
spieglt wrote: post #121

Earlier quoted context omitted.

If Rust had a standard library like Go's I'd love it even more.

Even if that library had slow serialization like that of Go, forcing the use of packages to make it faster?

So we'd be no worse off than we are now? And just in that one case?

Re: Thoughts on Rust bloat

#150

Post by Qworg »

mmastrac wrote: post #120
burntsushi wrote: post #109

Earlier quoted context omitted.

At least from a licensing perspective, you should be all set. Virtually everything in the Rust ecosystem is permissively licensed. Trustworthy is another thing altogether though. How do you handle this process in C and C++? Both of those languages have fairly spartan standard libraries as well.

> Virtually everything in the Rust ecosystem is permissively licensed. I just did our license audit and 100% of our shipped deps were Apache | MIT. If you can clear those two licenses with legal, you should be good to go for virtually any crate. Might be worth releasing my one liner for this if anyone else finds it useful.

Please do.
Post reply on HN