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

181–190 of 313 posts

Re: Thoughts on Rust bloat

#181

Post by pjmlp »

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.

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.

Re: Thoughts on Rust bloat

#182

Post by pjmlp »

Scuds wrote: post #43
xyzzyz wrote: post #34

Earlier quoted context omitted.

I think a GUI app in 6MB is hugely impressive. You think that because nobody cares about bloat anymore, so everything else is large.

If you want to code a large app in C with X Athena Widgets or Win32 you're welcome to do so.

Why endure such pain?

We already could use Turbo Pascal (OWL), Delphi (VCL) and C++ (VCL, MFC, OWL) on Windows 3.1 and deliver applications that could fit on a floppy.

Re: Thoughts on Rust bloat

#183

Post by deafcalculus »

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.

Dynamic libs on the file system are awful. It's OK if the kernel wants to conserve RAM by sharing code pages that are identical, but saving hard disk space with dynamic libs is so painful.

Re: Thoughts on Rust bloat

#184

Post by anp »

vunie wrote: post #105
anp wrote: post #90

Earlier quoted context omitted.

I agree that in many cases a much simpler API would suffice, but it strikes me as odd to suggest adding a convenient but insufficient-for-security API to the same standard library that protects HashMap against DoS.

The request here is for a simpler API. I and many others would be more than happy to get a function that returns a random u64. No traits, no crippling commitments to a specific API design.

The API you describe, IIUC, can’t be serviced faithfully on the OSes targeted by std while being backed by real entropy.

Re: Thoughts on Rust bloat

#185

Post by anp »

anp wrote: post #90
raphlinus wrote: post #82

Earlier quoted context omitted.

I admit, design of a proper random number library API is tricky, and experience from deploying rand will no doubt be invaluable. The point I was trying to make is that some use cases require sophistication such as being able to choose different algorithms, but a lot of the times rand shows up in a build time histogram, it's just because the user wanted some pretty good random numbers; a much simpler API would suffice…

I agree that in many cases a much simpler API would suffice, but it strikes me as odd to suggest adding a convenient but insufficient-for-security API to the same standard library that protects HashMap against DoS.

(past edit window) This was written with hostility I don’t feel. Sorry Raph!

Re: Thoughts on Rust bloat

#186

Post by nonbirithm »

vvanders wrote: post #80
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…

On the flip side Lua is a wonderful language because its small lib lets it go anywhere. We used to run a whole gamestate of a shipped title on PSP in a 400kb block allocation. I've yet to see that in any other dynamic language of consequence.

LuaJIT is incredibly fast. It might just be the fastest scripting language out there.

I think this was only possible because Lua itself is such a simple language. It says a lot that LuaJIT's implementation of this simple language is extremely complex in comparison to vanilla 5.1. Imagine the added complexity for something like Ruby that offers more than one associative data structure.

With LOVE you get a complete game engine runtime with all the boring OS abstractions taken care of and you can just start working.

I tried a few game development bouts with Rust since it seemed like a natural step up from C++ but the compile cycle kills a lot of my creative drive.

I think this is just a consequence of the language being compiled, as with C++. With Rust having a wide variety of language features the compile time is increased also. At least we're lucky to have languages today that offer far shorter turnaround times for building prototypes.

Re: Thoughts on Rust bloat

#187

Post by jcelerier »

Jasper_ wrote: post #143
pcwalton wrote: post #139

Earlier quoted context omitted.

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.

hm, I've run a lot of profiling of various software through the years and never once instruction cache misses have been a problem, in large template-rich boostful C++ codebases

Re: Thoughts on Rust bloat

#188

Post by erik_seaberg »

bluejekyll wrote: post #113
sanderjd wrote: post #86

Earlier quoted context omitted.

I think not anymore since java.time - which is incredibly similar to Joda - came around? This is actually an illustrative example of the process I like and hope rust will develop over time: let the community reach a consensus on the best third party libraries things, then consider pulling them in to or at least taking the best parts of their APIs for the standard library.

But won’t the community converge on that anyway, and in a similar amount of time? So why add it to the stdlib?

The JRE should be self-sufficient. By bundling java.time, it can finally start offering methods that take and return those types, instead of the current jumble of millis, nanos, long+TimeUnit pairs, Dates, and Calendars.

Re: Thoughts on Rust bloat

#189

Post by Jweb_Guru »

jnordwick wrote: post #102
pcwalton wrote: post #24

Earlier quoted context omitted.

> Also be aware that highly inlined code does nicely in microbenchmarks but might have significantly negative performance implications in a larger system when it blows out the I-cache. I see this assertion a lot, but I have never actually seen a system in which inlining that would otherwise be a win in terms of performance becomes a loss in a large system. LLVM developers seem to agree, because LLVM is quite aggressi…

Any time you have an error/exception/abort path, you always never want to inline it (LLVM prob has attributes to prevent that, but I'm not sure if they are used by rust). Also, LLVM does get a little too aggressive with things like unrolling so I wouldn't be surprised if it inlined too aggressively too.

They are used by Rust.

Re: Thoughts on Rust bloat

#190

Post by jcelerier »

orf wrote: post #84
BubRoss wrote: post #57

Earlier quoted context omitted.

Fltk can give you a static binary on every platform where simple GUIs are under 100KB. Win32 isn't actually all that bad and getting simple GUI programs with icons under 10KB is completely doable. Thinking that GUIs need to be 6 MB or painful is a complete false dichotomy.

Arguing about 10KB or 100KB applications on a comment page that's 40kb in size is somewhat silly. It's _worth_ it to trade 1mb, 10mb or 100mb of app size in some cases. That's why you don't hand-craft your "simple 100kb guis" in assembly and have them only be 1kb. Exactly the same principle applies here. Plus, realistically, users don't care. Not one bit. That's why Slack is out here capturing the market, while some…

> Plus, realistically, users don't care. Not one bit.

I disagree. I develop an audio workstation - https://ossia.io ; the total size is between 50 and 100 megabytes depending on the platforms. It uses Qt and LLVM and is itself around 500kloc so I'm already around the lower limits of what I can do.

My users, & much people on the internet keep comparing it in size to Reaper, another DAW where the binary is around 10 megabytes (https://www.reaper.fm/download.php) - but they wrote their own gui toolkit and language interpreter.

Post reply on HN