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

71–80 of 243 posts

Re: Bun 0.6

#71

Post by arp242 »

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.

You can statically link libc in Rust too; at least, if teh interwebz is correct (not a Rust expert); you just need some extra flags.

This is actually not that different from Go in practice; many Go binaries are linked to libc: it happens as soon as you or a dependency imports the very commonly used "net" package unless you specifically set CGO_ENABLED=0, -tags=netgo, or use -extldflags=-static.

Re: Bun 0.6

#72

Post by beanjuiceII »

winrid wrote: post #49
thewataccount wrote: post #36

Earlier quoted context omitted.

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.

how about ubuntu chisel

Re: Bun 0.6

#73

Post by Conscat »

arp242 wrote: post #71
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.

You can statically link libc in Rust too; at least, if teh interwebz is correct (not a Rust expert); you just need some extra flags. This is actually not that different from Go in practice; many Go binaries are linked to libc: it happens as soon as you or a dependency imports the very commonly used "net" package unless you specifically set CGO_ENABLED=0, -tags=netgo, or use -extldflags=-static.

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.

Re: Bun 0.6

#74

Post by claytongulick »

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.

Yeah, this is honestly one of the things that turns me off of containers in general.

Like, the whole point was to effectively use linux kernel namespaces with cgroups in an intelligent way to give VM-like isolation, but non-emulated performance - and supposedly not having to deal with image size bloat from the OS like you get in VMs.

What we got was an unholy mashup of difficult to debug, bloated images and ridiculously complex deployment and maintenance mechanisms like kubernetes.

I just do old school /home/app_name deployments with systemd unit files, and user-level permissions.

Oh, and it's webscale[1].

[1] https://www.youtube.com/watch?v=b2F-DItXtZs

Re: Bun 0.6

#75

Post by diego_sandoval »

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

What bothers me is that even when that capability exists, most of the Rust open source programs that I've tried don't distribute binaries, and still ask you to install cargo and compile the program from source.

Re: Bun 0.6

#76

Post by f311a »

conradev wrote: post #17
Signez wrote: post #4

Earlier quoted context omitted.

Really impressed to see that bun is now faster than esbuild, that was in my mind one of the fastest bundler/minifier in town. How did you achieve that? Are there some shortcuts you took, or some feature you deemed not in scope (yet)?

This is a fantastic talk on some of the optimizations that Zig makes easy to implement: https://vimeo.com/649009599 Bun is written in Zig, but it takes the same approach that esbuild took to make things fast: a linear, synchronous pipeline fitting as much as possible in the CPU cache with as little allocation and other overhead as possible. Zig has more knobs to turn than Go. Bun goes one step further and does a grea…

Zig is cool, but Bun heavily relies on JSC which is written in C++

Re: Bun 0.6

#77

Post by [deleted] »

diego_sandoval wrote: post #75
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

What bothers me is that even when that capability exists, most of the Rust open source programs that I've tried don't distribute binaries, and still ask you to install cargo and compile the program from source.

[deleted]

Re: Bun 0.6

#78

Post by VWWHFSfQ »

diego_sandoval wrote: post #75
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

What bothers me is that even when that capability exists, most of the Rust open source programs that I've tried don't distribute binaries, and still ask you to install cargo and compile the program from source.

My experience is the opposite. Nearly every Rust tool I've used offers static binaries for various platforms.

Re: Bun 0.6

#79

Post by verdverm »

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.

If everyone is on the same base image, then you aren't really dealing with 500mb images, but much smaller layers on top.

Re: Bun 0.6

#80

Post by 10000truths »

dheera wrote: post #60

Why are we still minifying JavaScript? Is it only for obfuscation? State-of-the-art HTTP servers already do a pretty damn good job gzipping stuff on the fly, do we need this garbage? If it is for obfuscation, fine, can we just call it that?

You can shrink transmitted sizes even further by using minification on top of transport compression. That nets me ~25% reduction in size compared to compression without minification, in practice, and those kinds of gains add up, especially at the tail end of page load times.
Post reply on HN