Should the Zig community fork bun?

Challenge
1

honestly i loved the handmade vibe of bun in the beginning but now it seems like the project is going in the wrong direction.

possible improvements the zig community could make by forking bun:

  • show recognition to the vendored libraries, get what is there working well, instead of constantly adding new things
  • reverse the damage done by clankers
  • better ffi and packaging support for zig code (inbuilt compilation)

benefits to the zig community: scriptability, testing, rapid prototyping

bun could be the glue that leads to wider adoption of zig code inside of web applications. If there was better support to compile and package zig code with bun, people could selectively replace part of their typescript code with zig.

3

What’s the point of Bun or Deno? Node is great. I never understood the value proposition of these other projects.

7 Likes
5

More fun than that would be building something based on Kiesel.

9

I would consider this just a not well thought-out question, but the interest in tweeting about this thread from a brand new account forces me to consider the case where the main interest is just to enjoy seeing reactions rather than to actually exchange opinions.

To answer the titular question: no, we’re not interested at all, thank you very much.

12 Likes
2

Why does it matter that bun was written in zig?

It was never zigs flagship product (that would be the compiler itself) and was never the biggest project written in zig (pretty sure that would be tigerbeetle).

What benefit would there be to keeping bun in zig?

Zig is already being adopted more and more, bun is a minor exception to that.

And there is no reason you need a scripting language implemented with zig, even if you want one there are better languages than js/ts already implemented in zig (search this forum for some!).

Interoperability with js/ts was never a goal of zig.

I think you are focusing on all the wrong things

3 Likes
4

If you’re moved to build a javascript runtime, then do it! But I’d argue that that is such a large project / commitment that forking something as far along as Bun, Deno, Node, etc doesn’t make sense. They’ve made so many foundational choices, and so many tradeoffs. For something like a runtime + stdlib, you’ll feel hamstrung by their decisions.

Assuming the goal is actual adoption, you’ll be living with your baby and it’s codebase for years. Make it your own with your vision and eventually your community’s vision! Let the other projects do what they will and bring your own thing into the world.

3 Likes
6

The one great feature of Deno is that it can directly import from remote locations without requiring scaffolding files likes package.json, e.g. you can do things like:

import { copy } from 'jsr:@std/fs@^1';

That’s really nice for standalone cross-platform ‘shell-scripts’ (for which I used Python before).

Also it’s just a single executable (the macOS homebrew install is 9 files, but that includes shell completions, readme, license, …)

IMHO Deno is overall an actually better Node, just a shame that the core vision has been watered down by the need to be ‘successful’ (node/npm compatibility, ‘enterprise features’ etc…).

3 Likes
7

If the goal is to show that Zig is powerful and to get Zig recognition, I think a better proposition would be going for a space that is relatively unoccupied, or does not have major competition going on. This is essentially what made Bun shine initially, it comes from a place which only really had Node, it improved on the state of Node at the time. That drove improvements in both Node and Zig, but also Deno. A “Zig community fork” would only get 1 day worth of HackerNews attention, which I’m not sure if it is a positive for the fork or Zig, and when it inevitably dies down due to niche scope and project oversaturation in the field, it will no doubt be used as a “hey look! this language sucks so bad that they couldn’t maintain this fork!” by the same group it got attention from in the first place.

Ultimately, the Zig community (and programmers in general) should write software for fields that interest them, that solve projects that interest them, and if they do a good job, it’s good for Zig too!

6 Likes
10

Porting of my posix-based project to 0.16.0 was based on vendored bun usockets.

So I “learned” bun’s internals, at least low-levels

Bun used Zig as “best C” (and now it uses Rust as “best Zig”)

One important issue related to Bun, that we need to remember and take upon consideration in the future - it’s impossible to implement bun network IO model using new Io.

Regarding fork - bun itself is not framework, it’s specific application dedicated to one use case

I don’t see any reason for fork - just migration to 0.16.0 will be real challenge

Possible good exercise for AI

1 Like
8

Who is this pitching to specifically? The zig community isn’t a co-ordinated group, it’s just people who like zig. If someone feels the idea of a bun fork is appealing I’m sure they’ll give it a go, but that doesn’t guarantee community buy-in.

8 Likes