4 ms·

Next thing we know, every program is gonna ship with either a slimmed-down (!) 20MB JRE (if you use modules, otherwise it's gonna be worse), 130MB Electron runt

by ylyn 7y ago

Next thing we know, every program is gonna ship with either a slimmed-down (!) 20MB JRE (if you use modules, otherwise it's gonna be worse), 130MB Electron runtime (this makes bundling the JRE seem like a good option), or what have you.. Wait, I think we're already in that era. Oh well. (Cue "but disk space is so cheap nowadays"...)

sqldba 7y ago
Isn’t the whole point of dotnet that it ships with all the executables, libraries and binaries too? I don’t know how I feel about it myself.
- chusk3 7y ago
  You can choose to do a self-contained deployment, which bundles the runtime with your app, or a framework-dependent deployment, which requires a pre-existing shared install. Pick your poison.
danpalmer 7y ago
> (Cue "but disk space is so cheap nowadays"...) Sure I'll bite. There are cases where this matters, absolutely, it would also matter if the difference was between 10MB and 10GB, but we're talking about a pretty small relative difference. In return, you get the reliability of not having to worry about how your OS/configuration/other packages may interact with the software. In my opinion that's a huge productivity win, and also fits nicely with the fact that build systems should be thoroughly reproducible and do the same thing everywhere they run. There are some good, niche, reasons for not bundling things like a JVM: - If you're a strong free software advocate and need total control over the freedom in your dependencies. Debian do a lot of dependency unbundling for this reason. They're good at it, but it's not something most people care about or want to deal with the fallout of. - Memory usage optimisation by sharing libraries in memory. This has a nice benefit for native code, but unlikely to do a lot for Java processes from what I understand. This likely _could_ have a significant benefit for the Electron ecosystem given that many people now run 2-3 Electron apps at a time.
- jstimpfle 7y ago
  "Small relative difference" - Most programs, probably including Bazel, have <1MB worth of code. Some programs have additional media files, but not all of them. And even in 2019, small programs do make a difference in convenience. Sometimes when you download things, sometimes when you copy files around, sometimes when you search the files on your computer... A factor of 20, or 130, makes a huge difference if you consider all programs installed on your computer.
  - danpalmer 7y ago
    Currently Bazel has 48MB of source code in the `src` directory, plus another 125MB of integrations. Some of this will be tests, some will be build config, but that's probably in the ballpark of 100MB of source code. Adding somewhere between 20-100% for reliable running of that in ~all circumstances feels like a pretty solid engineering decision to me?
    - jstimpfle 7y ago
      I haven't looked at the project. In my experience, 100K lines of C source code roughly corresponds to 1MB of native code. That might not be representative, though. But maybe it's just that that the rest of this project has some more of these "20-100% expansion will be ok" decisions.
      - danpalmer 7y ago
        I just took these sizes from the master branch when I wrote the above comment. While that may have been true at one point, or is for C code, I suspect that is no longer the case in general. Between data files, resources, modern compilers optimising for speed over size, and more, I'd expect this to be significantly higher now.
dorfsmay 7y ago
In the era of static linking (golang, rust), sure, why not. These days getting dependencies and the right version of the runtime is considered a harder problem. I personally feel like the world is wasting a huge amount of memory because of this, but have to agree that distributing apps is hard.
- pjmlp 7y ago
  Oh the irony of seeing such comment. I still remember when dynamic linking was being introduced into OSes, Amiga libraries, Windows 3.x, the very first Linux kernel to support dynamic linking,....
  - dorfsmay 7y ago
    Can you explain why it's ironic?
    - pjmlp 7y ago
      Because the large majority of OS only allowed for static linking. When dynamic linking was finally possible, it was welcomed with pleasure, because not only it allowed to save disk and memory space, it also opened the door for extensibility via plugins, and dynamic behavior without restarts, instead slow IPC with one process per plugin/action. Now thanks to missteps of glibc design and .so hell on Linux (even worse than on Windows due to all distributions), many devs embrace static linking as some golden solution.
      - dorfsmay 7y ago
        Which was my point when I said I feel the world is wasting a huge amount of memory. It feels like a step backwards.

by ylyn 7y ago

sqldba 7y ago

Isn’t the whole point of dotnet that it ships with all the executables, libraries and binaries too? I don’t know how I feel about it myself.

chusk3 7y ago
You can choose to do a self-contained deployment, which bundles the runtime with your app, or a framework-dependent deployment, which requires a pre-existing shared install. Pick your poison.

danpalmer 7y ago

> (Cue "but disk space is so cheap nowadays"...) Sure I'll bite. There are cases where this matters, absolutely, it would also matter if the difference was between 10MB and 10GB, but we're talking about a pretty small relative difference. In return, you get the reliability of not having to worry about how your OS/configuration/other packages may interact with the software. In my opinion that's a huge productivity win, and also fits nicely with the fact that build systems should be thoroughly reproducible and do the same thing everywhere they run. There are some good, niche, reasons for not bundling things like a JVM: - If you're a strong free software advocate and need total control over the freedom in your dependencies. Debian do a lot of dependency unbundling for this reason. They're good at it, but it's not something most people care about or want to deal with the fallout of. - Memory usage optimisation by sharing libraries in memory. This has a nice benefit for native code, but unlikely to do a lot for Java processes from what I understand. This likely _could_ have a significant benefit for the Electron ecosystem given that many people now run 2-3 Electron apps at a time.

jstimpfle 7y ago
"Small relative difference" - Most programs, probably including Bazel, have <1MB worth of code. Some programs have additional media files, but not all of them. And even in 2019, small programs do make a difference in convenience. Sometimes when you download things, sometimes when you copy files around, sometimes when you search the files on your computer... A factor of 20, or 130, makes a huge difference if you consider all programs installed on your computer.
- danpalmer 7y ago
  Currently Bazel has 48MB of source code in the `src` directory, plus another 125MB of integrations. Some of this will be tests, some will be build config, but that's probably in the ballpark of 100MB of source code. Adding somewhere between 20-100% for reliable running of that in ~all circumstances feels like a pretty solid engineering decision to me?
  - jstimpfle 7y ago
    I haven't looked at the project. In my experience, 100K lines of C source code roughly corresponds to 1MB of native code. That might not be representative, though. But maybe it's just that that the rest of this project has some more of these "20-100% expansion will be ok" decisions.
    - danpalmer 7y ago
      I just took these sizes from the master branch when I wrote the above comment. While that may have been true at one point, or is for C code, I suspect that is no longer the case in general. Between data files, resources, modern compilers optimising for speed over size, and more, I'd expect this to be significantly higher now.

dorfsmay 7y ago

In the era of static linking (golang, rust), sure, why not. These days getting dependencies and the right version of the runtime is considered a harder problem. I personally feel like the world is wasting a huge amount of memory because of this, but have to agree that distributing apps is hard.

pjmlp 7y ago
Oh the irony of seeing such comment. I still remember when dynamic linking was being introduced into OSes, Amiga libraries, Windows 3.x, the very first Linux kernel to support dynamic linking,....
- dorfsmay 7y ago
  Can you explain why it's ironic?
  - pjmlp 7y ago
    Because the large majority of OS only allowed for static linking. When dynamic linking was finally possible, it was welcomed with pleasure, because not only it allowed to save disk and memory space, it also opened the door for extensibility via plugins, and dynamic behavior without restarts, instead slow IPC with one process per plugin/action. Now thanks to missteps of glibc design and .so hell on Linux (even worse than on Windows due to all distributions), many devs embrace static linking as some golden solution.
    - dorfsmay 7y ago
      Which was my point when I said I feel the world is wasting a huge amount of memory. It feels like a step backwards.