Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bun 0.6

bun.sh

Post reply on HN
Print view View original

171–180 of 243 posts

Re: Bun 0.6

#171

Post by synergy20 »

hu3 wrote: post #6

> Standalone executables. You can now create standalone executables with bun build. > bun build --compile ./foo.ts > This lets you distribute your app as a single executable file, without requiring users to install Bun. > ./foo This is big! Part of Go's popularity is due to how easy it is to produce self-contained executables. And it seems to support amd64 and arm according too: https://twitter.com/jarredsumner/statu…

golang is the most famous all-in-one-binary language with reasonable size.

zig is by default static linked, it probably has the smallest binary size, smaller than static C.

Re: Bun 0.6

#172

Post by squeaky-clean »

Waterluvian wrote: post #158
carbotaniuman wrote: post #149

Earlier quoted context omitted.

I think it isn't, and there saying it's impressive how small the JVM overhead is.

Is the JVM inside that 8MB then I guess? That is pretty great. Originally I thought the alternative was “8MB but supply your own virtual machine.”

There's no JVM when using GraalVM Native Images, it relies on a JVM during the compile step (well, specifically GraalVM), but produces native code similar to compiling C. There's no virtual machine running bytecode, just entirely native code. So the size of the executable will depend on how many features of the JVM you need compiled into your executable.

A pure java bytecode (bring-your-own-JVM) Hello World can be under 2KB pretty easily. Smaller than the equivalent C program. But of course, that's not including the size of your system JVM.

Re: Bun 0.6

#173

Post by moron4hire »

tracker1 wrote: post #104
moron4hire wrote: post #53

Earlier quoted context omitted.

Browsers weren't written in a day. Technically speaking, Mozilla Firefox is a ship of Theseus going back to the release of Netscape in 1994. Did browser and internet infrastructure developers in the early 90s understand that these things would become rich application platforms? Looking at the history of HTTP, it's clear that they expected some concept of "application" to be delivered through the browser. While there'…

There were a lot of JS heavy web applications prior to Google Maps. From around the release of IE5 at the end of 2000 in particular through the long tenure of IE6. Having worked on some JS heavy applications around that time. It was also much harder as you had a relatively wide variety of browsers and versions. Since people on dialup were far less likely to update their browsers regularly (or at all beyond what came…

Yeah, I worked on some of them, too. They were even in mapping. I had written one of the first, dynamic, 2D drawing libraries for JavaScript, long before Canvas2D, but it was hidden in proprietary consultoware.

The significance of Google Maps was that A) it had all the parts that we would recognize today as a JS single-page app, B) it had no alternative interface that people could opt to use instead (diluting the usage of that particular implementation versus the product as a whole), C) it had broad appeal and adoption, and D) it was significantly better than competitors specifically because of the "SPA-ness" of the app.

Google Maps had the features and penetration necessary to change the public perception at large of what could be done with browser-based apps.

Re: Bun 0.6

#174

Post by billywhizz »

billywhizz wrote: post #157
ricardobeat wrote: post #108

Earlier quoted context omitted.

The engine is not the largest part of it. just-js, which is pretty close to barebones V8, sits at ~20MB. JSC is supposed to be about 4MB, Hermes is 2-3MB. The largest parts I think are ICU and the built-in libraries.

yes. author of just-js here. a minimal build of a v8 based runtime weighs in around 23-25 MB on modern linux using latest v8. this gets bigger all the time, due to new functionality being added to JS/V8 and no easy way to decide what parts of JS to include. when i started working on just-js ~3.5 years ago i'm pretty sure it was only 15MB or so - can verify when i have time.

i just tried recompiling v0.0.2 (https://github.com/just-js/just/releases/tag/0.0.2) of just-js and comparing it to current. for the completely static build on ubuntu 22.04 i see following:

0.0.2 (v8 v8.4.371.18) - file size: 15.2 MB, startup RSS: 8.4 MB current (v8 v10.6.194.9) - file size: 19.5 MB, startup RSS: 12.3 MB

so, that's roughly 30% binary size increase and 50% greater startup memory usage in 2.5 years. =/

Re: Bun 0.6

#175

Post by jrockway »

thewataccount wrote: post #36
winrid wrote: post #24

Earlier quoted context omitted.

I've been desensitized by my world of 500mb docker containers.

Have you tried using alpine based images instead of debian/ubuntu/others? I know it's not always possible especially because of musl but for most things it works fine and is tiny.

Why even include Alpine? Distroless is the way to go.

Re: Bun 0.6

#176

Post by toastal »

Jarred wrote: post #2

I work on Bun. Happy to answer any questions also: there is a bug in `bun build --compile` I am currently working on fixing. Expect a v0.6.1 in a bit

When will Bun open up communications to something open source/decentralized instead of relying on users to give up their online security to Discord?

Re: Bun 0.6

#177

Post by jrockway »

mirashii wrote: post #97
winrid wrote: post #48

Earlier quoted context omitted.

Nah, rust still depends on libc at runtime which is a pain. Go doesn't have this problem afaik as it has its own stdlib and runtime.

> Nah, rust still depends on libc at runtime which is a pain. It does in general, though I don't really think this is a big pain or blocker in the general case, there are very version requirements around libc. > Go doesn't have this problem afaik as it has its own stdlib and runtime. That's also true, but it's not really a pure win. Choosing not to use a battletested libc has led to a variety of subtle and difficult…

I think it's a pure win. Writing your program in 1 language instead of 2 is worth one simple misunderstanding of vDSO.

Re: Bun 0.6

#178

Post by leeoniya »

winrid wrote: post #48
MuffinFlavored wrote: post #11

Earlier quoted context omitted.

> Part of Go's popularity is due to how easy it is to produce self-contained executables. Rust too... :D

Nah, rust still depends on libc at runtime which is a pain. Go doesn't have this problem afaik as it has its own stdlib and runtime.

https://github.com/redox-os/relibc ?

https://musl.libc.org/

Re: Bun 0.6

#179

Post by thristian »

Kamq wrote: post #160
Conscat wrote: post #73

Earlier quoted context omitted.

Statically linking libC is problematic in various ways. I really appreciate that Zig has its own runtime that is designed specifically for this use case.

> Statically linking libC is problematic in various ways. Are we just talking about standard rop gadget vulnerabilities, or is there something else that's a problem with it?

glibc, Linux's traditional libc, can dynamically load hostname resolution policies, but that only works if the executable has access to dynamic loading, i.e. if it's not a static executable.

Dynamically loading hostname resolution policies doesn't happen often, but when it does happen it's a right pain to diagnose why some tools see the right hostname and other tools don't.

Re: Bun 0.6

#180

Post by Spivak »

microflash wrote: post #138
pseudosavant wrote: post #117

Earlier quoted context omitted.

Is 90MB really that big when compared against the other types of binaries that would get deployed: containers and VM images? How big is the platform (k8s, docker, etc) you need installed to run your app? Probably more than 90MB.

A native Java "Hello World" can be around 8MB in size.[1] So, yes, 90MB is too much. 1. https://sergiomartinrubio.com/articles/getting-started-with-...

I feel like using Graal for the comparison is cheating a bit because it's so fundamentally different from what bun is doing. You need to compare it to tools that ship class files and a JVM, or something like PyInstaller which will have much much more overhead.
Post reply on HN