Hacker News Reader

Comment by jedahan | Hacker News Reader

Is there a better phrasing you could use than "drop-in replacement" for a 1.0 release that has decided to not implement all of "node:"?

The let-down from the first two projects not being a drop-in replacement is jarring, now I have to be skeptical of all communications coming from bun.

For context, both projects use osc which requires dgram. I was able to find a feature request tracking ticket from 9 months ago with no communicated plans to implement, but searching for 'dgram' in this announcement page doesn't show anything.

For a quick suggestion - can you explicitly state what modules are not supported by bun 1.0 and put that in the section related to node.js compat?

edit: found the docs on node support - https://bun.sh/docs/runtime/nodejs-apis . Would be nice to link in the release notes.

Cursory glance looks like for modules - 17 implemented - 17 partially implemented - 7 unimplemented

View on HN

I think the version is actually closer to `1.0.0-beta` than to `1.0.0`. I just installed v 1.0.0 and run `bun repl` and it failed with exit status code 1, it turns out the repl wants to use port 3000, which was used in my case already. There are probably a lot of other small things like that, look on reported bugs in github. So, I also should be 'skeptical' about all claims they did.

Nevertheless I am super impressed with their speed and exited with the result. Didn't expect this project to grow so quickly to this state, I though it will take them much more time. For comparison, deno was started way earlier and now they are miles behind (personal feeling). I am considering to use it for my pet projects

bun repl was a last-minute hack we added. All it does is "bun x bun-repl" which is currently not an official thing.

The repl is about to be added and rewritten completely

I’m a little surprised they announced 1.0 already. When I tried bun a little while ago, I noticed many bugs reported on GitHub around reading from standard-in and readline. I attributed it to being a pre-1.0 thing, but those bugs have not been resolved as far as I can tell.

What issues are you running into? We added support for setRawMode in Bun v0.8 (a month ago) and that addressed many issues with stdin and readline.

The port being in use is user error not really fair to put that on bun.

The following is probably not relevant for bun. But as an aside:

Most programs should bind to port 0 and let the OS allocate a free port and then report the resulting port to any future clients.

It is when you're trying to run a REPL. You really shouldn't need exclusive access to a port for that.

How is Deno "miles behind?"

I just started a new project, writing the back end. I'm new to JS and TS, and I don't want to deal with NPM and a morass of modules at all. Deno, Oak, and MariaDB seem like a pretty tidy combo. I have routes and queries up and working with no experience in writing server-side code since PHP 5.

What makes Bun better?

1.0.0 means the API and semantics are stable, not that there are no bugs.

> Cursory glance looks like for modules - 17 implemented - 17 partially implemented - 7 unimplemented

The question isn't just how many? but also which ones?. Anecdotally, I've been test driving bun for a large application with millions of existing customers. So far, the only issue I've had isn't with bun per se, it's with patch-package not yet supporting the lock file (bun.lockb).

Bun is without question faster than yarn by a wide margin. And I say this as someone who really loves yarn.

All good questions - and every person has different needs.

The fact is each potential adopter either needs to go through and comb over the compatibility page (not what I would expect with a drop-in replacement); or just try and see if it works, and be surprised later if they run into an unimplemented module because they were operating under an incorrect assumption.

In the section related to node.js compat, they state:

> Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.

The detailed breakdown explicitly states which modules are not supported.

Drop-in replacement [1]

---

[1] Not a drop-in replacement

"Drop-in replacement" doesn't imply perfect 1:1 compatibility with no missing features or differences. Otherwise there would be no such thing as a drop-in replacement (in the software world at least).

If a drop-in replacement isn't almost assuredly 1:1 compatible then _what the heck is it_? The nodejs compat page for Bun notes that base64 encoding is still incomplete. Where do you draw the line?

> Where do you draw the line?

That's up to you, and society. Do you accept that tall people exist?

Right. Now exactly what height do you need to be a "tall person"?

This is the same. I haven't used it so I can't say how optimistic their "drop-in replacement" claim is, but they certainly don't need it to work 100% of the time with 100% of project with 0 changes to make that claim.

"Drop in replacement" makes an implicit guarantee about utility. It sets expectations about what I'm able to accomplish by investing time and effort into a solution. I don't expect tall people to have any specific utility.

If you call something a drop in replacement and it is not a drop in replacement, it's simply a lie.

> Otherwise there would be no such thing as a drop-in replacement (in the software world at least).

That's obviously wrong, because there are things that could be different while the API/compatibility is still matching 1:1, such as:

- speed, memory usage, memory safety

- additional features, more capabilities

- simple licensing stuff

Imho, a drop-in replacement actually suggests that you can simply swap out the runtime and expect your code to work out of the box.

To me it mostly implies that wherever the replacement is supported, it doesn't require substantial reconfiguration or learning a different interface. It's about that approach, even when the execution of that approach is limited or incomplete in scope.

It does generally suggest a high degree of compatibility to me though.

I think the definition on Wikipedia is correct, otherwise a "drop-in" replacement is no different than any other replacement, making it a meaningless term.

> [Drop-in replacement] refers to the ability to replace one hardware or software component with another one without any other code or configuration changes being required and resulting in no negative impacts.

https://en.wikipedia.org/wiki/Drop-in_replacement

I don't see a conflict by that definition. The drop in could easily or partially be interpreted from the perspective of the receiver and does not have to be a static property of the replacement.

Sure, and for many projects it can be replaced without any other code or configuration changes.

My feeling is that not all replacements have feature parity, but a drop in replacement does.

podman is a drop-in replacement for docker but yarn is not a drop-in replacement for npm. Makes sense?

Yes exactly. Podman is not 1:1 compatible with Docker. Occasionally you will run into issues e.g. due to the rootless nature. I actually recently had to uninstall Podman and replace it with Docker due to an incompatibility!

But it works enough of the time without any changes that it's reasonable to call it a drop-in replacement.

Either I missed this on first read-through, or they just added it.

It seems the note mentioning this feels buried for me under a large banner image, instead of near all the other text about compatibility.

Anyway, glad it is there, hope that their communications design improves in the future as at least a few others got caught with mismanaged expectations.

I second this notion. I was really excited to try it out, only to have it fail to run most of our projects:

* can't use AWS SDK v3 because throws an error when parsing a response;

* can't use octokit (or anything that depends on jsonwebtoken, for that matter) because node:crypto is not fully implemented;

* can’t run our tests, because jest.resetAllMocks() is missing

* in another project, bun test failed to even run, complaining about invalid call to shared library So for me the local workflow is “run it with bun, see if it fails, re-run with node if it does”. At least I can always replace npm with it, I guess? Can’t imagine running our services with it just yet. Really excited for the future of the project, because when it works - it really is amazing. But I wouldn’t call it 1.0 if the selling feature is Node compatibility.

Reply on news.ycombinator.com