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

21–30 of 243 posts

Re: Bun 0.6

#21

Post by chrisco255 »

henry_viii wrote: post #16
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…

Doesn't Deno already let us do this?

Bun is intended to be a drop in replacement for Node.js, with Node.js compatible APIs. Deno chose to go a different route with the design of the runtime, encouraging more modern web-native paradigms.

Re: Bun 0.6

#22

Post by codethief »

Jarred wrote: post #15
kitd wrote: post #7

Earlier quoted context omitted.

Congrats on the release! How standalone are the standalone executables produced by `bun build`? Is a libc or equivalent expected to be present?

Bun does need glibc, but older glibc versions should work okay because of this: https://github.com/oven-sh/bun/blob/78229da76048e72aa4d92516... We haven't implemented polyfills for everything yet though, like Bun uses posix_spawn and doesn't have an exec + fork fallback Bun's dependencies otherwise are statically linked

> Bun does need glibc

Wait, are we talking about what Bun needs to run or what standalone executables produced by bun build need in order to run?

Re: Bun 0.6

#23

Post by ignoramous »

henry_viii wrote: post #16
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…

Doesn't Deno already let us do this?

Yes, that it does. Bun is mostly towing Deno with Zig + JSCore (and per some microbenchmarks, faster than both Node and Deno).

Re: Bun 0.6

#24

Post by winrid »

TechBro8615 wrote: post #12
silisili wrote: post #10

Earlier quoted context omitted.

It's why I dove into Go. This definitely took me from the 'eh, kinda cool project' to 'I cant wait to try this out immediately' camp. The binaries are pretty huge, hoping they can bring that down in time.

You've been able to do this with Deno for a long time (and Node too, as of recently). The downside is it bundles all of V8 so a "hello world" binary ends up being at least 70mb.

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

Re: Bun 0.6

#25

Post by intelVISA »

samwillis wrote: post #3
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

> I work on Bun Understatement.

Local hacker seasons v8 Bun with io_urings; woulda been a cool proj if the Js runtime was organic like Bellard's qjs

Still, in the native-starved web space this sorta meal will be considered haute cuisine.

Re: Bun 0.6

#26

Post by vlovich123 »

afavour wrote: post #14
silisili wrote: post #10

Earlier quoted context omitted.

It's why I dove into Go. This definitely took me from the 'eh, kinda cool project' to 'I cant wait to try this out immediately' camp. The binaries are pretty huge, hoping they can bring that down in time.

> The binaries are pretty huge, hoping they can bring that down in time. I'm surprised the numbers are as high as they are and hope they can reduce them... but they'll never get down to the kind of numbers Go and Rust get to because Bun depends on JavaScriptCore, which isn't small, and unless they're doing some truly insane optimizations they're not going to be able to reduce its size. FWIW QuickJS is a tiny JS runti…

For 90% of things this will be used for, it's more than enough so it might be a good default unless you enable a `-Ojit` flag when building more complex applications where the JIT will be a benefit. In fact, startup times might even be faster.

The challenge of course is supporting two JS runtimes within the same codebase.

Re: Bun 0.6

#27

Post by nine_k »

winrid wrote: post #24
TechBro8615 wrote: post #12

Earlier quoted context omitted.

You've been able to do this with Deno for a long time (and Node too, as of recently). The downside is it bundles all of V8 so a "hello world" binary ends up being at least 70mb.

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

Docker containers are actually smaller if they share layers with other containers in the system. A ton of containers based on the same image reaps many deduplication benefits.

Re: Bun 0.6

#28

Post by brundolf »

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…

Fwiw, Deno can do this too: https://deno.com/manual@v1.33.3/tools/compiler

Re: Bun 0.6

#29

Post by meekaaku »

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

Just wanted to say thank you for starting and leading the one of the most exciting projects in js landscape.
Post reply on HN