> ...
> pnpm
pnpm's flagship feature is global deduplication of packages, so sadly bun's package manager doesn't seem to be a replacement. Is there any plan or intention to support pnpm-like disk saving?
That said, I'm very impressed with the speed of `bun add` with already cached packages. Literally instant.
According to that, the speed benefits will probably not be as noticeable in windows.
That, coupled with the fact that bun installs twice as fast when no packages are cached (634ms compared to 1.3s) and 100x as fast when all packages are cached (6ms to 639ms), I think it's fair to say that bun can replace pnpm.
Here's the package.json I tried:
{ "dependencies": { "express": "^4.18.2" } }%I know it’s possible to get it to work, but I didn’t have time to fiddle all the bits.
If Bun made this easier, I’d switch from pnpm immediately.
"Unlike Node.js and other runtimes that are built using Google's V8 engine, Bun is built using Apple's WebKit engine. WebKit is the engine that powers Safari and is used by billions of devices every day. It's fast, efficient, and has been battle-tested for decades."
That's really interesting, does WebKit do less JITing or something to be faster for startup?
I am still absolutely amazed at how much more performant websockets throughput in bun vs node.
Congrats on 1.0!
But from anecdotes, I have the impression people still run into bugs and missing functionality semi-commonly. I'm sure it works great for small/personal projects, but I've been hesitant to recommend it for production use at my workplace because of this impression
So my question is: how feature-complete/stable/secure is it right now, what does the v1.0 label say about that, and what are the long-term plans/prioritization/guarantees around this area?
Sure, the instability of Zig may increase the maintenance costs for Jarred, to use updated versions of Zig. But this has no effect on the features that Bun provides. The risk that a change to Zig would be so consequential that they would actually prevent Jarred from continuing to work on Bun, or would otherwise force Jarred to fork Zig, that risk is so low as to be inconsequential.
(disclaimer: not associated with either bun or zig, the above are pure opinions)
With that said, it is probably fine to use for most ordinary apps, but I wouldn't yet build a bank infrastructure on top for example.
This has probably been asked before, but has there been any thoughts about moving community chat to a platform other than Discord? Discord has been brought up many times on HN for its accessibility/privacy/proprietary lock-in concerns that don't seem to be in line with the spirit of open-source. Also see [1].
[1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...
https://news.ycombinator.com/item?id=35970869
And in the comments of the bun 0.8 announcement, the same question generates very little interest and some well every other project uses it, so...:
> Choosing proprietary tools and services for your free software project ultimately sends a message to downstream developers and users of your project that freedom of all users—developers included—is not a priority.
— Matt Lee
And I think Deno uses it.
> Discord-hate is a double standard that is not applied to any service
What does this mean? Dropbox/Amazon/Google/Windows get criticism across the web and on HN regularly, some of those far more than Discord.
> to the extent that comments criticizing Discord appear with extreme regularity on threads that should be completely unrelated
I don't get it. Are you implying a conspiracy?
Discord is just an added communication channel, mostly for the community.
Relevant discussions happen on GH.
I am part of numerous programming discords and I just see no issue with them being on discord, again, starting from the fact being there is far from being a requirement for anything really.
Has Discord ever asked you to provide and confirm your phone number to continue using it?
But otherwise, yeah, I would warn against potential vendor lock-in, especially if that service is not open-source.
Well, and joining most discussions require an account, and if your alternative communication platform is Discord, we see all the same issues of lock-in.
> What I can tell you is that, to my surprise, Discord’s accessibility has apparently improved in recent years, and more blind people are using it now. One of my blind friends told me that most Discord functionality is very accessible and several blind communities are using it. He also told me about a group of young blind programmers who are using Discord to discuss the development of a new open-source screen reader to replace the current Orca screen reader for GNOME
Discord is honestly a great place for FOSS to house their communications. I find all of the articles claims very haphazard:
> When you choose Discord, you are legitimizing their platform and divesting from FOSS platforms
It is legit? It's free? It has loads of compelling features, is very accessible, and - most importantly... Also, choosing Discord does not take value away from FOSS communication platforms.
> Use IRC
It isn't IRC which is very inaccessible to lots of people new to computers and software in general.
Yes, but this ignores the others issues the post brings up: Users who cannot afford new enough hardware to make the resource-intensive client pleasant to use are also left by the wayside.
Or: Discord also declines service to users in countries under US sanctions, such as Iran.
> Discord is honestly a great place for FOSS to house their communications ... Discord does not take value away from FOSS communication platforms.
The blog's author, and others such as myself disagree. Discord chats are not indexible by search engines, so solutions are harder to find. You need a Discord account, and you need to join the channel to even see chat and use the search feature. Discord is proprietary and non-extensible because of it. Lastly, Discord is also profit-motivated, so they can shut things down or add limitations because they need to maintain a profit, and there would be nothing we can do about it. "Enshittification" as HN users love to say, is practically inevitable.
> It isn't IRC which is very inaccessible to lots of people new to computers and software in general.
Which client are you speaking of? :) The beauty of IRC, Matrix, XMPP, etc is that you have the choice and freedom (without being legally threatened by Discord Inc.) to build your own client.
Instead of bashing library authors that have already so much to think, why don't you propose a discord replacement and pay for it, while providing the same ease of use for the users and the same features from channels, threads, third party apps/plugins, video conferencing, etc?
I'm glad you enjoy Discord! And thanks for your hard work. But I disagree, and all of the issues with Discord I pointed out above still persist despite your love for the UX.
> Instead of bashing library authors that have already so much to think
I never bashed library authors.
> why don't you propose a discord replacement and pay for it
I engage in communities that use Zulip and Matrix. Zulip is free for open-source projects [1], and I donate to a small community that hosts its own Matrix server.
> while providing the same ease of use for the users and the same features from channels, threads, third party apps/plugins, video conferencing, etc?
We're kinda getting away from the point here. No one is suggesting that there is a FOSS alternative to Discord that has 100% feature parity.
Wait… people can’t run web browsers?
it does though. it's the same vicious cycle that allowed microsoft to gain control of the OS market: developers write programs for windows (because that's where the users are) and users run windows (because that's where the programs run). the more people agree to use discord, the more it becomes "the place where the <x> community is", the harder it becomes for any community to not use it.
9/10 discord users don't understand or care about this at all. which is why it's of utmost importance that developers - especially open source developers, presumably developing open source software for a reason - encourage discussion on other platforms.
Free as in gratis, sure. But as in libre? No, it’s definitely proprietary & it’s free because users are the product (data collected and upselling Nitro); not every user wants to give up their privacy freedoms to participate. Discord’s not federated so users will be required to create an account & agree to the ToS & CoC of Discord, not the community running it. Discord has also been hostile towards folks trying to make alternative clients to meet usability needs & certain kind of bots.
Without IRCV3 & bouncer it would be a difficult/unexpected experience for a new user. Luckily IRC isn’t the only libre option. If you want to keep the system requirements low XMPP MUCs are good & allow federation. If you want newer bells & whistles at the cost of system requirements federated Matrix can be considered (tho centralization concerns around Matrix.org having the most users, most used server, most used client, & controls the spec). There are bridges between all of these that you can choose as many or as few as meets the community needs such as a community-hosted XMPP main server in a neutral country with bridges to IRC & Discord.
There's some room for debate about offering Discord as a bridged option. But having the official community chat only on Discord? How is there even a question?
Both are proprietary websites owned by for-profit companies. Both require you to create an account in order to participate in discussion.
Don't get me wrong. I get small developers defaulting to infrastructure they don't have to set up and maintain themselves, and I understand wanting to meet people where they're at. But it's definitely a problem that GitHub plays such a central role in F/OSS development, too.
1. Git is distributed by design. Hosting on Github tends to not be controversial because that code can also live on Gitea/Sourcehut/your private git server at the same time. If Github goes down, it does not really matter. Very different from Discord, where there is no way to actually backup server/channel data, and attempting to do so may be a violation of the ToS and get you IP banned.
2. Your argument hinges on the fact that you have never seen an open-source project criticized, but it does happen. The blogpost in the parent comment even suggests not hosting on Github.
Some time ago I asked them whether they planned to ever become Free Software so it could be actually safe and have a community around it, and after a couple of messages they went (not verbatim, but in spirit) "oh, open source? lolno", missing the point entirely in multiple ways.
Taking into account their massive teen-focused PR campaign - which is a particularly social phase of human growth and FOMO reigns supreme, their predecessor OpenFeint's demise including a privacy lawsuit, the amounts of data and metadata implicitly and explicitly collected, it's at least _likely enough to distrust it_. The doors in the back are bound to be giving that sweet personal data to whomever has a big enough money stick, and/or other non-trustable agencies.
Could you link to the program they are working on? Nothing appears when searching for "orca screen reader for gnome replacement."
Creating a channel on Matrix.org is free.
Libera.Chat & OFTC offer free IRC for open source—& can depending on the community be a welcome bridged platform for any alternative as IRC requires the least resources to run (tho if you need rooms with encryption, that won’t be an option).
I’ve been loosely following the progress of Bun for awhile, but I haven’t actually tried it. The blog post you linked does make it sound very intriguing.
[0]: http://remix.run/
Any plans for other interesting experimental features (like macros)?
I don't know how much this is still a problem, but a few years ago one area where I used to experience a bit of pain was that package.json scripts would get pretty unwieldy and supporting windows required using third-party tools. Have you consider experimenting a bit with the scripts or are you happy with the state of that feature?
It hardly mentions anything until the very bottom on what's changed to reach v1, the github release page on the other hand clearly outlines it.
Personally found the blog post to read like documentation rather than a release announcement.
Performance comparisons to Go/Java on the backend would be insightful. Would be interesting to see how close the gap is.
There's a slightly similar case high on the frontpage right now: https://news.ycombinator.com/item?id=37434918. The thing isn't released yet but the appetite to discuss it is strong.
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?
> Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.
The detailed breakdown explicitly states which modules are not supported.
---
[1] Not a drop-in replacement
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.
If you call something a drop in replacement and it is not a drop in replacement, it's simply a lie.
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.
It does generally suggest a high degree of compatibility to me though.
> [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.
But it works enough of the time without any changes that it's reasonable to call it a drop-in replacement.
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.
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 say this as someone who really loves yarn.
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.
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
The repl is about to be added and rewritten completely
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.
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?
* 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.
ESM can use top-level await and CJS can't. So this can't possibly work, right?
// x.mjs
export const x = await 'x';
// y.cjs
console.log(require('./x.mjs').x);
TypeError: require() async module "/tmp/x.mjs" is unsupported. use "await import()" instead.
But it looks like it does work in Bun if I drop the `await` from y.mjs. So, is it just transpiling ESM to CJS, and failing out if the ESM uses top-level await?
EDIT: I see the documentation page https://bun.sh/docs/runtime/modules has a "low-level details" section, explaining how import(CJS) works (by transpiling CJS to ESM), but it doesn't say anything there about how require(ESM) works, which is unfortunate, because that's by far the most interesting part! I've filed a doc bug on this. https://github.com/oven-sh/bun/issues/4601
Could the mods change the link to the blog post? It explains better than the github release page
Blog post: https://bun.sh/blog/bun-v1.0