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

201–210 of 243 posts

Re: Bun 0.6

#201

Post by spacechild1 »

ricardobeat wrote: post #152
Buttons840 wrote: post #146

Earlier quoted context omitted.

Bun might be a cool project, but them building on an immature language like Zig makes me wonder where their priorities are.

It wouldn't exist any other way, the story is that it was built with speed as a priority, and Zig was chosen for the performance optimizations it enables.

> with speed as a priultimat

They could have just used C++ or Rust. Not saying that they shouldn't use Zig, just questioning speed as the (primary) motivation

Re: Bun 0.6

#202

Post by iExploder »

ojosilva wrote: post #199
Buttons840 wrote: post #167

Earlier quoted context omitted.

There are several other languages that could achieve the same speed and performance optimizations. To be clear, I hope to see Zig succeed and I'd like to learn it one day. It reminds me of the video game engine question, only in this case it would be: do you want to build a product, or do you want to build something with Zig? I imagine the creators of Bun answered "we want to use Zig" as their first priority, and tha…

At one point, the Rust team switched away from the performant Jemalloc allocator to something more widely compatible (the system default). They chose to sacrifice performance in the sake of compatibility/stability. It's still available, but optional. https://internals.rust-lang.org/t/jemalloc-was-just-removed-... Insane performance gains, like the ones we see early in Zig, is something that can be easily eaten away b…

my impression is Zig wants to replace C and has the same philosophy of a very simple language that does not evolve once it stabilizes. that means to me they want to stabilize the language with small amount of features and make it as performant as possible at that point. from their webpage:

A Simple Language

Focus on debugging your application rather than debugging your programming language knowledge.

Re: Bun 0.6

#203

Post by mike_hearn »

U1F984 wrote: post #121
paulddraper wrote: post #102

Earlier quoted context omitted.

IIRC the latest Linux Node.js binary is over 70MB. Though Bun doesn't use Node.js I believe, there's a reference (At least it's not JVM Hotspot...)

A Java Runtime for Hello world is just 32 MB: https://adoptium.net/blog/2021/10/jlink-to-produce-own-runti...

You can actually get it smaller if you compile your own JDK and look at the compressed size. I got it down to 7mb at one point.

Re: Bun 0.6

#204

Post by sgammon »

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

https://elide.dev

Re: Bun 0.6

#205

Post by bruce_one »

lionkor wrote: post #189
AndyKelley wrote: post #118

Earlier quoted context omitted.

why?

Because otherwise you need to implement almost everything yourself - memory allocation, input, output, etc. and anything more complex (like asking for the width of the terminal) requires you to get into Kernel structs, copy them out, translate, and basically copy paste glibc code anyways. And thats just linux.

There are alternative C libraries that are worth considering, e.g. Zig (which is what Bun itself is written in, afaiu) supports using [musl](https://musl.libc.org) as an alternative to glibc, and musl can be statically linked as well (by contrast to the glibc quasi-static-linking).

Re: Bun 0.6

#206

Post by ptx »

pseudosavant wrote: post #117
pier25 wrote: post #81

Earlier quoted context omitted.

Apparently a hello world is like 90MB. https://twitter.com/jarredsumner/status/1657765876085690368

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.

Python's embeddable package for Windows [1] is 16 MB unpacked.

The OpenJDK runtime with the java.base and java.desktop modules is 64 MB. Replacing Swing with SWT (leaving out the java.desktop module) gets it below 50 MB. The full OpenJDK runtime with all modules is around 128 MB. (With Java 17 on Windows.)

[1] https://docs.python.org/3/using/windows.html#windows-embedda...

Re: Bun 0.6

#207

Post by 19h »

Funny to see improvements in crypto.createHash… I was totally caught off guard yesterday noticing most of crypto has been removed in Node 20 and replaced with the exclusively-async „subtle“ WebCrypto. Quite a pain to work with when you need synchronous code.

Re: Bun 0.6

#208

Post by icemelt8 »

Jarred wrote: post #116
alberth wrote: post #38

Earlier quoted context omitted.

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

The plan is JavaScript edge hosting focused on fast cold starts and being extremely inexpensive, using lots of custom infrastructure

This reply is news itself. Nice!

Re: Bun 0.6

#209

Post by codethief »

hiccuphippo wrote: post #88
codethief wrote: post #22

Earlier quoted context omitted.

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

Both, the executables produced by bun are the bun binary concatenated to your script at the end. Try building a hello world and run `tail -c200 hello | xxd` to see your script at the end of the file.

Thanks!

Re: Bun 0.6

#210

Post by geysersam »

wiz21c wrote: post #188
keyle wrote: post #122

Earlier quoted context omitted.

yeah 90MB for a hello world is big. Approximately 2,700 times bigger than it could be.

I got 4Gigs on my phone and 4x that on my laptop. I don't care about 90megs. What's the point in looking at size ? I can see two: - want to email the exe, and you have limits on mail size - want to be ecofriendly, in that case stop watching netflix for 2 hours and you'll have your megs

I see it differently, what if I want to have more than 40 apps on my phone?

Although, to be fair it seems likely the executable size will shrink with time.

Post reply on HN