Hacker News Reader

Comment by junon | Hacker News Reader

It's also sad that Bun is written in Zig, which has not had a proper review of the stdlib since it's not v1 yet, where Andrew has already stated publicly that Zig should not be used in production until v1 due to security vulnerabilities in the standard lib.

But here we are.

View on HN

Bun uses Zig’s standard library carefully. We read the code for the parts we use (and sometimes change it locally). We also rely on mature C/C++ libraries like picohttpparser, BoringSSL, c-ares (along with the C std lib). We use lots of code from WebKit, and are starting to use more of their security features like segregated heaps

I have no idea what's driving this but it's a repeated pattern on HN and we need it to stop. No more of this, please.

https://news.ycombinator.com/item?id=34675866 (Feb 2023)

https://news.ycombinator.com/item?id=34675665 (Feb 2023)

https://news.ycombinator.com/item?id=34669045 (Feb 2023)

https://news.ycombinator.com/item?id=34439732 (Jan 2023)

https://news.ycombinator.com/item?id=34138064 (Dec 2022)

We detached this subthread from https://news.ycombinator.com/item?id=37246288.

Bun is currently below v1.0, so not declared production-ready either.

But I'm not sure Bun should go to 1.0 without Zig going to 1.0 too. And Zig 1.0 is a distant target, which is a normal timeline for a programming language.

Bun is apparently targeting September 7th for a 1.0 release. I also have concerns about delivering a stable api using a language that doesn't have one yet.

Tbh I've had the same issue delivering my own 1.x software with 0.x dependencies and my argument has always been that it's my problem, not the client's, so "do not worry". Being realistic, no sw offers any guarantees and Zig's 1.0 stability is more of a "contract" than a "guarantee".

What security vulnerabilities, exactly?

I've never heard Andrew say you shouldn't use Zig in production because of "security vulnerabilities", but simply because Zig is quite immature (expect bugs including segfaults in perfectly "good" code) and changing constantly, not something anyone should want in a production setting.

Honestly. In a world in which JavaScript is the number one language, I’m walking back on the idea that “instability means no good for production”.

10 years ago, I thought for sure that JavaScript devs were eventually going to get sick of breaking and deprecating changes, but they’re still going strong with picking frameworks that just don’t give a shit, switching to new breaking tool chains, etc.

It seems that there are A LOT of developers willing to put up with a whole lot more than I am.

The one I found a while back was a DOS in UTF-8 decoding. I believe it's since been fixed but things like that given that the standard library hasn't been audited. Andrew will definitely have that happen at some point but I'd not put anything Zig into production right now, personally.

Many :(

> Andrew has already stated publicly that Zig should not be used in production until v1 due to security vulnerabilities in the standard lib.

Andrew has made the claim a couple years ago that Zig should not be used in production yet. The part about security is not at all part of anything he ever claimed, and is in fact only something that you went crazy about on your own.

See: https://news.ycombinator.com/item?id=34669045

While I can understand holding real hard onto your opinion, please don't put words in people's mouths, especially when the person in question does not share your position on the matter at all.

Please don't cross into personal attack. You can make your substantive points without any of that.

https://news.ycombinator.com/newsguidelines.html

Aren't both these things true?

- he says it shouldn't be used in prod

- he acknowledges there are potential security flaws that should be revisited before 1.0 (https://github.com/ziglang/zig/pull/4929)

I just feel like there is a lot of hair splitting here.

Reply on news.ycombinator.com