3 ms·

Out in javascript land no one cares about file size or wire time any more (but should) -- Over in C, plenty of people work on things where file size matters. I

Out in javascript land no one cares about file size or wire time any more (but should) -- Over in C, plenty of people work on things where file size matters. It is a big deal. System constraints (embedded) wire constraints (far away systems where internet is slow and ephemeral), legacy systems where everything is going to be slow even moving that fat file around and you have to be present to update (ATM, ticket, vending machines)... The list goes on. So it may NOT matter for the desk top, or mobile or servers, but that's a tiny fraction of the computing out there.

lifthrasiir 3y ago
I do have a lower threshold for JS apps, which is about 200 KB. This difference accounts for the fact that websites can be streamed while executables can't. I'm not saying that we shouldn't optimize for the size---rather I'm saying the size optimization is not worthwhile under some threshold.
- flohofwoe 3y ago
  Many MMOs do actually download updated client executables on the fly in the launcher, and that shouldn't make the player wait more than necessary. Even the Steam client has such an automatic update process (and at 200 MBytes this is already in "very annoying" territory IMHO).
  - lifthrasiir 3y ago
    I mean, yes! Games are on the opposite end of the spectrum, where uncompressed assets fly around and 100 MB sounds like very small. These are what I refer to "low-hanging fruits"---I expect a moderate effort can halve the total size for most cases. (I did work on asset file formats back when I was a gamedev.) 400 KB executable is not really a big deal compared to that.
- pdimitar 3y ago
  I agree with the threshold argument but I guess it differs for all of us. To me 4MB Hello World program is hilariously bad. I want Rust to compete with C. Not be better or even equal to C when it comes to binary sizes, but I want it to be close.
  - lifthrasiir 3y ago
    I agree that 4 MB is bad, but I felt 400 KB is fine given all circumstances. If Rust really wants to minimize any overhead in spite of the necessity of backtrace supports, there are indeed many ways to minimize the cold section of executable. Even a simple compression will work---especially given that we already have a copy of miniz-oxide there! So try that if you are motivated, and I would more than welcome that effort, but Rust has way, way more important things to do than that.
    - pdimitar 3y ago
      I am 100% sure there are much important issues right now and I sympathize with the lack of bandwidth. The one thing I am claiming is that some lower-hanging fruit (if it is indeed that; might be super complex in fact) carries a significant positive public relations / image potential which should IMO be picked / harvested. (EDIT: I am talking about the `build-std` work here, not the default strip debug info flag.)
- zer00eyz 3y ago
  I dont have a hard limit for JS... What I have is a wall for functionality. Loading 700kb react blob (compressed mind you) so I can read a web page is a hard no. You want to give me a rich GUI to do data editing in a browser, bring it on, I'll take the down load. I know that rust and tiny go swap code here and there, binary sizes getting smaller on rust might make me give it a poke for some of the more "cute" embedded/iot things I like to play with... (another place where small matters!)
edflsafoiewq 3y ago
What? JS is the only ecosystem I know of that really cares about file size, to the point that it's expected to see the size of a library in release form (minified, gzipped) on its homepage. That's vanishing rare with any other language, including C.
JohnFen 3y ago
> Out in javascript land no one cares about file size or wire time any more Which is one of the reasons why I tend to leave JS disabled in my browser. Too many web devs have no care or concern for these sorts of things, which often makes JS a real resource drain.

lifthrasiir 3y ago

I do have a lower threshold for JS apps, which is about 200 KB. This difference accounts for the fact that websites can be streamed while executables can't. I'm not saying that we shouldn't optimize for the size---rather I'm saying the size optimization is not worthwhile under some threshold.

flohofwoe 3y ago
Many MMOs do actually download updated client executables on the fly in the launcher, and that shouldn't make the player wait more than necessary. Even the Steam client has such an automatic update process (and at 200 MBytes this is already in "very annoying" territory IMHO).
- lifthrasiir 3y ago
  I mean, yes! Games are on the opposite end of the spectrum, where uncompressed assets fly around and 100 MB sounds like very small. These are what I refer to "low-hanging fruits"---I expect a moderate effort can halve the total size for most cases. (I did work on asset file formats back when I was a gamedev.) 400 KB executable is not really a big deal compared to that.
pdimitar 3y ago
I agree with the threshold argument but I guess it differs for all of us. To me 4MB Hello World program is hilariously bad. I want Rust to compete with C. Not be better or even equal to C when it comes to binary sizes, but I want it to be close.
- lifthrasiir 3y ago
  I agree that 4 MB is bad, but I felt 400 KB is fine given all circumstances. If Rust really wants to minimize any overhead in spite of the necessity of backtrace supports, there are indeed many ways to minimize the cold section of executable. Even a simple compression will work---especially given that we already have a copy of miniz-oxide there! So try that if you are motivated, and I would more than welcome that effort, but Rust has way, way more important things to do than that.
  - pdimitar 3y ago
    I am 100% sure there are much important issues right now and I sympathize with the lack of bandwidth. The one thing I am claiming is that some lower-hanging fruit (if it is indeed that; might be super complex in fact) carries a significant positive public relations / image potential which should IMO be picked / harvested. (EDIT: I am talking about the `build-std` work here, not the default strip debug info flag.)
zer00eyz 3y ago
I dont have a hard limit for JS... What I have is a wall for functionality. Loading 700kb react blob (compressed mind you) so I can read a web page is a hard no. You want to give me a rich GUI to do data editing in a browser, bring it on, I'll take the down load. I know that rust and tiny go swap code here and there, binary sizes getting smaller on rust might make me give it a poke for some of the more "cute" embedded/iot things I like to play with... (another place where small matters!)

edflsafoiewq 3y ago

What? JS is the only ecosystem I know of that really cares about file size, to the point that it's expected to see the size of a library in release form (minified, gzipped) on its homepage. That's vanishing rare with any other language, including C.

JohnFen 3y ago

> Out in javascript land no one cares about file size or wire time any more Which is one of the reasons why I tend to leave JS disabled in my browser. Too many web devs have no care or concern for these sorts of things, which often makes JS a real resource drain.