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

241–250 of 313 posts

Re: Thoughts on Rust bloat

#241

Post by burntsushi »

pjmlp wrote: post #234
burntsushi wrote: post #232

Earlier quoted context omitted.

I don't understand what point you're trying to make. All I did was ask a simple question: if trust in Rust is hard, how do you handle trust in other ecosystems? The details on exactly how big or how small the standard libraries are (or why they are that way) are less important for this particular question. Consider the size of Python's standard library vs C or C++ or Rust. The size of C or C++ is much closer to Rust'…

My point is that although many only think about ISO C libc when talking about C's standard library, the reality is that with a few exceptions, libc always goes alongside POSIX across the large majority of platforms with a C compiler. So in reality POSIX complements libc as C's "runtime platform", even though ISO C never considered to make libc that big. My historical context is how I experienced how things went, thro…

> My point is that although many only think about ISO C libc when talking about C's standard library

I wasn't. Even with POSIX, it is spartan by today's standards. Look at the standard libraries of Python and Go. POSIX doesn't have JSON (de)serialization, HTTP servers, XML parsing and a whole boatload of other crap. So I don't think there is anything wrong with my characterization.

Re: Thoughts on Rust bloat

#242

Post by Amezarak »

stouset wrote: post #60
Amezarak wrote: post #56

Earlier quoted context omitted.

There are a lot of us out there with dev and prod environments that aren’t allowed to be connected to the Internet or otherwise strictly controlled. Languages that rely on me downloading packages are mostly dead in the water at my workplace.

Virtually no modern language or package system requires this. All of them allow you to cache dependencies locally, so they can be committed to version control or otherwise put in place during deployment however you see fit.

Maybe I didn't communicate my point clearly. I cannot just go out and get whatever dependencies I want to use. It isn't possible. What I have on the system is what I've got, and I can't add anything. I cannot put the dependencies on the system by any means.

Thus a lot of things get done in Python and Java, because of the ample standard libraries. I was able, after a year of lobbying and procedures and approvals, to get a Rust compiler, but there is zero chance of me ever getting anything off crates.io.

Re: Thoughts on Rust bloat

#243

Post by home_project123 »

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 ?

Re: Thoughts on Rust bloat

#244

Post by home_project123 »

Macha wrote: post #44
Scuds wrote: post #39

Earlier quoted context omitted.

Cargo compiles dependencies in parallel so if you have lots of cores you'll hear your fans spin up. I see a lot of difference between my i5 laptop and i9 desktop.

As a case in point, I have a project that uses amethyst and nalgebra (and their 200 transitive dependencies). On upgrading from an OC i5-4670k to a r9-3900x, my compile times for a clean release build went from 20 minutes to 2.

I added a comment about a cloud builder. Would appreciate comments.

https://news.ycombinator.com/item?id=20767201

Re: Thoughts on Rust bloat

#245

Post by [deleted] »

pjmlp wrote: post #238
nicoburns wrote: post #235

Earlier quoted context omitted.

Not really. Rust supports 8 bit microcontrollers. Lot's of libraries, including parts of the standard library make no sense on these kind of platforms. The standard library and 3rd party crates generally have excellent compatibility across mainstream platforms.

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

[deleted]

Re: Thoughts on Rust bloat

#246

Post by floatboth »

pjmlp wrote: post #238
nicoburns wrote: post #235

Earlier quoted context omitted.

Not really. Rust supports 8 bit microcontrollers. Lot's of libraries, including parts of the standard library make no sense on these kind of platforms. The standard library and 3rd party crates generally have excellent compatibility across mainstream platforms.

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

Since when does libc include "rich" things like regex, serialization and http?? Even C++ standard lib is mostly containers and algorithms.

libc is barely a standard library, it's almost nothing.

Re: Thoughts on Rust bloat

#247

Post by floatboth »

adrianN wrote: post #193
orf wrote: post #78

Earlier quoted context omitted.

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

The screens alone are responsible for a lot of size increases (framebuffers in RAM, high res media) but also, unlike in Windows 3.11, modern Word allows you to mix English, Japanese and Arabic in a document, allows use of a screen reader, and has a thousand features that you personally don't need but everyone has some set of features that they use, and taking away any of them would offend someone.

Re: Thoughts on Rust bloat

#248

Post by xenocratus »

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.

Rust is used a lot for embedded development, and the memory available on an IoT device is nowhere near that of a smartphone. You probably won't want a GUI running on an IoT sensor, but you might need a network stack, maybe some data processing...

Re: Thoughts on Rust bloat

#249

Post by floatboth »

pjmlp wrote: post #181
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.

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.

Re: Thoughts on Rust bloat

#250

Post by pjmlp »

floatboth wrote: post #246
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.

Since when does libc include "rich" things like regex, serialization and http?? Even C++ standard lib is mostly containers and algorithms. libc is barely a standard library, it's almost nothing.

C might not include those specific examples, but POSIX + libc already include plenty of stuff.

C++ surely does include regex, with serialisation and http scheduled for C++23, or with luck with a TR as intermediate delivery.

Although serialisation depends on static reflection being finalized as well.

Post reply on HN