7 ms·

This is impressive, although the cynic that I am can't help pointing out that we must have gone wrong somewhere when a "hello world" HTTP server application "on

• Samtaran 8y ago
  Check out this article in which the author was able to run an app written in java with 4MB RAM only using GraalVM: https://sites.google.com/a/athaydes.com/renato-athaydes/posts/a7mbnative-imagejavaappthatrunsin30msandusesonly4mbofram https://sites.google.com/a/athaydes.com/renato-athaydes/post... That clearly shows whats possible.
• pavlov 8y ago
  Every application comes with an entire operating system's worth of code nowadays. Download a desktop chat client or a little menu bar utility — each app includes its own copy of Electron at 150MB. Make a "Hello world" web client app using React with the recommended "create-react-app" toolchain — your project will first download nearly 200MB of code via npm (and each project you start will have its own copy of this stuff). Make a web server with a framework like Rails, Vert.x or whatever — be prepared to spend hours downloading dependencies and setting up your local environment just so. I don't have any good ideas for how to break this cycle. By 2028, I expect every to-do app will include its own 4GB copy of Ubuntu because it's convenient.
  • koolba 8y ago
    > I don't have any good ideas for how to break this cycle. By 2028, I expect every to-do app will include its own 4GB copy of Ubuntu because it's convenient. 2028? More like 2015. It’s already like that for much of what runs in Docker containers.
    • gnur 8y ago
      Kind of, except that the base ubuntu image is more like 70MB.
      • pavlov 8y ago
        I was thinking of the Ubuntu desktop. Each desktop utility could be its own virtual machine, and it wouldn't be so far removed from what already happens with Electron.
        • homarp 8y ago
          see https://www.qubes-os.org/ https://www.qubes-os.org/ and https://www.qubes-os.org/news/2018/01/22/qubes-air/ https://www.qubes-os.org/news/2018/01/22/qubes-air/
      • IanCal 8y ago
        And if things are using the same base, you don't have multiple copies but only one copy of the base image.
    • jrs95 8y ago
      Is it? Most people I’ve seen working with Docker have tried their best to use Alpine for everything. Even something with a lot of OS dependencies tends to end up at around 200MB on the high end.
      • spacemanmatt 8y ago
        my nginx image is around 16M until I add python (certbot)
  • bradleyjg 8y ago
    Every cell in your body includes gigabytes worth of source code for the entire organism. Maybe this kind of redundancy isn’t such a bad idea? The industry has tried shared library schemes many many times and it always turns out to be a mess.
    • pavlov 8y ago
      There's over 10^13 cells in the human body. If my computer had enough memory to fit 10 trillion copies of Electron, I wouldn't be complaining.
      • krylon 8y ago
        > If my computer had enough memory to fit 10 trillion copies of Electron, I wouldn't be complaining. You would, once you saw the power bill. ;-) SCNR
    • kbenson 8y ago
      I think there was a shift lost in the metaphor. Most people don't care if they have hundreds of copies of distros scattered around their humongous disks, but they might care if all those distros are running and actively using RAM and CPU cycles. In the same vein, I'm pretty sure that while all those cells contain a copy of DNA, they don't all execute the whole copy all the time.
      • theyinwhy 8y ago
        Deduping in ram anyone? https://theithollow.com/2012/12/17/memory-de-duplication-in-vmware/ https://theithollow.com/2012/12/17/memory-de-duplication-in-...
  • throwaway2048 8y ago
    you wish, more like each subcomponent of ubuntu will contain its own full operating system enviroment itself aswell.
  • specialist 8y ago
    I was an early critic (technorati objector) of the app server movement. Then I needed to have a UI to monitor & manage a bunch of independent loosely coupled processes. Think poor man's workflow engine. Imagine my chagrin when I knowingly, faithfully recreated the Windows Task Manager for my stack. I was very late to the Unix world. But I really think the Unix way is something akin to a golden law of the universe. Which each new cohort needs to rediscover for itself.
  • BenoitP 8y ago
    > and each project you start will have its own copy of this stuff I don't get why npm can't setup a content addressed shared repository, something à la m2/maven. This seems like such a waste of space. I'm not up to speed with filesystems, but IMHO content-addressing by default should be a standard feature as well.
  • acemarke 8y ago
    The set of dependencies that comes with CRA (and other similar tools) includes: - A compiler - A bundler/linker - An optimizing minifier - A linter - A development server with live reloading - A test runner All of those are isolated and scoped to that one project, and they are all build-time dependencies only. The build output you actually deploy is just static JS/HTML/CSS files, and developers are encouraged to keep those at a few hundred KB tops. It's also important to understand that Javascript packages are effectively distributed as source, which affects the number of files on disk. (Granted, many NPM packages do include unnecessary files in the published artifacts, but Javascript itself is a major factor there.) Meanwhile, XCode is supposedly something like 8GB installed, Visual Studio is multiple gigs, and if you were to look at the actual file size on disk of any C++ compiler toolchain, that would be a minimum of several dozen megs - those are just usually preinstalled on Linux or Mac systems. So, context is pretty important here. A couple hundred MB for a complete JS build toolchain is perfectly fine :)
  • fest 8y ago
    I've seen embedded device which runs on yocto/poky flavour of Linux, and the main app chroots into Ubuntu 14.04 for no apparent reason.
