5 ms·

One little deno feature I didn't realize until digging in to play with it more was that it can 'compile' code and the V8 runtime into a single standalone execut

One little deno feature I didn't realize until digging in to play with it more was that it can 'compile' code and the V8 runtime into a single standalone executable. IMHO this is really nifty and feels very go-like in building tools with zero other dependencies. Obviously the V8 runtime adds a lot of size (seems like a hello world is 90MB or so in quick testing) but I like the potential for building tools that are easy to give to others to install and use. It seems great for internal use where you have analysts and such using a mish-mash of scripts and one-offs with lots of dependencies and little documentation or time to help people setup and use them. Just hook up your CI to spit out new executables and be done with walking people through how to troubleshoot their broken homebrew node, python, etc. environments.

rektide 5y ago
Personally I weap for the death of shared libraries. It's great developer convenience to statically bundle everything, and ever so manageable... But it makes me so sad thinking not just of the storage footprint of dozens of copies of the library floating around (be it v8 for deno, or chrome for electron), but the memory cost too of having that near-to duplicate library loaded multiple times too. And then there's the maintenance cost to the user, of needing to update each package independently to get updates. With something like the web, I as a user would far prefer having bleeding edge shared libraries/v8's/browsers underfoot, and carry the expectation that each app can load & run atop this most recent version. The trends have been very much in the other way. One of the main Go champions tout is it's static compilation, I think rust too. What are containers but entire static system images, as opposed to just having some static libraries? Part of me is willing to acknowledge that the larger footprints aren't that impactful, aren't really a problem, but it contravenes the deliberate & elegant simplicity that something like an OS distribution used to represent: I look at Debian as thousands of different pieces, all wonderfully integrated & interlinked, a cohesive system, that one ought to be able to bring additional projects onto to compile & extend. But our appetite for such has waned. The convenience for you & your users of just bundling everything you personally need to ship your stuff is quite high, at least when you're not updating dozens of oversized apps or running janky old versions because of this easy-to-get-started convenience.
- admax88q 5y ago
  Honestly the memory cost isn't that much. Code size has not grown as fast as memory and storage capacity has. One is constrained by manufacturing progress, the other is constrained by programmer output. Deno is sub 50MB For any non trivial app, your assets and working set data will likely dwarf the code size itself. EDIT: Was looking at an old bug, deno is closer to 100MB. Starting to feel a bit large but still.
- judge2020 5y ago
  The problem seems to stem from library developers making should-be-stable APIs and later fixing/updating them in a way that shouldn’t break compatibility but does, all without a major version change. While this doesn’t happen to the majority of libraries out there, every developer has encountered this issue at least once, and the easy way to fix this is to statically link all dependencies, thus enabling Uber-compatibility as future dependency updates won’t be automatically introduced in your program. When these dependencies are updated, the app developer can perform a full suite of validation that guarantees the update doesn’t break anything. The only way to fix this is with either an extremely stable API (eg. libc) or a mostly-stable api that developers know they have to validate often, and that’s going to be the web with Chrome/Firefox PWAs.
- qbasic_forever 5y ago
  If it's an internal tool used by 10's of people I really don't care one bit about memory use, the elegance of shared dependencies, etc. The kind of optimizations debian is going for are great at scale but it's the kind of last 10% of work that will take 90% of your time. This is optimizing squarely for fastest agility with lowest developer and maintenance time.
- ImprobableTruth 5y ago
  >contravenes the deliberate & elegant simplicity that something like an OS distribution used to represent That simplicity is also the root cause of an incredible amount of issues. Want to install a program that needs a different library version than is already installed? Well, too bad, guess you'll have to manually patch it (assuming the source code is even available). And there's countless such stories, 'dependency hell' is still an issue to this very day for dynamically linked libraries. Docker and the like didn't come into existence for no reason but because the experience of simple package managers is just not adequate. Now, dynamic libraries on their own aren't at fault of course. If more complex package managers like Nix were common this wouldn't be an issue, but simplicity 'won', so static linking it is.
