I’m starting a project that requires a lower level language. Ideally I have tighter control of memory and no GC. I want to move fast and be safe. Go gives me the speed of development I desire, but is a little higher level than this project calls for. Rust is in theory the right choice, but my development speed is like molasses. Given I hope for this project to turn into a company I seek VC backing for, I’m uncomfortable investing in a tool that slows me down so early on.

How has Zig been for you in this regard? Do you have any regrets building your company’s flagship software around it at this stage?

IMO Zig right now is fairly buggy. And the rate of bug introduction has been greater than the fixing of said bugs over the past few years. (Not a knock on the project.) Move fast and break things. Trying to develop production quality software in Zig is like trying to hit a moving target. Zig is not production ready, and they mean it. The ABI is not stable and features are removed/retooled from version to version. (eg. removal of async.) This is all stated upfront, however. Zig is a WIP. That being said, if you've read the warning labels and are still excited there's /tons/ of promise. They are on the right track to being a modern C replacement/augment/mux with an integrated build system. And it's a joy to program in. And the community is pretty great. The best way forward is joining the community and contributing in one way or another, because Zig will be quite special once it's done. Bun is a clear indication of this.

I'm also interested in this, the segmentation faults Primeagen found in Bun were concerning: https://youtu.be/qAYFepR4GcE?t=370 might have been fixed by now though.

I was seriously looking at Zig, but I'm always getting faster in Rust and it feels like the downsides of extra complexity is well worth the upsides for larger projects.

What's the target level of compatibility with existing npm modules? 100%? Some lower percentile?

Hate to carry forward baggage of past design choices, but likely essential to really get widespread adoption. I'd definitely start using Bun for my projects today (non-production), if it works seamlessly with existing packages.

We want Bun to feel more like an upgrade from Node than switching runtimes

Basically everything that doesn’t rely on node’s internal “bindings” C++ stuff should eventually be supported

Will bun perpetuate the dependency hell that it prevalent with node? I like the deno approach better in this regard.

Are there any install methods other than piping curl into bash? Like packages.

I suppose a compatibility shim for features that should not go into the new core could work. It would have a performance cost, but as long as this cost is limited to some deprecated APIs it would be OK.

Yeah, a compatibility branch or a build time cross compatibility compiler would suffice.

Congrats on the release!

Were there any organizational or policy changes after the "9 month grind" [0] tweet? Or is this still the policy of the bun/oven org?

[0]: https://news.ycombinator.com/item?id=32584211

Tweet in question:

https://archive.ph/PP6Im

I have been unable to locate examples using remote import/export. I would like to able to do a

  import { inflate } from "https://www.example.org/libs/zlib.ts"

with bun downloading all dependencies in the background. Like Deno does.[1]

[1] https://deno.land/manual@v1.28.3/basics/modules#remote-impor...

I’ve built a few utility apps at work. I absolutely love it.

I hijacked your jsx support so that I had built in server-side templating without having to pull in any external libraries (e.g. React). The process of building my own TSX bindings was pretty trivial, but did feel like a hack (I created a React package.json entry that was a file path to my local source folder).

Is that scenario doable with less hackery?

You can set “jsxImportSource” in tsconfig.json or jsconfig.json to point to a different jsx package

There is also a setting in bunfig.toml but it appears we haven’t documented it yet

Bun seems really cool! I had a question about this part:

> Bun now works in more Linux environments, including Amazon Linux 2 and builds for Vercel and Cloudflare Pages. (Previously, you might have seen errors like: "version 'GLIBC_2.29' not found")

How would building for Vercel and CF pages work? Like normal but installing the relevant build tools using bun?

Bun is able to run in these environments now - before it had that glibc error

Right now you’d need to download it via curl https://bun.sh/install | bash

But we need to make that better

Additionally, I'd love to see the PR where this change was implemented. I've been trying to convince Zola, a static site generator written in Rust, to support older versions of GLIBC.

Most of the code is here. It needs some linker config but basically you wrap symbols which depend on too new versions of glibc and dynamically load them or call some other implementation internally

https://github.com/oven-sh/bun/blob/main/src/bun.js/bindings...

Are there any exclusive features that Bun has, that are particularly well-suited for writing databases or other low-latency, high-throughput I/O applications?

Seems like being written in Zig might give it a good foot in the door here.

I was curious where the 'dgram' module is on your roadmap?

Lower than “tls” and “dns”, but not much lower. It’s necessary for databases and anything databases need is important for Bun to support well

Who do you see as biggest competition (Eg Just-JS, Deno, etc)

Thanks for all you do to make the ecosystem better, btw.

can Bun help solve the hell that is running `npm install` in a project and seeing an error mentioning `node-pre-gyp` in the output with some platform-specific native dependency build issue

Great job, when can we expect native MS Windows support?

What are the things you are hoping to release in Bun v0.4?

Is there a plan to add:

- Compiling to a single binary

- WASM

Check out bkg, the vercel/pkg for bun