Hacker News Reader

Comment by dimgl | Hacker News Reader

I've been pretty jaded by Node.js lately, especially with all of the ESM and TypeScript stuff. This led me to try using Deno but Deno was missing the mark in a lot of ways.

Is Bun in a state where I can start thinking about replacing my Node.js production toolchains with it?

View on HN

Nope. I wouldn't. Not for production.

• Bun is not stable yet (0.6.0)

• Zig, the language Bun is built upon is not stable either (0.11.0)

Nothing against these awesome projects, I'm all in for a streamlined toolchain (TypeScript, bundling, binary generation...) and other excellent goals driving the Deno and Bun teams.

But...

• Node.js is a powerful piece of software, it's stable and full of battle-tested buttons and knobs

• NPM and Bun/Deno are not real friends at the moment, just acquaintances

• Take benchmarks with a pinch of salt. Real-world app performance depends on a well-greased system, not a particular 60,000 req/s react render benchmark. Remember the adage: your app will as fast as your slowest component.

On a side note, lately I've been extending Node.js with Rust + N-API (ie. napi-rs or neon) and it opens up excellent possibilities.

https://napi.rs/ https://neon-bindings.com/

Bun might be a cool project, but them building on an immature language like Zig makes me wonder where their priorities are.

It wouldn't exist any other way, the story is that it was built with speed as a priority, and Zig was chosen for the performance optimizations it enables.

There are several other languages that could achieve the same speed and performance optimizations. To be clear, I hope to see Zig succeed and I'd like to learn it one day. It reminds me of the video game engine question, only in this case it would be: do you want to build a product, or do you want to build something with Zig? I imagine the creators of Bun answered "we want to use Zig" as their first priority, and that's great, I hope they have fun.

At one point, the Rust team switched away from the performant Jemalloc allocator to something more widely compatible (the system default). They chose to sacrifice performance in the sake of compatibility/stability. It's still available, but optional.

https://internals.rust-lang.org/t/jemalloc-was-just-removed-...

Insane performance gains, like the ones we see early in Zig, is something that can be easily eaten away by the natural evolution and maturity of a programming language.

Btw, Zig is beating trees with a stick to see what may fall down in this area: https://github.com/ziglang/zig/issues/12484

my impression is Zig wants to replace C and has the same philosophy of a very simple language that does not evolve once it stabilizes. that means to me they want to stabilize the language with small amount of features and make it as performant as possible at that point. from their webpage:

A Simple Language

Focus on debugging your application rather than debugging your programming language knowledge.

Zig, unlike C++ and Rust, doesn't need an optimized general purpose allocator in order to be fast. Zig outperforms its peers despite currently having a slow GPA in the standard library because the language encourages programmers down a path that avoids boxing the shit out of everything, which is inherently slow even if you have a global allocator optimized for this use case.

Rust switched away from Jemalloc because it uses global allocation for everything. Zig's convention of explicit allocator argument passing means such a compromise will never be needed.

As for "beating trees with a stick", I'll probably end up doing what I did for WebAssembly, which is to ignore the preexisting work and make my own thing that is better. Here's my 160-line wasm-only allocator that achieves the trifecta: high performance, tiny machine code size, and fundamentally simple.

https://github.com/ziglang/zig/blob/c1add1e19ea35b4d96fbab31...

> with speed as a priultimat

They could have just used C++ or Rust. Not saying that they shouldn't use Zig, just questioning speed as the (primary) motivation

I've been pretty happy with Deno... mostly in personal use... still some rough bits in terms of Node compatibility but pretty good in general.

Reply on news.ycombinator.com