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

41–50 of 243 posts

Re: Bun 0.6

#41

Post by afavour »

vlovich123 wrote: post #26
afavour wrote: post #14

Earlier quoted context omitted.

> 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.

Yeah I suspect the weird little differences between runtimes (e.g. what language features they do and do not support) would lead you down a path of a thousand cuts.

It still feels like a graceful idea, though.

Re: Bun 0.6

#42

Post by petetnt »

brundolf wrote: post #28
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

And NodeJS too https://nodejs.org/api/single-executable-applications.html

Re: Bun 0.6

#43

Post by whimsicalism »

alberth wrote: post #38
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

Revenue/monetization model? Given that Oven has taken $7m in VC funding, how do you plan to monetize Bun, etc?

my understanding was an edge environment similar to CF workers

Re: Bun 0.6

#44

Post by afavour »

whimsicalism wrote: post #40
afavour wrote: post #14

Earlier quoted context omitted.

> 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…

JSC is ridiculously fast, this is what makes bun great

It really depends on what you're doing. If 95% of your code is file or network I/O then it's really not going to make the slightest difference whether you're running JSC, V8 or QuickJS. If your code is enormously complex and benefits from JIT then yes, you're going to really feel that downgrade.

Re: Bun 0.6

#45

Post by tankenmate »

ponyous wrote: post #39
tankenmate wrote: post #37

I am truly perplexed as someone outside of the Javascript ecosystem; why are there so many incompatible bundlers? If you look at most compiled languages they have a set ABI / executable image format, and you just use a link editor (either compile time, run time, or both). Is it just because most Javascript developers have never learnt from any of the lessons that came from decades of compiled languages? (compilers, c…

Because there were browsers and no standards. How can you expect someone that starts coding on the web to know what pains kernel went through decades prior?

But surely the people writing the browser code thought about the ecosystem they were creating / trying to create?

Re: Bun 0.6

#47

Post by RedShift1 »

petetnt wrote: post #42
brundolf wrote: post #28

Earlier quoted context omitted.

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

And NodeJS too https://nodejs.org/api/single-executable-applications.html

Experimental, so probably at least 5 years before it's considered "stable"

Re: Bun 0.6

#48

Post by winrid »

MuffinFlavored wrote: post #11
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…

> 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.

Re: Bun 0.6

#49

Post by winrid »

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.

It becomes a political issue at this point w/ battling the ops team. I have more important battles.
Post reply on HN