Hacker News Reader

Comment by akagusu | Hacker News Reader

Bun won my heart because: - it uses Zig and not Rust - it uses JavaScriptCore and not V8 - it has built-in support for my favorite database: sqlite - it is all-in-one

View on HN

Careful, enough comments like that might just make Zig the new Rust. Rewrite It In Zig! Zig Uber Alles!

OTOH, that could at last free Rust from being the shiniest kid on the block. Carry on...

that can't happen with Zig, since you can just drop your C/C++ headers and call it a day ;)

however that fact that it is NOT using V8 is quite refreshing change. We need diversity in the JS eco system other than google v8. Didn't realize JavascriptCore is faster than v8.

To be fair they only said it starts faster than V8, nothing was said on runtime performance

This is the same weak argument that's being used to sell native compilation on Java. Tons of graphics showing startup time improvement, never a word on what happens after. But the only cases where this metric makes a real difference are CLI utilities and Serverless (if you know others, please tell me)

That’s not true, as far as I've read. I feel it is spelled out pretty thoroughly: Startup time and memory footprint are way lower, but peak performance is also lower: JIT outperforms static compilation due to it having more information. There are some tools to gather such information by running the program for a while, gathering stats, but JIT still outperforms.

Careful there. The JavaScript ecosystem is nothing if not diverse...

You do realize people write rust for a reason right? Not because it's new and shiny...

Well obviously. It's not going to shine when it's rusty.

To be fair: there have been several SEGFAULT issues opened already on the repo.

The only time I've seen a SEGFAULT in Rust was when using a really badly implemented C library wrapper.

Kind of unfair if that's your concern since rust has segfault issues as well.

Does it? I've never seen safe Rust segfault.

It can't people are shilling zig aimlessly.

The segfault can happen in safe rust, it just can't be caused by it. Segfaults don't happen immediately

Only with unsafe Rust , and the ecosystem is generally very good about keeping unsafe code tightly scoped and correct.

What do you have against Rust?

Haha, good question.

Should have used Nim, to make it interesting :D

too complicated

The whole rewrite everything in Rust.

Rewriting into a safe language actually has some benefits - namely safety compile time guarantees.

Only RAM manufacturers like memory leaks.

While true, I think there's a lot of "this is better because it's been written in Rust" software around these days. The emphasis is on the language, not the problem being solved.

Agreed. Some project attract attention just because it is written in Rust. Although Rust is well-designed, the language does not make everything.

Memory leaks in rust might be less common than a fully GC'ed language but saying rust prevents or makes them less common than e.g. zig/c++ seems like a stretch.

You literally cannot get them period in rust. Like it is not possible. That's the point of rust.

Leaks are absolutely considered safe by rust. Just look at Box::leak. And if we're comparing it to GC'd "leaks", those are typically hashmaps growning out of control and that can also happen

Leaks can happen in rust. The guarantee safe rust makes is that memory leaks cannot result in undefined behavior.

That's mostly a thing teenagers are doing to learn CS, when it's not it's because the software is vulnerable or slow and benefits from a rewrite in a safe language.

How is that worse than Zig in that context?

The bible is too thick!

It is effectively bait, irrespective of intent. Why would you say that “this pastry is great: it’s blueberry and not chocolate”. Is the implication that 50% of the enjoyment is on account of what it is not? Just weird.

this is very interesting difference too! can you please tell me what you like more about zig over rust and JavascriptCore over v8. very interesting cause I've always thought v8 is superior to JC cause v8 is chrome and JC = safari and zig is very interesting too

Safari consistently performs better than Chrome in JS benchmarks (on Macs).

Also some things are wayyy slower on v8 compared to other engines. (I've only checked spidermonkey.) In my experience v8 is faster at running WASM and spidermonkey is faster at running optimized js (not quite asm.js but using some tricks like |0) and starting workers.

> I've always thought v8 is superior to JC cause v8 is chrome and JC = safari

I have never in my life heard anyone say they thought V8 was superior to JSC - what are you basing that on?

The entire marketing for Chrome was that V8 was faster.

Since 2019, it seems like JSC is actually faster (they even beat V8 benchmarks).

source please?

Every JS engine has interesting design choices. V8 has more documentation than other (the v8 blog is great resource [1]). This ism ore easy to have an overview of V8 internals. It could be nice to have more internal overview from other engine, in particular SpiderMonkey. It is hard to find up-to-date info.

[1] https://v8.dev/blog

Unrelated question, maybe someone knows, each time I opened a JavaScriptCore or Webkit source file, i've almost never seen any comments. Is it me and my bad sampling or these codes have almost no documentation at all? That's really uncanny.

> it uses JavaScriptCore and not V8

Isn't JavaScriptCore available only in Apple's ecosystem?

JavaScriptCore is a constituent part of WebKit, which is pretty much available on washer-dryers these days. But the macOS/iOS/etcOS framework part of JavaScriptCore that adds Objective-C/Swift layers is only available for those platforms, yes: https://developer.apple.com/documentation/javascriptcore

As much as I wholeheartedly agree, please dont spell it out.

Zig is not perfect, Zig is full of sin, in a world full of righteousness, using Zig should be closely guarded.

Reply on news.ycombinator.com