Bun v0.7.0(bun.sh)
bun.sh
Bun v0.7.0
https://bun.sh/blog/bun-v0.7.0
157 comments
This is cool but I'm struggling to think of a case where I'd want to run backend JavaScript in a memory constrained environment, doubly so where performance isn't a concern.
I have an example for you. I self-host a Telegram bot, which is written in Python. However, I believe that if it were written in JavaScript, the situation would be similar.
The bot is rarely used, so on average, it only uses 0.06% of my machine's CPU power. However, it consumes 3% of the RAM at the same time. --smol switch according to Jarred's tests reduces memory usage ~7 times by increasing CPU usage just 2x times. In my case such redistribution of resource consumption would be a clear win!
To save RAM, I actually switched to a 32-bit Python base image. This switch resulted in a 30% reduction in RAM usage.
The bot is rarely used, so on average, it only uses 0.06% of my machine's CPU power. However, it consumes 3% of the RAM at the same time. --smol switch according to Jarred's tests reduces memory usage ~7 times by increasing CPU usage just 2x times. In my case such redistribution of resource consumption would be a clear win!
To save RAM, I actually switched to a 32-bit Python base image. This switch resulted in a 30% reduction in RAM usage.
Full process/container isolation for many instances of untrusted code, perhaps? A serverless PaaS could use this to cut down significantly on the frequency of cold starts, all else being equal.
> This is cool but I'm struggling to think of a case where I'd want to run backend JavaScript in a memory constrained environment, doubly so where performance isn't a concern.
Maybe launching lots of separate services/containers locally, just to have the ability to debug everything and step through how a request travels through all of the services in one go, with multiple IDE instances also open locally, in addition to other stuff?
Distributed tracing is nice for remote environments, but having 5-20 IDE instances open with all of the related services can also provide a nice debugger experience. Not every machine has ample RAM for this, though, so I guess it's nice to have the option, without the processes/containers running into OOM so much?
Maybe launching lots of separate services/containers locally, just to have the ability to debug everything and step through how a request travels through all of the services in one go, with multiple IDE instances also open locally, in addition to other stuff?
Distributed tracing is nice for remote environments, but having 5-20 IDE instances open with all of the related services can also provide a nice debugger experience. Not every machine has ample RAM for this, though, so I guess it's nice to have the option, without the processes/containers running into OOM so much?
The macbook air only has up to 16GB of memory right now. There's plenty of cases where one might want to run a javascript script on their laptop which uses quite a bit of memory, and they'd rather it complete at all, even if it's a bit slower.
I definitely have a M2 Air with 32GB. The point stands, but you aren't limited to 16GB on the Air
Can you point to that configuration in the apple store? I can't find _any_ M2 Air that can have more than 24Gb.
Oh yeah it's 24. Still higher than 16. My bad
Base M2 tops out at 24GB.
Uninformed spitballing here but I can totally imagine brewing up an eInk display that grabs X from the internet then draws something via the Canvas API. JavaScript would probably be a fine solution for that.
Sidecars perhaps. Don't bogart the memory.
Yeah, and how is this different from the behavior V8/JavaScriptCore would already have on a system with very little memory? Unless this actually makes it possible to run on lower-memory systems than before, I don’t really see how it’s helpful. Unused memory is wasted memory and all that. I hope it’s using every last byte, not letting memory sit unused.
I like it :) as long as there are clear descriptions and docs there could be more whimsy in software
Maybe I'm dating myself, but it took reading these comments for me to figure out that "smol" is pronounced "small" and not "es em oh el". Only after that did I think to Google it and find the dictionary.com slang entry [0].
If some significant portion of the user base is as slang-ignorant as I am (for example, most who speak English as a second language!), it'd be good to support both --small and --smol for mnemonic reasons. Remembering a series of letters that have no meaning to you is much harder than remembering a word that obviously relates to what you're trying to accomplish, and if I had landed on the bun docs first I would have continued pronouncing it "es em oh el".
[0] https://www.dictionary.com/e/slang/smol/
If some significant portion of the user base is as slang-ignorant as I am (for example, most who speak English as a second language!), it'd be good to support both --small and --smol for mnemonic reasons. Remembering a series of letters that have no meaning to you is much harder than remembering a word that obviously relates to what you're trying to accomplish, and if I had landed on the bun docs first I would have continued pronouncing it "es em oh el".
[0] https://www.dictionary.com/e/slang/smol/
Go nuts, but please make your silly stuff an alias if you must.
Wait, who decided all software is now Entreprise Edition (EE (tm)) focused?
This has nothing to do with enterprise, it's about accessibility. For most people on the planet English isn't even the first language and now you expect them to know about obscure wannabe-cutesy internet slang? Fuck that shit, what's next? UWU.md instead of README.md?
A --small flag would provide approximately the same amount of information - you'd still need to read the description to figure out what it does.
And thanks for the UWU.md idea, love it!
And thanks for the UWU.md idea, love it!
English isn't my first or even second language. --smol creates a lot of confusion in my head. It doesn't even make any sense. Why not --less-ram or similar?
What does UWU means? Why using an artificial language instead of established one?
What does UWU means? Why using an artificial language instead of established one?
UwU is a cute looking face which also sounds funny when pronounced
https://en.wikipedia.org/wiki/Uwu
https://en.wikipedia.org/wiki/Uwu
[deleted]
To me, --small gives much more information. I immediately assume that it means something is smaller than the default, memory makes immediate sense. --smol on the other hand could be an acronym or a technical word I just don't know, the likelihood of random internet slang actually being one of the first interpretations seems low for most engineers.
Let's turn this around. If the flag was called --cutesy-wootesy-fartsy, would you still argue it's approximately the same amount of information? If not, can you explicitly explain why not?
Let's turn this around. If the flag was called --cutesy-wootesy-fartsy, would you still argue it's approximately the same amount of information? If not, can you explicitly explain why not?
[Scruffy voice] Second.
I'm writing out a bunch of notes for a technical screen in an UWU.md file right now (even if I'm definitely not shipping it to them like that)
I'm writing out a bunch of notes for a technical screen in an UWU.md file right now (even if I'm definitely not shipping it to them like that)
People like you make me want to code only in Brainfuck.
This sort of gatekeeping over programming culture and aesthetic is only causing the community to further splinter between people with sticks up their asses and people who just want to have fun and enjoy life.
This sort of gatekeeping over programming culture and aesthetic is only causing the community to further splinter between people with sticks up their asses and people who just want to have fun and enjoy life.
I don't see the limits in your ignorance. Bad names doesn't have anything in common with programming culture or aesthetic.
The notion of a "bad name" is evidence of aesthetic gatekeeping.
You can sometimes say something is objectively bad: You shouldn't name your class `Car` if it models a boat. It's unrelated.
However to argue about "small" vs "smol" is a matter of pedantry. And it's further trivialized by the fact that "smol" is part of a well-established lexicon of a large demographic. Eventually you'll see it in Merriam-Webster. But if the argument is "it must be in Merriam-Webster", that's textbook gatekeeping.
You can sometimes say something is objectively bad: You shouldn't name your class `Car` if it models a boat. It's unrelated.
However to argue about "small" vs "smol" is a matter of pedantry. And it's further trivialized by the fact that "smol" is part of a well-established lexicon of a large demographic. Eventually you'll see it in Merriam-Webster. But if the argument is "it must be in Merriam-Webster", that's textbook gatekeeping.
TIL I have a stick up my ass. I'm US born and didn't know what smol was until today so I'm not sure I buy the "large demographic", but it's always possible I'm out of touch.
Personally yeah I think it's better as an alias. I'm actually all for having fun with programming, but if you want your product to be useful you have to consider your audience. I'm much more likely to stick a joke name on an internal facing function, where I've got a strong reason to believe that everyone who sees it will be in on the joke. Or a piece of software that is itself for fun. Something that's meant for actually getting work done should generally not use naming that gets in the way of that.
> The notion of a "bad name" is evidence of aesthetic gatekeeping.
I mean that's objectively not true. You even provide an example in your next paragraph of a bad name. Another would be taking using md5s of descriptive names and using that. I mean md5 is broken and reversing it is fun and nerdy right?
When talking function names and program arguments, names which convey their purpose are better than those that don't. It's not gatekeeping, it's designing effective interfaces.
Personally yeah I think it's better as an alias. I'm actually all for having fun with programming, but if you want your product to be useful you have to consider your audience. I'm much more likely to stick a joke name on an internal facing function, where I've got a strong reason to believe that everyone who sees it will be in on the joke. Or a piece of software that is itself for fun. Something that's meant for actually getting work done should generally not use naming that gets in the way of that.
> The notion of a "bad name" is evidence of aesthetic gatekeeping.
I mean that's objectively not true. You even provide an example in your next paragraph of a bad name. Another would be taking using md5s of descriptive names and using that. I mean md5 is broken and reversing it is fun and nerdy right?
When talking function names and program arguments, names which convey their purpose are better than those that don't. It's not gatekeeping, it's designing effective interfaces.
Not knowing some internet slang doesn't mean there is a stick up your ass.
Having your own aesthetic preferences doesn't mean there is a stick up your ass.
But, if you were to claim, as others have, that this is an affront to programmer etiquette, that this product has a mandate to change it, then you might.
>> Something that's meant for actually getting work done should generally not use naming that gets in the way of that.
Like this. The case that "smol" is getting in the way of getting work done is just silly. No one is shoving their culture down your throat, but if you like Deno then you should be ready to also accept the culture established by its developers and not demand that one word be used over another of similar meaning, after it's established. There are other options out there for people who absolutely cannot be near and nonsense while working.
>> You even provide an example in your next paragraph of a bad name.
I established the difference between a pedantic situation and a genuinely unrelated name. This is nuance that most software developers are able to grasp.
>> When talking function names and program arguments, names which convey their purpose are better than those that don't. It's not gatekeeping, it's designing effective interfaces
`--smol` does this. It just happens to not be as well-known a word, but it is in fact an established part of the lexicon of an entire culture. That culture produced Deno, and being encouraging and accepting of these difference makes our little nerd corner of the internet just a bit cooler and more culturally diverse.
There is absolutely nothing from stopping anyone from joining the Deno collaborative process and creating a GitHub issue that requests a change. But if the maintainers find they prefer `smol`, it should end there and not become a constant struggle brought on by non-maintainers. And seeing as how it's been brought into the engine already, that is a sign that a consensus has already been reached at least once.
Having your own aesthetic preferences doesn't mean there is a stick up your ass.
But, if you were to claim, as others have, that this is an affront to programmer etiquette, that this product has a mandate to change it, then you might.
>> Something that's meant for actually getting work done should generally not use naming that gets in the way of that.
Like this. The case that "smol" is getting in the way of getting work done is just silly. No one is shoving their culture down your throat, but if you like Deno then you should be ready to also accept the culture established by its developers and not demand that one word be used over another of similar meaning, after it's established. There are other options out there for people who absolutely cannot be near and nonsense while working.
>> You even provide an example in your next paragraph of a bad name.
I established the difference between a pedantic situation and a genuinely unrelated name. This is nuance that most software developers are able to grasp.
>> When talking function names and program arguments, names which convey their purpose are better than those that don't. It's not gatekeeping, it's designing effective interfaces
`--smol` does this. It just happens to not be as well-known a word, but it is in fact an established part of the lexicon of an entire culture. That culture produced Deno, and being encouraging and accepting of these difference makes our little nerd corner of the internet just a bit cooler and more culturally diverse.
There is absolutely nothing from stopping anyone from joining the Deno collaborative process and creating a GitHub issue that requests a change. But if the maintainers find they prefer `smol`, it should end there and not become a constant struggle brought on by non-maintainers. And seeing as how it's been brought into the engine already, that is a sign that a consensus has already been reached at least once.
If weebs are in, then I am out. Consider this my final farewell. Mods don't even ban AYAYA anymore. 40 year old men thinking they are little anime girl. Thinking they are cuties
Why not? The audience is people who are deploying JS apps. Such people likely have access to the internet and are able to google "smol" if they want to know what it means. I'm not a first language speaker of English either, the system language on my phone is not English, if I google "smol" it immediately give me the translation into my system language. It takes no time at all.
Want to try again without a straw man?
Honestly, I havent been a nodejs dev for a long time.
However from the outside in, if an alternative runtime was to steal the show so to speak, then Bun looks like it might be able to do it.
- Full interoperability with the existing ecosystem
- Typescript and JSX as first class
- Blazing fast compile times
- Can serve a very large number of concurrent requests
- And a standard library that does as much as the go stdlib
Someone please tell me why this is a bad project, because so far I want to jump in.
However from the outside in, if an alternative runtime was to steal the show so to speak, then Bun looks like it might be able to do it.
- Full interoperability with the existing ecosystem
- Typescript and JSX as first class
- Blazing fast compile times
- Can serve a very large number of concurrent requests
- And a standard library that does as much as the go stdlib
Someone please tell me why this is a bad project, because so far I want to jump in.
You're reiterating Deno's feature list. Plus Deno's far more stable and works on Windows. So I'd suggest you go ahead and try Deno.
There's a big differentiator:
Bun is written in Zig while Deno is in Rust.
edit: I find this to be a big differentiator for those wanting to better understand how their tools work and hack/propose code changes when desired.
Bun is written in Zig while Deno is in Rust.
edit: I find this to be a big differentiator for those wanting to better understand how their tools work and hack/propose code changes when desired.
That's not a big differentiator.
Really hard to tell if this is sarcasm.
It's not bad, it's just still too early to "jump in", except to be an early adopter and perhaps one of the go-to experts when the bulk of the user developers come on board. The price for that is to always be prepared to refactor anything you build at this stage.
Bun is awesome. The only thing missing, for me at least, is streaming support (specifically for Server Sent Events [1]). Not sure if this release fixes it.
Nevertheless, have moved on to Go for servers so I don't really feel the need to go back to a Typescript/Javascript environment again. Rust is awesome for low level stuff. So quite happy with the combo of Go (for servers) and Rust (for everything else backend).
[1]: https://github.com/oven-sh/bun/issues/2443
Nevertheless, have moved on to Go for servers so I don't really feel the need to go back to a Typescript/Javascript environment again. Rust is awesome for low level stuff. So quite happy with the combo of Go (for servers) and Rust (for everything else backend).
[1]: https://github.com/oven-sh/bun/issues/2443
Full duplex streaming (which Deno supports) would be even nicer. Not yet part of the WHATWG Streams: https://github.com/whatwg/fetch/issues/1254
The worst part of Bun is the lack of compatibility with other Node stuff. I’d use it if it weren’t for my wish to use Prisma on my project.
Bun works with Prisma
https://elysiajs.com/blog/with-prisma.html
https://elysiajs.com/blog/with-prisma.html
I work on Bun. Happy to answer any questions
The inevitable question: what does Bun do that Deno doesn’t and vice versa? Competition is always good and I applaud it heavily. What is Bun’s killer feature over Deno and why would I pick Bun over Deno for a new project?
Personally, I like that Bun aims to be "Node, but better". That's all I ever wanted.
Deno's desire to rethink server-side JS adds friction in service of goals I don't value. They're gradually giving ground their aspirations (e.g., in my memory it was previously a point of pride to not interoperate with NPM), but it's still not a drop-in replacement and I don't think they want it to be.
Bun's goals align with mine, so it's the one I prefer using.
Deno's desire to rethink server-side JS adds friction in service of goals I don't value. They're gradually giving ground their aspirations (e.g., in my memory it was previously a point of pride to not interoperate with NPM), but it's still not a drop-in replacement and I don't think they want it to be.
Bun's goals align with mine, so it's the one I prefer using.
In a word: pragmatism. Bun is pragmatic where Deno is “by the book”. Node.js globals like process are Bun globals. You can use require() and import in the same file. Bun is faster, easier to use, and more compatible with the JavaScript ecosystem. There’s less new stuff to learn. And that also makes Bun easier to try in new and existing projects.
When will communications beyond the proprietary Discord be opened up to something FOSS & trustworthy for folks concerned about privacy or under sanctions?
There was a discussion in MermaidJS community to move away from Slack into Discord. But we were thinking about moving to a FOSS platform instead.
What are some viable options that communities have had success with?
What are some viable options that communities have had success with?
IRC is very low bandwidth & offers the minimal requirements for communication which can be accessible/acceptable for many projects. If something heavier is needed or wanted, XMPP MUCs & Matrix Spaces may be a good option since they are federated & decentralized (although Matrix has unfortunate defacto centralization around Matrix.org, because it requires quite a lot of resources to self-host in both the Python server as well as mirroring all content for all users for its take on federation). Mattermost & Zulip are fine, but require an account (I believe) to the central server but are FOSS & used enough places to be considered stable/trustworthy.
All options can by bridged to all other options (even the proprietary ones) in some manner, but if possible, the defacto server would be FOSS & owned/operated by the community so that that community can define their ToS and/or CoC. This way they are in control of the community rather than requiring users agree to someone else’s—especially a for-profit US corporation’s—terms in order to participate. Some users will want privacy, anonymity, control of personal data, or to get around a firewall/sanctions …and these desires should be considered acceptable. If not self-hosted (requires time/money), it’s still better to choose something using open protocols, like a space on Matrix.org, a big chatroom on XMPP’s Blabber/Conversations, Libera.Chat/OFTC, etc.
All options can by bridged to all other options (even the proprietary ones) in some manner, but if possible, the defacto server would be FOSS & owned/operated by the community so that that community can define their ToS and/or CoC. This way they are in control of the community rather than requiring users agree to someone else’s—especially a for-profit US corporation’s—terms in order to participate. Some users will want privacy, anonymity, control of personal data, or to get around a firewall/sanctions …and these desires should be considered acceptable. If not self-hosted (requires time/money), it’s still better to choose something using open protocols, like a space on Matrix.org, a big chatroom on XMPP’s Blabber/Conversations, Libera.Chat/OFTC, etc.
I'd second the recommendation for Zulip. It's pretty similar to Slack/Discord, but unlike those it has good support for making the archives public. It also has much better threading support, which is a nice bonus.
Self host Zulip, very easy, awesome integrations, etc.
Matrix is the way to go for FOSS.
It’s expensive to self-host, and centralized if using Matrix.org. It has its uses, but XMPP MUCs have a lot of overlapping features & Prosody/ejabbard can run on a potato by comparison.
It might be expensive for an organization to host, but for individual / small groups it can be as low as $6/mo. I've been running a small Matrix server on a DigitalOcean droplet for years now, and the $6/mo plan has been working fine for 5 users, and three bridges running on that server.
I believe all messages/multimedia from all users & the history all the rooms & private messages need to be mirrored which can end up being a lot even with a few users depending on what they’ve joined. If my understand is wrong tho, I’d like to know so I’m not running around with this notion.
No, you're right...that can be an issue. I had to configure my server to disallow large rooms and enforce some file size limits.
Mattermost is my favorite.
[deleted]
why are tech karens so hung up on forcing people use bad communications platforms just so its "FOSS"?
because commercial platform dies, the content vanishes.
because commercial platform decides to block searchbot indexing and once again content vanishes.
because commercial platform decides to block searchbot indexing and once again content vanishes.
Or commercial platform decides it doesn't want to deal with alternative clients and just bans people using them.
Or US sanctions tell the entity they’re no longer allowed to serve the clients in a particular country cutting off a chunk of the user base.
Or a user merely wishes to remain anonymous & that shouldn’t be a problem for them (provided they are acting in good faith).
Or a user merely wishes to remain anonymous & that shouldn’t be a problem for them (provided they are acting in good faith).
I know you took a lot of heat for tweeting about only hiring people who are willing to over-work. Do you regret that and is it still your policy?
I really like this project and will have to try it at work.
I'm a bit curious how the oven-sh will make money in the long term. It looks like you are getting funding at the minute, but at some point will users need to pay for this tooling?
I'm a bit curious how the oven-sh will make money in the long term. It looks like you are getting funding at the minute, but at some point will users need to pay for this tooling?
Just a guess: heroku-like hosting for js apps/backends with a focus on performance, using bun under the hood
They answer this on the website: https://oven.sh/
> Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps — and it will be powered by Bun.
> Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps — and it will be powered by Bun.
Indeed, same as how Deno plans to make money.
Does Bun have a built-in DOM Parser? In Nodejs it's horrendously slow using JSDOM and Linkedom is a great effort but still about 20x slower than a browser. Keep up the good work Jarred.
The closest thing we have builtin is HTMLRewriter, which is more of a tool for transforming HTML than for traversing.
I have looked a bunch of times at how hard it’d be to import the DOM APIs from WebKit/Safari and would really love to if it didn’t also mean pulling in most of a web browser
I think happy-dom is good for DOM-like testing though.
https://bun.sh/docs/test/dom
I have looked a bunch of times at how hard it’d be to import the DOM APIs from WebKit/Safari and would really love to if it didn’t also mean pulling in most of a web browser
I think happy-dom is good for DOM-like testing though.
https://bun.sh/docs/test/dom
Thanks HTMLRewriter actually fits my use case perfectly. I don't need canvas and complicated stuff like that. Just the ability to parse some html and strip out certain things.
Tried the latest version. Axios is broken. But that's an improvement from the last time I tried to run one of my backends. I'll keep an eye on your progress.
bun is awesome! thanks for all the work.
I haven't been able to swap nodejs our for bun yet.
how's the compatibility with web frameworks? when will nextjs 13 be supported?
how's the compatibility with web frameworks? when will nextjs 13 be supported?
Expecting SvelteKit & SolidStart end of next week. Maybe Next 13 in two weeks. A lot of frameworks work today in the release builds, it’s the dev servers which are harder for us right now.
What's left on the roadmap before Bun 1.0?
I wonder if Bun will end up being something that will eventually drive the innovation within Node.js, and maybe even merge with it (remember io.js?)
I can’t imagine a merge ever being on the cards. io.js was a fork of Node so merging it back in was a relatively simple proposition. Bun uses an entirely different JS engine so a merge would be horrendous, it would be more like a ground up rebuild.
I’m also still a little lost on the “why” of Bun. I respect the tech a ton having noodled around with the JavaScriptCore API myself in the past. But I’m not sure why I’d use it over Node.
I’m also still a little lost on the “why” of Bun. I respect the tech a ton having noodled around with the JavaScriptCore API myself in the past. But I’m not sure why I’d use it over Node.
Probably won’t merge because it’s a VC backed project
> and maybe even merge with it (remember io.js?)
Not likely. Bun doesn't use v8.
And if Bun has to go the way of NodeJs nothing will likely happen as well. Bun can move fast because there aren't as many stakeholders, committees and all sorts of gatekeepers in the way.
Not likely. Bun doesn't use v8.
And if Bun has to go the way of NodeJs nothing will likely happen as well. Bun can move fast because there aren't as many stakeholders, committees and all sorts of gatekeepers in the way.
Io.js was a fork of Node right. A merge is not on cards here.
i doubt it will get merged.
nodejs devs are firm on "this proposal is betteer kept in userland than within nodejs" approach, which also kept their ecosystem stable and predictable at most times.
nodejs devs are firm on "this proposal is betteer kept in userland than within nodejs" approach, which also kept their ecosystem stable and predictable at most times.
I don't think it will merge. After deno nodejs is getting similar features like native fetch, web stream etc. Similarly nodejs can just implement buns unique features
I hope so, whilst Bun isn't the fastest in this space it's definitely got potential to be if they can get some talented SWEs behind it.
Does anyone else think the logo looks more like an onion than a bun?
Looks like a bun (bao) to me.
I always saw it as a xiaolongbao specifically. Maybe that's my personal preference biasing me, though. (And now I'm hungry.)
That's exactly what it looks like [0].
With the face on it, I can't help but think of the Pixar short Bao: https://www.pixar.com/bao
[0] https://en.wikipedia.org/wiki/Xiaolongbao
With the face on it, I can't help but think of the Pixar short Bao: https://www.pixar.com/bao
[0] https://en.wikipedia.org/wiki/Xiaolongbao
The name always reminds me of this xkcd https://xkcd.com/1682 and this one https://xkcd.com/1871
Bun + RabbitMQ + BunnyCDN + Apache Jackrabbit for the Lagomorph stack.
Bun + RabbitMQ + BunnyCDN + Apache Jackrabbit for the Lagomorph stack.
Reminds me of khinkali.
https://en.wikipedia.org/wiki/Khinkali
https://en.wikipedia.org/wiki/Khinkali
Doesn't work on my system unfortunately (WSL 2)
LAPTOP-162NUQO7:~$ curl -fsSL https://bun.sh/install | bash
######################################################################## 100.0%
bun was installed successfully to ~/.bun/bin/bun
Manually add the directory to ~/.bashrc (or similar):
export BUN_INSTALL="$HOME/.bun"
export PATH="$BUN_INSTALL/bin:$PATH"
To get started, run:
bun --help
LAPTOP-162NUQO7:~$ ~/.bun/bin/bun
Error relocating /home/lewis/.bun/bin/bun: unsupported relocation type 37
Error relocating /home/lewis/.bun/bin/bun: unsupported relocation type 37
Error relocating /home/lewis/.bun/bin/bun: unsupported relocation type 37That’s an interesting error I haven’t seen before. Are you on the latest Linux kernel for WSL2? Is this WSL2 x64 or arm64?
Are you using musl by chance? Bun requires glibc 2.29+
Are you using musl by chance? Bun requires glibc 2.29+
Yes I'm using musl. Alpine Linux in WSL2.
All alpine users should already know this
https://wiki.alpinelinux.org/wiki/Running_glibc_programs
https://wiki.alpinelinux.org/wiki/Running_glibc_programs
Node.js works fine, the rustup script correctly determines I'm on a musl system and gives me the right binary.
Does anyone know why Bun (without --smol) sometimes uses much more memory than Node? Is this due to not being v1 yet?
I'm also wondering if some old benchmarks could now be irrelevant.
I'm also wondering if some old benchmarks could now be irrelevant.
The heap size grows faster & stays larger in the default configuration, adjusted for the amount of memory the computer has
We might enable —smol by default though.
The garbage collector configuration in JavaScriptCore is still kind of a mystery to me. I think we would ideally have something in-between —smol and default. I expect we will fiddle with this more shortly before or after 1.0
We might enable —smol by default though.
The garbage collector configuration in JavaScriptCore is still kind of a mystery to me. I think we would ideally have something in-between —smol and default. I expect we will fiddle with this more shortly before or after 1.0
OK thanks. Is that noted on the Bun site? Sounds like an FAQ.
Using more memory to increase performance is a good thing. All software should be doing it, especially one that is meant to run server-side. Who cares if Bun takes a couple hundred MBs extra (which is worth like $0.20)? It is also like 5-20x faster than Node for basic tasks because of it.
I don't know how different it is, but my guess is mostly that Node.js uses v8 and bun uses JavascriptCore.
[deleted]
Use v8 (node/deno) if JSC (bun) doesn't suit you
https://medium.com/walmartglobaltech/react-native-memory-pro...
https://medium.com/walmartglobaltech/react-native-memory-pro...
Am I misinterpreting or does it sound a bit arrogant as a response?
Yes, you are misinterpreting it.
Not having much luck running non-strict Node.JS classic scripts in Bun using CommonJS/require. Errors about strict mode despite not using "use strict";. Is there a flag to allow such scripts to run?
Try referencing `exports` or `module` in your code. That will automatically make it use CommonJS which doesn't have strict mode by default.
Bun internally treats most CJS modules as ESM, mapping require() calls to synchronous import() etc. And ESM is always strict mode, so that might be the issue?
AFAIK there are competing javascript runtimes including Bun, Deno, Rome, Node and other runtimes that I don't know about. So which one to use?
Rome is not a runtime and picking one depends on your use case and personal preference about certain features.
If you want to experiment with something new and fun pick bun or deno.
If you're looking to currently build a larger scale project with a few people that supports a lot of users, it's safer to go with nodejs/typescript.
If you're looking to currently build a larger scale project with a few people that supports a lot of users, it's safer to go with nodejs/typescript.
I don't see much deployment webapp story on the Edge/Lambda environment with Bun yet.
Check out the roadmap: https://github.com/oven-sh/bun/issues/159
Has anyone managed to get bun running with ChatGPT Code Interpreter?
I can get all the help text displaying but there's no output or error when running a JS file with the latest release (or even one from last year).
The latest Deno release works out the box with Code Interpreter. There might not be much benefit to running Bun over Deno but if like to try.
I can get all the help text displaying but there's no output or error when running a JS file with the latest release (or even one from last year).
The latest Deno release works out the box with Code Interpreter. There might not be much benefit to running Bun over Deno but if like to try.
It sounds like we aren’t flushing something at the right time. Can you file an issue?
Thanks. Reported here: https://github.com/oven-sh/bun/issues/3745
Update: the bug is likely due to Code Interpreter using a 4.4 kernel, which is 7 years old!
Update: the bug is likely due to Code Interpreter using a 4.4 kernel, which is 7 years old!
I don’t like binary lockfile. How do I know if something is properly resolved?
See the docs: https://bun.sh/docs/install/lockfile
> Why is it binary?
> In a word: Performance. Bun’s lockfile saves & loads incredibly quickly, and saves a lot more data than what is typically inside lockfiles.
> How do I inspect it?
> Run bun install -y to generate a Yarn-compatible yarn.lock (v1) that can be inspected more easily.
> Why is it binary?
> In a word: Performance. Bun’s lockfile saves & loads incredibly quickly, and saves a lot more data than what is typically inside lockfiles.
> How do I inspect it?
> Run bun install -y to generate a Yarn-compatible yarn.lock (v1) that can be inspected more easily.
I am excited for something other than v8 getting some attention. But at the same time I know over time it's gonna get bloated like Node.js
still no Windows
Going to https://github.com/oven-sh/bun
It seems bun is:
Zig 52.0%
C++ 19.2%
JavaScript 14.6%
TypeScript 12.1%
...
which is an interesting mix. I assume the JS is intended to be TS eventually or actually is right now. But why all the C++?
It seems bun is:
Zig 52.0%
C++ 19.2%
JavaScript 14.6%
TypeScript 12.1%
...
which is an interesting mix. I assume the JS is intended to be TS eventually or actually is right now. But why all the C++?
Many of the web APIs in Bun are generated code from WebKit/Safari, which uses C++. We copy them into Bun, comment out the web browser parts, and ship them in the runtime. This is great for web compatibility because it’s literally from a web browser
You forgot to say what it is.
They did say what it is:
> Bun is an incredibly fast JavaScript runtime, bundler, transpiler, and package manager — all in one.
> Bun is an incredibly fast JavaScript runtime, bundler, transpiler, and package manager — all in one.
No, it doesn't. This is the entire title: "Bun v0.7.0"
You’re conflating “title” with “summary”. They’re two different concepts.
I'm not conflating anything, and never mentioned a summary. I don't know if you're using a specialized application to view this site or something, but in a regular browser there's no summary. There's only the title, and this one neglects to say what the thing is.
My point was that you’re misunderstanding what a title is. If you want to understand more about something then you should click the link. Not complain that all the detail isn’t in the title.
It’s also worth noting that even their abridged description would be too long to use as the title string in HN. So what you’re asking for isn’t even possible on this forum.
It’s also worth noting that even their abridged description would be too long to use as the title string in HN. So what you’re asking for isn’t even possible on this forum.
I'm not misunderstanding anything. It's easy to put a short description in the title. To deny this is to promote making HN useless, since scanning its pages will tell you nothing and you would have no way to skip things you're not interested in.
Your assertion about the title is not correct, either. Try it. These titles fit into the limit:
"Bun v0.7.0: a fast JavaScript runtime, bundler, transpiler, package manager"
"Bun: an incredibly fast JavaScript runtime, bundler, transpiler, package manager"
It's time to stop silently putting up with useless titles, and WAY past time to stop attacking those of us who don't.
Your assertion about the title is not correct, either. Try it. These titles fit into the limit:
"Bun v0.7.0: a fast JavaScript runtime, bundler, transpiler, package manager"
"Bun: an incredibly fast JavaScript runtime, bundler, transpiler, package manager"
It's time to stop silently putting up with useless titles, and WAY past time to stop attacking those of us who don't.
It's literally the second sentence of the post. Why comment when you didn't even read it?
There is no second sentence. It says merely "Bun v0.7.0".
Is it only me that finds it strange that engineers working in a particular language will get another language to solve issues with said language? e.g. Javascript using C, C++, Zig, Rust, etc. Ruby and Python is also similar situation there are tools, libraries and such built in other languages
This is the way any interpreted language works, the interpreter has to be written in something and for good performance this has to be a compiled language
Usually. Pypy is a counterexample, with a JIT compiler written in Python: https://www.pypy.org/
It’s written in a very restricted variant of Python, rpython: https://rpython.readthedocs.io/en/latest/rpython.html
"RPython is a subset of Python2 that can be statically compiled. The PyPy interpreter is written mostly in RPython (with pieces in Python), while the RPython compiler is written in Python." - https://rpython.readthedocs.io/en/latest/getting-started.htm...
I don't think it's strange. A programming language should focus on a specific problem domain, and not try to solve problems outside that domain (not that Javascript is a particular good example of that philosophy though).
One could flip that question around: given there's all these fast C/C++/Fortran libraries, why do we have all these scripting languages?
The answer usually is there's a bunch of IO/parsing/configuration that we need to do, and doing that in a lower-level language isn't that much faster overall, is much less maintainable or accessible for users than wrapping in a scripting language, or simply avoids the need for recompiling each time you want to modify something (e.g. game engines with a high-level scripting component).
The answer usually is there's a bunch of IO/parsing/configuration that we need to do, and doing that in a lower-level language isn't that much faster overall, is much less maintainable or accessible for users than wrapping in a scripting language, or simply avoids the need for recompiling each time you want to modify something (e.g. game engines with a high-level scripting component).
Bun is not solving the language though. It uses JavaScriptCore, which is written in C/C++
It’s the same reason people will use Vue or React instead of writing their own frameworks for each and every website. Or why people target Windows or macOS instead of writing their applications to run on bare metal.
Abstractions are needed to simplify the problems of a particular stack.
If that weren’t the case then we would all still be punching machine code directly into computers.
Abstractions are needed to simplify the problems of a particular stack.
If that weren’t the case then we would all still be punching machine code directly into computers.
I find it strange to find that strange. Why wouldn't one leverage one language's strengths to address a shortcoming in another?
> bun --smol is a new CLI flag which configures the JavaScriptCore heap size to be smaller and grow slower, at a cost to runtime performance. This is useful for running Bun in memory-constrained environments.
From the example they gave (https://i.imgur.com/IDHTaAh.png):