• jug 8y ago
  Yes, but GraalVM is still a VM with all that implies. An emulation of a computer system to execute code in a platform independent environment, where another security-wise benefit is the walled garden nature. I think that all this done in 40 MB is pretty fascinating!! It depends on how you look at it? If you want the lowered resources, go ahead and code in C or why not Free Pascal, with an underestimated pretty mature and stable API on a multitude of platform targets. There are plenty of active projects with rich libraries. But there are also several disadvantages from not running on a VM. I think that these days, what you look for sometimes makes sense but in my opinion mostly just if you are into operating systems, embedded systems, hardware drivers, and so on. I don't think the added effort is worth it otherwise except for maybe personal pet projects. :)
  • tom_mellior 8y ago
    > Yes, but GraalVM is still a VM with all that implies. What does it imply? For one thing, the term "VM" itself is vague. GraalVM isn't an "emulation of a computer system" in the way a "VM" like VirtualBox is.
    • tootie 8y ago
      It sorta is. It was like a single Docker image called "Java" that gave you a complete runtime environment with all the OS internals available through a standard API so long as you wrote everything in one language.
      • tom_mellior 8y ago
        An API is not an emulation of a thing X. It's a way for you to access the actual X. Besides, as a sibling comment pointed out, even that loses all significance with native image compilation that throws out all the API methods that are not used, and inlines away the ones that are used.
  • viraptor 8y ago
    > GraalVM is still a VM with all that implies. An emulation of a computer system to execute code in a platform independent environment, Not with graalvm native image compilation. It does ahead of time compile and eliminates the bytecode as far as I understand. It still uses managed memory and other abstractions, but it's quite far from a typical java VM. (And definitely away from a system vm)
• pron 8y ago
  This is actually very, very sane. I've been a professional developer for 25 years, and in the old days we used to -- or, rather, had to -- make use of a lot of crazy hacks to get what we wanted, in terms of performance and RAM footprint, from slow, RAM-limited machines. This resulted both in brittle code (which wasn't so bad because the programs had to be small) and in increased development time. These days, you can increase the performance of your code by writing well-optimized code, using a better compiler (but there's a limit to that), getting more CPUs (but there's a limit to that, too, due terms of hardware support, programming style and Amdahl's law) and getting more RAM. By far the most expensive option is writing hand-optimized code, and the cheapest, least limited resource (except for special cases of constrained environments) is RAM. Every MB of RAM spent on making your code faster while still keeping development costs low is a MB well-spent. Of course, nothing here should be taken to the extreme.
  • specialist 8y ago
    I'm really struggling with this. Most of my professional career, I've optimized my time. My novel strategy has always been "do less work" (aka a month of coding can save a week of design). 80% of a project is maintenance, right? Mitigating that means clear code, good docs, safety net of tests, etc. Is that 80% still true? I've heard, but cannot yet validate, that code now only lives 3 years. I just can't believe how much code we're all creating. Over the weekend, I rewrote some incomprehensible goo which took months to create. A module all our services use. A real pain point. My rewrite is 1/6th the size. Was the rewrite worth it? I honestly can't say.
    • BenoitP 8y ago
      > I've heard, but cannot yet validate, that code now only lives 3 years. That would be the rate at which the Hello World's and the front-end pieces get replaced. Back-end or entreprise code is very different in my experience. Most enterprise internal apps actually live for much much longer that that. These are seen as cost centers and never get the necessary cash to be properly refactored. They are usually riddled with copious amounts of lava flow anti-patterns [1]; and outlive several times over the users, the developers, the management, and the founders/CEOs. If the hardware dies, they get put as-is on a VM that emulates the old hardware. Development is incremental and grinds slowly down, tending to the asymptotic ratio of changing business needs w.r.t. the amount of archeology required. [1] https://en.wikipedia.org/wiki/Lava_flow_(programming) https://en.wikipedia.org/wiki/Lava_flow_(programming)
• shellac 8y ago
  On my machine it's an order of magnitude larger than `true`. /usr/bin/time -f "\nmaxRSS\t%MkB" true maxRSS 1276kB I'm not sure what to make of that.
• dullgiulio 8y ago
  Not a lot of pruning. Incidentally, writing the same thing in Go (for example) yields more or less the same binary size. You should see how quickly the binary size grows as you add more of your code (answer: not much) and what the alternative is: a txt file containing "hello world" and a statically built nginx server.
  • eikenberry 8y ago
    They list the binary size as 27MB where a similar Go binary is just under 5MB. So I'm not sure where you got your numbers, but they're wrong. Also you were responding to a comment about the runtime resident memory (RSS) of the app being 40MB, not about the file size.
• dagenix 8y ago
  It's not overhead unless you are intent on only making a hello world app and stopping there. Assuming you are going to make something more involved, you are going to use those extra features. Optimizing the size of the executable for the hello world case (outside of a fun weekend project) is insane - optimization should be done for the types of apps that are doing real work. I'm not sure why I'm saying any of this since you seem to be aware of it - your second paragraph says the same thing and completely contradicts your first paragraph.
• jpalomaki 8y ago
  What is the most scarce resource for average developer. Is it CPU? Is it memory? Is it network bandwidth? Or is it his own time? I guess for most developers it is reasonable to trade-off to blow few megabytes here and some kilobits there in order to save even few hours of precious calendar time. When everybody contributing to the dependency graph does that, it adds up.