Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cruller: Bun's Zig Runtime, Continued on Zig 0.16

ziggit.dev

Post reply on HN
Print view View original

11–20 of 127 posts

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#11

Post by flohofwoe »

pjmlp wrote: post #6

As usual, most forks created out of community rupture eventually die.

I think there are quite a few high profile examples where the fork was successful (egcs comes to mind which eventually became the official gcc, also all the BSD flavours). And even when the fork ultimately isn't successful, it sometimes at least forces the original project to adapt (e.g. ffmpeg vs libav).

E.g. "it's difficult to make predicitions, especially about the future" ;)

PS: of course for this specific project I don't quite understand the reason. The original Bun was largely a line-by-line port of esbuild from Go to Zig, so it's not like the original codebase was a marvel of engineering to begin with...

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#15

Post by audunw »

muppetman wrote: post #8

[flagged]

Why feel bad? If you’re using Zig to write a game or a system tool why should you care if Bun uses it or not? All this drama has very little impact on most users of Zig or its developers (some financial impact, but Andrew had already foreseen that as a risk and avoided depending on it)

libghostty is more impactful than Bun IMO. It doesn’t matter to most other developers that Bun was written in Zig, but that such a a good library is written in Zig could have an impact on whether other devs use Zig to write libraries, or if they consider Zig for their app when having libghostty as a dependency

TigerBeetle is also more important than Bun since Zig is a better match for their needs it was for Bun, and TigerBeetle team seems to be a better partner for the Zig foundation. The Bun/Oven team seemed to be an annoyance rather than a synergetic partner.

But in general, pre-1.0, I think any large project that uses it is just a bonus.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#16

Post by m00dy »

andai wrote: post #7

There seems to be some confusion here (including in the linked discussion?) about what this is. This is not continuing the development on the original Bun (Zig) codebase. It is extracting a subset of that codebase for deployment purposes. The full version of Bun (presumably in Rust?) will continue to be used for actual development. So it is not a replacement for Bun, but a supplement to it. https://news.ycombinator.c…

yeah, no place for amateurs

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#17

Post by youre-wrong3 »

audunw wrote: post #15
muppetman wrote: post #8

[flagged]

Why feel bad? If you’re using Zig to write a game or a system tool why should you care if Bun uses it or not? All this drama has very little impact on most users of Zig or its developers (some financial impact, but Andrew had already foreseen that as a risk and avoided depending on it) libghostty is more impactful than Bun IMO. It doesn’t matter to most other developers that Bun was written in Zig, but that such a a…

This is really clutching at straws to justify zigs existence.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#18

Post by TurdF3rguson »

pjmlp wrote: post #6

As usual, most forks created out of community rupture eventually die.

I don't know that there's ever been a high-profile fork of a product acquired by such a fat, mealy, and genuinely unspooling parent as Anthropic's acquisition of Bun before.

But by all means I would love to hear some examples of that.

Re: Cruller: Bun's Zig Runtime, Continued on Zig 0.16

#20

Post by eddythompson80 »

muppetman wrote: post #8

[flagged]

Back when Bun was announced I was so excited for it. I was onboarding on a large node TypeScript project at the time and the build time and resource usage were killing me. Deno’s compatibility hacks and rough edges with node made it a non-starter.

I thought Bun’s promise of full node compatibility with better devex was a dream come true. Then “1.0” was announced and the first simple script I tried segfaulted Bun. The second threw a random error because the http server didn’t implement some stream api. I knew then that Bun was in the league of Vlang. Over promise and under delivery. Just ship “1.0” anyway for marketing and VC reasons. I haven’t touched it since. 2 people I trust that spent time looking at its code and both said to stay away.

Deno had the quality, but missed on the compat because (initially at least) it had an original and more ambitious vision. At least I’d give them that. Bun promised compat in exchange of any ambitious vision but it offers nothing. It runs on hype and hyperbole.

Post reply on HN