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

111–120 of 127 posts

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

#111

Post by ericyd »

dbalatero wrote: post #82

> My idea is to strip the system down as much as possible and leave only what is required for production. > Development would be done using the full Bun runtime, while production would use its lightweight fork, Cruller. I do not have the resources of the Oven team to develop and maintain a massive general-purpose runtime, so I want to focus on specific production requirements. I don't know about others, but I don't t…

Hard agree, I would never use a totally different piece of software to run prod vs dev or local.

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

#112

Post by holysantamaria »

afavour wrote: post #101
holysantamaria wrote: post #2

What makes Bun Bun is all the things that got removed from this project. Node is already powerful enough and well maintained. Why would anyone use this?

The developer is quite clear about not wanting to make Bun. They want to make a reusable JavaScript runtime for Zig. How would you execute a Node runtime in Zig?

Spawning a process and piping the input? This does require having a node available at runtime though.

Isn’t the main point of using zig to avoid having a runtime and garbage collection to begin with?

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

#113

Post by abejfehr »

insanitybit wrote: post #38
mekky16 wrote: post #36

i dont see the point of this to be honest, if rust is actually better for bun why are you people just hating on it for no reason? a software doesnt have to be written in your favourite language for it to work. bun was a sloppy project is zig and still sloppy in rust

The repo calls out the purpose and it's pretty good.

> Bun stopped shipping a Zig-based runtime after 1.3.14 — the project moved on to a Rust rewrite. Cruller forks that last Zig-era Bun and ports it forward to Zig 0.16 instead of following Bun into its rewrite.

I might be missing something, but where does it mention why specifically they're interested in having this be Zig and not Rust?

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

#114

Post by bjourne »

Skywalker13 wrote: post #37

I don't understand why the git history has been pruned in this fork. According to the first commit in this fork: > Squashed as a single orphan commit — the original oven-sh/bun history isn't relevant to this stripped fork and its shallow clone doesn't push cleanly to a fresh remote. IMHO it's always a bad decision to do that. Here, all commit authors are lost. The original history is always relevant.

Yeah, this is one thing you should absolutely never, ever do as a responsible developer. It makes future debugging much more difficult (destroys git blame) and also is a huge dump on previous contributors who don't get credit for their work in the fork. If solenopsys is serious about the fork he should redo it. Throwing away history willy-nilly is such a giant red flag that I think he will have trouble attracting any contributors.

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

#115

Post by ShinTakuya »

sevenzero wrote: post #109
ShinTakuya wrote: post #92

Earlier quoted context omitted.

I'm tempted to suggest you have encountered the issue but your team mates are shielding you from the consequences (with or without their knowledge).

What teammates?

Well that would explain why you wouldn't need a git history.

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

#116

Post by afavour »

holysantamaria wrote: post #112
afavour wrote: post #101

Earlier quoted context omitted.

The developer is quite clear about not wanting to make Bun. They want to make a reusable JavaScript runtime for Zig. How would you execute a Node runtime in Zig?

Spawning a process and piping the input? This does require having a node available at runtime though. Isn’t the main point of using zig to avoid having a runtime and garbage collection to begin with?

That’s about the most basic imaginable implementation. Typically you use JavaScript runtimes like this to provide a plugin-like system for your static build that allows sandboxed customisation at runtime.

Take a look at the JavaScriptCore documentation to get a sense of what’s possible, it goes far beyond “piping the input”:

https://developer.apple.com/documentation/javascriptcore

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

#117

Post by insanitybit »

abejfehr wrote: post #113
insanitybit wrote: post #38

Earlier quoted context omitted.

The repo calls out the purpose and it's pretty good.

> Bun stopped shipping a Zig-based runtime after 1.3.14 — the project moved on to a Rust rewrite. Cruller forks that last Zig-era Bun and ports it forward to Zig 0.16 instead of following Bun into its rewrite. I might be missing something, but where does it mention why specifically they're interested in having this be Zig and not Rust?

> In any case, I do not want to throw away such a large codebase that has taken several years to build. It makes more sense to turn it into a convenient embeddable library that can be used throughout the Zig ecosystem.

Sorry, not repo, the link.

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

#118

Post by tredre3 »

afavour wrote: post #116
holysantamaria wrote: post #112

Earlier quoted context omitted.

Spawning a process and piping the input? This does require having a node available at runtime though. Isn’t the main point of using zig to avoid having a runtime and garbage collection to begin with?

That’s about the most basic imaginable implementation. Typically you use JavaScript runtimes like this to provide a plugin-like system for your static build that allows sandboxed customisation at runtime. Take a look at the JavaScriptCore documentation to get a sense of what’s possible, it goes far beyond “piping the input”: https://developer.apple.com/documentation/javascriptcore

But what does bun bring to the table in that scenario? Why not interface with javascriptcore directly and skip the (unmaintained) middle man?

Bun provides the node standard library, I suppose, but you likely don't want it in a plugin system. Because the bulk of it is to deal with web requests, or to allow system-wide file/network/process access. So you're going to re-implement your own safe library anyway.

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

#119

Post by afavour »

tredre3 wrote: post #118
afavour wrote: post #116

Earlier quoted context omitted.

That’s about the most basic imaginable implementation. Typically you use JavaScript runtimes like this to provide a plugin-like system for your static build that allows sandboxed customisation at runtime. Take a look at the JavaScriptCore documentation to get a sense of what’s possible, it goes far beyond “piping the input”: https://developer.apple.com/documentation/javascriptcore

But what does bun bring to the table in that scenario? Why not interface with javascriptcore directly and skip the (unmaintained) middle man? Bun provides the node standard library, I suppose, but you likely don't want it in a plugin system. Because the bulk of it is to deal with web requests, or to allow system-wide file/network/process access. So you're going to re-implement your own safe library anyway.

> But what does bun bring to the table in that scenario?

There's a middle ground between "raw C API" and "full Node-compatible runtime". It sounds like this project is attempting to use that middle ground: the Zig wrapper around JavaScriptCore, rather than the whole abandonware project.

As per another comment here:

> This is not continuing the development on the original Bun (Zig) codebase. It is extracting a subset of that codebase for deployment purposes.

Post reply on HN