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

91–100 of 243 posts

Re: Bun 0.6

#91

Post by tracker1 »

claytongulick wrote: post #74
winrid wrote: post #24

Earlier quoted context omitted.

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

It doesn't HAVE to be that bulky or complex. You have a lighter space like Dokku or just direct scripted deployments pretty easily. As to the size, you can use debian-slim or alpine as a base for smaller options. There's also bare containers, or close to bare for some languages and platforms as well (go in particular).

Re: Bun 0.6

#93

Post by sroussey »

yobuko wrote: post #58
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

First, thank you for all of your hard efforts. I have seen some desire and works expressed towards using Bun with Electron or Electron alternatives; this interests me greatly. Do you have any plans or aspirations to make any strong push in this direction?

This would be awesome. Use bun as the main process (replacing node) and have the front end use the system webview. The system webviews are good these days.

Re: Bun 0.6

#94

Post by colonwqbang »

qbasic_forever wrote: post #61
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…

Bundling is totally different from linking and building for native platforms. Bundling is all about optimizing code to be sent over a small pipe--you're combining multiple compilation units into one file (so just one web request and lower latency) and doing optimizations like tree shaking to send only the code that's actually used. It's a pretty unique use-case that not many other programming languages deal with or c…

A native compiler also optimises the code. A native static linker also tries to omit unused library data and code. It's absolutely not the case that native devs don't care about code size (we do!)

I guess Javascript uses a slightly unusual executable format, text instead of binary. Otherwise, it seems like very much the same thing?

Re: Bun 0.6

#95

Post by tracker1 »

hiccuphippo wrote: post #67
chrisco255 wrote: post #21

Earlier quoted context omitted.

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.

Deno changed their opinion recently and will offer Node.js compatibility. Apparently it wasn't such a good idea to not be compatible on purpose.

I actually have mixed feelings on this one... since I think Deno's approach has been generally cleaner, but also recognize the scale of what's in NPM.

Re: Bun 0.6

#96

Post by conradev »

f311a wrote: post #76
conradev wrote: post #17

Earlier quoted context omitted.

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

JSC is a multi-tier JIT with the last stage ultimately being LLVM, so if you want to be pedantic, Bun relies on LLVM’s optimizer which is written in C++.

The transpiling itself is written in Zig, which is the part that has the performance improvement. If Bun relied on JavaScript and JSC for the heavy lifting, it would be no faster than the other JS bundlers.

edit: no longer LLVM: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...

Re: Bun 0.6

#97

Post by mirashii »

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.

> 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 to diagnose bugs over the years, e.g. https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

Re: Bun 0.6

#98

Post by sroussey »

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

Bun is awesome! Need debug support and console fixes. Please!!!

Re: Bun 0.6

#99

Post by chrisco255 »

hiccuphippo wrote: post #67
chrisco255 wrote: post #21

Earlier quoted context omitted.

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.

Deno changed their opinion recently and will offer Node.js compatibility. Apparently it wasn't such a good idea to not be compatible on purpose.

Didn't realize that, thank you. I can empathize with Deno's desire to take backend JS in a more web-native direction.

Re: Bun 0.6

#100

Post by leeoniya »

pier25 wrote: post #81
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…

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

ICU :(

https://github.com/oven-sh/bun/issues/2541

https://twitter.com/jarredsumner/status/1616597667408404481

Post reply on HN