ksbrooksjr 5y ago
There used to be a '--lite' option that produced smaller binaries, but it looks like they removed it recently [0]. There's also a CLI called pkg that lets you achieve something similar with Node. It actually compiles the source code into V8 bytecode and bundles that with the Node binary [1]. [0] https://github.com/denoland/deno/issues/10507 https://github.com/denoland/deno/issues/10507 [1] https://github.com/vercel/pkg https://github.com/vercel/pkg
hashbig 5y ago
You can do this with Node.js as well using: https://github.com/vercel/pkg https://github.com/vercel/pkg
- itisit 5y ago
  Also with nexe: https://github.com/nexe/nexe https://github.com/nexe/nexe

rektide 5y ago

Personally I weap for the death of shared libraries. It's great developer convenience to statically bundle everything, and ever so manageable... But it makes me so sad thinking not just of the storage footprint of dozens of copies of the library floating around (be it v8 for deno, or chrome for electron), but the memory cost too of having that near-to duplicate library loaded multiple times too. And then there's the maintenance cost to the user, of needing to update each package independently to get updates. With something like the web, I as a user would far prefer having bleeding edge shared libraries/v8's/browsers underfoot, and carry the expectation that each app can load & run atop this most recent version. The trends have been very much in the other way. One of the main Go champions tout is it's static compilation, I think rust too. What are containers but entire static system images, as opposed to just having some static libraries? Part of me is willing to acknowledge that the larger footprints aren't that impactful, aren't really a problem, but it contravenes the deliberate & elegant simplicity that something like an OS distribution used to represent: I look at Debian as thousands of different pieces, all wonderfully integrated & interlinked, a cohesive system, that one ought to be able to bring additional projects onto to compile & extend. But our appetite for such has waned. The convenience for you & your users of just bundling everything you personally need to ship your stuff is quite high, at least when you're not updating dozens of oversized apps or running janky old versions because of this easy-to-get-started convenience.

admax88q 5y ago
Honestly the memory cost isn't that much. Code size has not grown as fast as memory and storage capacity has. One is constrained by manufacturing progress, the other is constrained by programmer output. Deno is sub 50MB For any non trivial app, your assets and working set data will likely dwarf the code size itself. EDIT: Was looking at an old bug, deno is closer to 100MB. Starting to feel a bit large but still.
judge2020 5y ago
The problem seems to stem from library developers making should-be-stable APIs and later fixing/updating them in a way that shouldn’t break compatibility but does, all without a major version change. While this doesn’t happen to the majority of libraries out there, every developer has encountered this issue at least once, and the easy way to fix this is to statically link all dependencies, thus enabling Uber-compatibility as future dependency updates won’t be automatically introduced in your program. When these dependencies are updated, the app developer can perform a full suite of validation that guarantees the update doesn’t break anything. The only way to fix this is with either an extremely stable API (eg. libc) or a mostly-stable api that developers know they have to validate often, and that’s going to be the web with Chrome/Firefox PWAs.
qbasic_forever 5y ago
If it's an internal tool used by 10's of people I really don't care one bit about memory use, the elegance of shared dependencies, etc. The kind of optimizations debian is going for are great at scale but it's the kind of last 10% of work that will take 90% of your time. This is optimizing squarely for fastest agility with lowest developer and maintenance time.
ImprobableTruth 5y ago
>contravenes the deliberate & elegant simplicity that something like an OS distribution used to represent That simplicity is also the root cause of an incredible amount of issues. Want to install a program that needs a different library version than is already installed? Well, too bad, guess you'll have to manually patch it (assuming the source code is even available). And there's countless such stories, 'dependency hell' is still an issue to this very day for dynamically linked libraries. Docker and the like didn't come into existence for no reason but because the experience of simple package managers is just not adequate. Now, dynamic libraries on their own aren't at fault of course. If more complex package managers like Nix were common this wouldn't be an issue, but simplicity 'won', so static linking it is.

ksbrooksjr 5y ago

There used to be a '--lite' option that produced smaller binaries, but it looks like they removed it recently [0]. There's also a CLI called pkg that lets you achieve something similar with Node. It actually compiles the source code into V8 bytecode and bundles that with the Node binary [1]. [0] https://github.com/denoland/deno/issues/10507 https://github.com/denoland/deno/issues/10507 [1] https://github.com/vercel/pkg https://github.com/vercel/pkg

hashbig 5y ago

You can do this with Node.js as well using: https://github.com/vercel/pkg https://github.com/vercel/pkg

itisit 5y ago
Also with nexe: https://github.com/nexe/nexe https://github.com/nexe/nexe