Hacker Newsnew | past | comments | ask | show | jobs | submit | tipiirai's commentslogin


Thanks. Seems pretty innocent to me.


What does innocent even mean in this context? I don't care if it's innocent. It is. Naivy too. But millions of people use the system and were expecting stability, not it to be a random AI experiment.


Nothing. Bun is just smaller and faster and comes with a built-in package manager, test runner, bundler, SQL engine, image processor etc..


I also use Bun.Image to collect image size and metadata, and also to generate low-quality image placeholders. Works great.

Have you tried 1.4?


have you? Type -canary instead of this garbage article


Unused code is one issue. A project called Buz[1] found over 11,000 lines of dead code from the Rust port.

[1]: https://github.com/jazzzooo/buz


That was 11,000 lines of dead code removed from pre-rust Bun. In a million lines of vibed Rust Bun I'd be astonished if there was a mere 11,000 unused LoC. Noticing unused code isn't a strength of LLMs in my experience.


11k out of a million. I wish I had a project under 1% of "dead code".


there are linters that check for dead code (depending on your language / ecosystem), it should always be 0%


The dead code was removed from the pre-Rust Zig version. The OP has no credibility.

P.S. Nor does new user parenting my comments.


Flag the article and move on.


You cannot be serious, any person with actual professional software experience would laugh at that claim


I mean, how do you check that your frontend code (possibly not even managed by your team) is calling and needs all of your backend endpoints? I'm sure it can be done, and it probably should, but saying it should always be 0% is not very pragmatic.


Dead code likely means chunks of code not used by other chunks of code, which should be easy to determine statically in most modern languages. Whether an exposed endpoint is being hit (used) or not as an API is more of a test-code-coverage thing, different from the concept of "dead code".


True, but Bun actually has a similar problem. It's creating bindings to a JS runtime. If the JS glue code then no longer uses it, the code is still marked as alive because it's registered with the runtime.


In a previous life I managed to deliver a system with (basic-block) coverage measurement compiled in (gcov) but instead of the mess of files gcov generates, the whole coverage structure was streamed to a remote server (it compressed very well). Once that was in place it was an amazing telemetry tool.

Later on used Intel Processor Trace in a similar fashion for even finer (mc-dc) coverage.

Coverage tools are very useful, if a bit hard to use...


First of all, I'd need to see a diff on that. It's insane to make that kind of claim without backing it up. Second of all, dead code (as in truly dead code: like an if statement that is guaranteed to never be true), is optimized away by the compiler. So even if we had all this dead code, it is not an issue that would ever impact the final product. Third of all, the Bun runtime consists of over a million lines of code, so that figure (again, even if true) is insignificant.


> It's insane to make that kind of claim without backing it up.

A bizarre accusation. It's a fork of Bun that says they removed the dead code. All you have to do to see the diffs is look at its history. Most of the commits are code removal.

It's a fork of Zig bun, though, not Rust, so hardly relevant to the AI argument.


Congrats on completely undermining your own argument and credibility. Did you not even read your link?

> Buz is an early-stage experimental fork of pre-Rust Bun.... Over 11,000 lines of dead code removed from upstream Bun.


I'm still waiting for v1.4 as I have committed to Bun so much. Not looking good, though.


I've been a heavy user of Bun since 2022. The last three months of their public timeline have not looked good, so I wanted to summarize my frustration


This was useful to read, thanks.


[flagged]


> Bun 1.4 Rust rewrite is not looking good

This is.. clickbait ?


I'd love to know what the alternatives are and how this is better


This will be a little faster right now on an M4 or M5 because it's optimized for Apple Silicon. Assuming this model is still state of the art in six months, which might not be a surprise given how long other video models have taken, this should be much, much faster with the M7 chip.


I totally agree with you.


I like it!


:)


Can someone give me one concrete use case that explains what this does, and how it is useful/different? Thanks!


It's a multiplexer w/ distributed state. If you know about tmux then it's basically tmux but someone else can connect to the same session w/o logging on to the same computer. I can imagine it being useful for debugging production outages b/c several people can use a single "dashboard" for coordinating their work w/o having to go back & forth on slack/zoom/etc. You can ask any chat bot to explain further if you want to look into it: https://share.google/aimode/XadkUVcvpjlYhuWmK


I get the tmux part, but not the slack/zoom part. What does “for all work” mean technically?


The list of people on their announcement page have a track record that will probably answer your question.


Can you give me one concrete use case that explains how this is an incredible idea? Thanks


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: