Hi Jarred, I am curious about your insight into the source of Bun's performance advantage over Node.js. The Bun website[1] writes this:
Why is Bun fast?
... Zig's low-level control over memory and lack of hidden control flow makes it much simpler to write fast software. ...
Is your sense also that this is the root cause of Bun's outstanding speed? Node.js is written in C++ (although not primarily) which also requires low-level control over memory.
Is there something about C++ that makes it less well-suited than Zig for what Bun does?
Or is the problem with Node.js that it relies too much on JavaScript rather than C++ in hot paths?[2]
1) That benchmark appears to be bottlenecked by the HTTP client — that’s why the numbers are so close for each runtime. Effectively, it is benchmarking the http client and not the http server.
The benchmarking tool has to be at least as fast the server and it needs to support HTTP keep alive. That means popular Node.js-based benchmarking tools like autocannon don’t produce useful results in benchmarks like these
Instead, a tool like oha or wrk or bombardier is better
2) That benchmark is not using the ReactDOM server build for Bun's runtime, which is used in Bun's benchmark and is part of the next release of react-dom.
Like with any promising project, what are the downsides ?
How are you funded?
Is speed enough of a concern to take a risk on using this vs Node ?
From my experience with Node your lucky if it works at all, I don't know if I'd like to add another variable when things go wrong.
I can't imagine this supporting every single npm module.
That said, god speed. If you can really make JavaScript fast as a complied language, I and many other JS devs will be happy.
Bun and deno are in an arms race for nodejs compatibility in order to leverage node's vast ecosystem of libraries (think the "embrace" stage of embrace/extend/extinguish). This compatibility layer will take a long time... and will require early adopters to take more time to produce work which their nodejs counterparts can perform faster.
"Oven has raised $7m in funding led by Bucky at Kleiner Perkins with participation from Guillermo Rauch, YCombinator’s Continuity Fund and more." https://oven.sh/
>Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps — and it will be powered by Bun
Getting early funding is cool , but I'm not sold on the business model. Tons of hosting providers exist, corps are unlikely to switch meaning your stuck selling to hobbyist / small developers.
That said, they just need to stay alive until aquired
You should watch some of the interviews Jarred has given. Don't have any links, but searching "jarred sumner bun" on YT will bring some stuff up. His ideas for Bun are very different to a stock-standard hosting and he's thinking very long term.
Another thing is that he intends for Bun to be a drop-in replacement. Why •wouldn't* you switch hosting providers for a free massive boost in performance?
>Another thing is that he intends for Bun to be a drop-in replacement. Why •wouldn't* you switch hosting providers for a free massive boost in performance?
So I'm going to convince upper management to let me host our apps in a new unknown hosting provider vs the AWS contract we already likely have ? Maybe if your a CTO at a startup you could pitch this, but for the most part I'd imagine people will end up using Bun on existing hosts like AWS and Azure.
Nothing stops AWS from implementing whatever makes Bun hosting faster on their own platform. Don't get me wrong, I REALLY love Bun as an idea. I'm just not sure it'll make money.
I, too, have ADHD and (in remission) depression. I'm only partly joking too -- focusing on projects, work, hobbies etc. keep me sane and useful to those around me
Fully agree. Imo, it is up to everyone to find their own balance within their own lived experience. Maybe this Jarred person is doing what works in their own case, and I hope its working well.
Not a question, mostly a comment. Excited to see the crypto speed improvements. Makes me hopeful about projects like scikit.js[0] toppling Python's ML dominance
What scientist is going to want to write JS when they can choose Python?
I've worked with hundreds of scientists from different domains over the past two decades and I've literally never once heard of wanting to use Javascript for anything remotely scientific.
Furthermore, given that WebAssembly seems poised to (eventually) make strides in how browser-oriented applications are built then the logical conclusion is a sort of reduce function on languages where you choose the language that's the most pleasant to write and maintain since you will eventually be able to just target the browser from anything. For the life of me, I can't see a future where large, STEM-educated groups and agencies decide "Well yeah, I guess if we can use this cooked-in-a-weekend piece of $^&# then why would we ever use Python?"
I think a lot of language enthusiasts see python projects entering into spaces where it wasn't previously viable and think that the same principle applies to their language, which misses something fundamental about why Python has so deeply entrenched itself into the STEM/ML world, and why it will NEVER be uprooted. When I see things like Brython/Pyscript/Pyodide, it's obvious to me that people would rather write Python for ~accomplishing the task they set out to~ than have to muck around with another language entirely. Python is a winner in so many spaces because of that element of taking the programmer from Point A to Point B the easiest way. It's a language designed for accomplishing tasks, for getting stuff done, for being understood at a glance. Javascript was made up by one guy, in a very short period of time, for a singular purpose that it didn't even do well when it was introduced and has stuck around due to sheer coincidence and convenience. All languages on a long enough timescale converge to a point of usefulness but if we're pitting Python against JS I just can't see the scales tipping enough to warrant choosing it for real work.
Not JS, but I much prefer TS over Python. I've used all 3 pretty extensively for scientific work as well as webscraping
The thing is a lot of scientists are going to have to learn FE technologies eventually. The push to make scientific work more presentable and accessible means JS' place in academia is cemented for a long time.
WebAssembly is still a long way off and given that even Rust WASM was found to usually do worse than JS, I highly doubt Python WASM will outperform it any time soon. Even once it does become worth it, tooling has a long ways to go
> people would rather write Python for ~accomplishing the task they set out to~ than have to muck around with another language entirely.
your argument seems to boil down to: people know Python so they wanna use Python. People can just as easily know JS/TS. If I'm a botanist and I really don't wanna invest too much of my time in learning languages I can choose between Python, the language with all the scientific libraries, and JavaScript, the language of the web. If I choose the former, I'll likely have to bother someone to help me present my work to the web anyways. If in the near future JS also reaches good support for scientific/ml libraries it seems like entering that ecosystem is an obvious advantage. I get to learn the web and access scientific libraries at the same time
Also I don't really find Python all that legible. The language you're describing isn't Python nor JavaScript. It's something like Ruby. Modern javascript has some obvious advantages when it comes to syntactic sugar like arrow functions. It's also easier to teach because you don't need to install anything. Just open up your html file in any browser
> If in the near future JS also reaches good support for scientific/ml libraries it seems like entering that ecosystem is an obvious advantage
Fully agree with this sentiment. To that end, I’ve been contributing to Shumai (linked by someone else in the comments) to enable torch-like machine learning for Bun
Super exciting! I'd love to see Bun take a focus on this. Tbh with Deno's recent massive expansions to npm support it's kinda hard to see what role Bun plays in the ecosystem. Focusing on performance critical work like ML and crypto would cement it's place and fill a niche that's underserved. At least until WASM works as advertised but it seems that's kind of a ways off
The irony of this comment, given that there is precisely nothing about Python itself as a language that makes it particularly suitable for "anything remotely scientific", is thick enough to spread on toast.
I can see the validity of such an argument for languages like R or Matlab or Julia (EDIT: or Fortran), wherein the languages were designed with scientific use cases in mind. Python is not in that category; it's rather in the category of Perl (EDIT: and not Fortran): languages that happened to be useful to scientists by happenstance, and around which a library ecosystem developed in support of that usefulness. No fundamental reason why Javascript would somehow be ineligible if Python is eligible.
JavaScript has a very weak standard library. The language & standard library lacks essentials like structural equality, until 2015 or so very weak class-based object-oriented programming, and to this day has numerous footguns that are tricky to remove without breaking the web, like `==`, `this` scoping, and Array.prototype.sort() being in-place.
JavaScript is turning complete and I prefer it’s semantics to the lawless land of Perl, but it ultimately does not serve its users as a general purpose programming language for getting things done - it serves the web foremost, and as a distant second there’s specialized programming environments like Node and Bun with priorities like “asynchronous” that struggle with POSIX/system scripting basics like fork(2), execve(2), working with files in simple ways. Don’t even get me started on FFI/calling into dynamic libraries, which is the bread and butter of scientific computing. FFI is in the stdlib in Ruby; but requires writing or compiling C++ for Node, or a monstrous stack of compilers for the web.
JavaScript is interesting because there are so many healthy alternative runtimes, but when it comes to getting things done with data, both Python and Ruby are much more straightforward and prioritize developer happiness & utility, instead of standardized web compatibility.
> Don’t even get me started on FFI/calling into dynamic libraries, which is the bread and butter of scientific computing.
Which is, incidentally, one of the things Bun provides.
Like you said: there are indeed healthy alternative runtimes. Said runtimes can (and often do) readily provide a richer standard library, or break web compatibility to resolve footguns, or what have you. Bun seems to be making good progress to that effect, and my point in the previous comment presupposes that it succeeds.
I can see based on your perspective that you haven't collaborated with hundreds of STEM professionals, postdocs, or researchers.
I can also see that your comment fails to address the meat of mine, despite being a reply to it.
Python is extremely easy to get tasks done with, there's a minimal amount of ceremony and PLT background knowledge needed to program it. I love Perl, but explaining how $ and @ work differently given the point of usage is annoying, and if I taught Perl all day every day, it'd be a continuous annoyance.
I don't have the studies and data to back up my opinion, but a lifetime of work has taught me the certainty that Python is one of the greatest languages ever created, that quite literally ANYBODY who can type and read English can learn to become effective with it, and that it blows every competitor out of the water by a large margin with regards to getting from Point A to Point B as a novice programmer. As more of the world becomes programmers, that facet alone cements Python's continued success and its place in PLT history. It's the human part of the language, not the object system or type theory or compiler internals or any of the esoteric technical bits. Nobody can teach someone to program in anything other than Python quicker than I could teach them to program in Python.
But anyhow, this is well below my time to spend in a discussion like this. I mean this in the nicest way possible: I've probably spent more time teaching and training people who weren't programmers to write good programs then you've spent programming throughout your life. People who work in the White House, DARPA, the FDA, DOT, IRS, you name it. I know I can't PROVE my position, but time will. Python will always win eventually.
Honestly though, the original comment was just a plea for more competition to drive innovation it seems.
Most of the data scientists I've worked with are programmer hobbyists as well. We've used Javascript/Python/Go/R. Maybe this will exist for people in that demographic, those who are data scientists that already are solid in programming.
> I can see based on your perspective that you haven't collaborated with hundreds of STEM professionals, postdocs, or researchers.
Surely you know the saying about what happens when you ass-u-me.
But hey, if that's the tone you'd like to set, then I'm happy to oblige...
> I can also see that your comment fails to address the meat of mine
There was no meat to yours. "Python is good for scientific uses because reasons and JS is not because reasons; also, here are some cheap shots at JS being a weekend project despite there having been literal decades of work since Brendan Eich invented it". That's the sort of drivel I'd expect from novices using tribalism as a substitute for an informed opinion, not someone who claims to have sufficient expertise in programming to competently educate someone else.
> I love Perl, but explaining how $ and @ work differently given the point of usage is annoying, and if I taught Perl all day every day, it'd be a continuous annoyance.
Explaining to beginners why their programs break if they don't get indentation perfectly right strikes me as no less of a continuous annoyance.
On that note, Ruby lacks either of those issues. Same with Lua. Same with Javascript.
> ANYBODY who can type and read English can learn to become effective with it
That's true of pretty much every scripting language out there; that's indeed what usually sets scripting languages apart from systems languages.
> it blows every competitor out of the water by a large margin with regards to getting from Point A to Point B as a novice programmer
Not every competitor. It's one of a category of languages which novices in significant numbers successfully learn reasonably quickly - and significant numbers of novices do become successful with Ruby or Lua or - yes - JS just as quickly as novices do with Python.
> I mean this in the nicest way possible: I've probably spent more time teaching and training people who weren't programmers to write good programs then you've spent programming throughout your life.
I mean this in the nicest way possible: if your comments here are representative of your teaching and training of others, then you owe your students refunds and apologies. I would hope that you don't teach your students blatant misinformation like JS being merely a weekend project (as if Python wasn't?) or fanboyishly insist that "Python will always win eventually" as if programming is all about winners and losers rather than using the right tool for the job. If you do teach your students such, then they are worse off for it, and deserve someone who actually educates rather than misinforms.
If you're as good a teacher as you claim to be, then the language doesn't matter; the differences between the various scripting languages out there are minute in comparison to the fundamental concepts like "how do I write and call functions?" or "how do I store data and use it later?".
Likewise, to your average non-programmer, the language doesn't matter. What matters is the path of least resistance between "I need to do this thing" and "I have done this thing". Sometimes that's Python. Sometimes that's JS. Hell, sometimes that's something totally bonkers like Haskell. Python is one of several paths of least resistance for scientists in particular not because of anything to do with the language itself, but rather because of a library and tooling ecosystem that formed around it by happenstance; no reason why that couldn't happen for JS, or any other scripting language.
> Hell, sometimes that's something totally bonkers like Haskell.
This literally happened to me the other month. I had a tiny problem which I realised was a perfect fit for the List monad. Guess which language has the best support for that?
I rewrote my little script in JS afterwards using flatMap, and it was much uglier.
I don't know what scientific hole this peg fits into, but it might make more sense to run something in the browser than on the backend (scalability).
Instead of using a wasm runtime for python for that it might also make more sense performance-wise to at least write that part in js if not an even faster language compiled to wasm. Either way if it ends up on a webpage some js will be needed to at least glue things together.
Also, from the perspective of just wanting to write some code and get what I want, I really don't see much of a difference between python and js.
For the rest of us, it's kinda the other way around. We can't figure out why scientists prefer python over all the other many options. I'm assuming it's just a lot of cobbled together legacy code nobody wants to breathe on.
> Furthermore, given that WebAssembly seems poised to (eventually) make strides in how browser-oriented applications are built
Also, this isn't really true. The proposals and implementations out there suggest the goal is to use wasm for libraries and specialized optimizations. Nobody wants to wait for a massive binary to download. You can try to port legacy junk apps, but making it usable on the web (not a canvas) might turn out to be more work than it's worth in many cases.
Scientific performance critical code isn't written in Python, it is written in C/C++ which is used by Python. Python in ML usually merely describes the calculation not unlike React describes the DOM that should be displayed in the browser.
JavaScript was never really known for admin or file manipulation (Perl replacement), so that was what probably established the dominant ecosystem for Python. I also don't think the runtime overhead is applicable due to native C/C++ part, and download time doesn't have to be bad since modules can be split just like in JavaScript ecosystem today. For an AI app, the model inference weights might be larger than the compiled WASM code itself. However, I'd agree with you that porting legacy apps might not be possible without something close to a rewrite.
There is a reasonable chance that once WASM GC is implemented, then direct DOM access will be provided [1], which I believe could pretty much halt interest in new JavaScript development for web frameworks overnight. WASM is the reincarnation of the Java Applet, but better. And a more typed language like Go or Dart could become the most widely used programming language. Either compile it to WASM as plugin for something like the browser, compile to JavaScript for "legacy browsers", or to native code for a standalone app. There are probably a handful of developers already assuming this and trying to write a version of React running in WASM already.
JavaScript has a massive and unrivaled ecosystem outside of core data analysis. The main hurdle to adoption is ecosystem and community. A generation of applied mathematicians and data scientists were trained on Python. Python overcame older ecosystems like Matlab and Fortran for its ease of use for other general computing tasks (Matlab is a decent language for large array manipulation but soft tasks like string processing are kludgy compared to Python).
In the same way that Python developers are interested in extending their ecosystem to other spaces, JavaScript developers are interested in growing into the data science space. But that doesn't happen unless there's a clear benefit for switching.
What advantages do a native JS solution have over Python? Performance: There are arguably many more developers and companies focused on pure JS performance than python. Community: A JS solution opens up a much larger pool of talent to build innovative solutions. Cost: Running heavy computations client-side, in the web browser, reduces costs for service providers.
Performance where, exactly? Most Python data munging I've seen just punts it all to C based libraries anyways. Are people doing things in pure python these days?
Under the hood, numpy and friends punt to native code. FFI / native module performance becomes a bottleneck, and Bun is correctly focusing in this area. Shumai [1] is a cool library for Bun that also punts to native code
Given your extremely outsized reply I can tell this is something you feel passionately about or whatever, but the “JS was built in x days” line is a thought-terminating cheap shot. It doesn’t acknowledge the vast amounts of work that have gone into subsequent ES versions. The JS that a typical remotely-modern-tech-stack developer is writing these days is not the JS that you’re belligerently referring to.
I’ve got honestly no idea how long it took to write the first ‘version’ of the Python interpreter or whatever. It’s not as much a piece of tech lore that was later (mis)appropriated for Internet arguments. Even after acknowledging that JS being a browser-based language causes let’s say ‘less well-considered’ language quirks to hang around for longer than we’d like, I’d never use that as such a central argument.
To be clear: in my day job I predominantly write Python. It’s a web project, which I have control over the architecture of, and it’s for the most part oldschool server-side rendered Django views, in no small part because JavaScript scares me. I am FAR from a fanboy. Having recently spent a solid month writing TypeScript - which for contexts like this should be considered ‘JavaScript’ - it’s (way too late) become clear to me that it’s a language worthy of respect and consideration.
If we want to get into the comparative qualities of JS you dislike, well, I still don’t think I’d be interested in a language wars back and forth. However at least we’d be getting closer to a productive conversation. And, to be clear, I’m not jumping to take up arms arguing that JavaScript is as suitable for ML/scientific computing as Python is. Even if we pretend that e.g. pandas and numpy were available for JS, I’m still not confident that JS is up to the task, but I also don’t feel confident arguing against it either.
What I will say is that, coming back to writing Python after being deep in JS for just a little while, there are JS language features that I felt myself missing. Just like there are Python language features I felt myself missing in JS. My point is, again, that modern JS is in my eyes within the realm of respectable general purpose language, ESPECIALLY with TS.
> What I will say is that, coming back to writing Python after being deep in JS for just a little while, there are JS language features that I felt myself missing. Just like there are Python language features I felt myself missing in JS
I relate to this a lot. If I've been doing Python a lot, JS can feel clunky. If I've been doing JS/TS a lot, Python feels clunky. I think TS tips the scales here for me though
The only language that I really feel is actually really elegant and readable and lives up to the "get stuff done" mantra in a way that goes beyond "this is what I know already" is Ruby
Let's say you want to a small notebook in the browser, JavaScript is nicer there, even with WebAssembly. Or the user is not a scientist, and already knows JS, and it lets them discover ML. It's not taking anything away from those Python projects.
> What scientist is going to want to write JS when they can choose Python?
One who has a reason to?
All languages have their strengths and weaknesses. Popular languages have a positive balance. JS is great for the web, and there's surely >0 applications in science that require web interoperability...
The statement "mucking around with learning another language entirely", comes across as someone who hasn't experienced other languages to the point they see they often have more similarities than differences, become easier and easier to learn as a result, and are best used - at that point - like a box of tools, rather than the situation most programmers start with of using a screwdriver for everything because it's all they have.
This is where more than a few scientists seem to have got stuck with Python, and possibly part of why the language itself has accelerated into becoming a bit of a mess - though they often do, anyway. (So much for that "just getting from A to B" thing, I hope it sticks around, but it's not looking good.)
While many might not presently be in a position to, any scientist who could choose to use something more readily suited to a particular use-case, such as JS, or C, or Perl/Ruby, or Elixir (particularly with regard to ML lately), may find themselves reaching higher heights than they could have when limited to only Python.
As with anything, those with more options have an edge over those with fewer.
Python is great and ergonomic for interactive fiddling.
But the scientific strength of "Python" comes not from Python itself. It just offers a nice interface to tons of C, C++, and Fortran code that implement the core of numpy, pandas, keras, pytorch, etc. That's what STEM and ML crowds use. Moving that code to WASM must be possible, but likely for demo purposes, not for serious work.
Jarred didn't port esbuild, his vision/ambition is far beyond that for bun.
But even as a transpiler, Jarred made different decisions about the compilation process. Also time doesn't really mean the same thing, this brosef works 80hrs/week on this stuff, and he's been doing that for over a year.
He chose Zig because it's a good language for performance sensitive applications and found himself to be very productive in it.
What's the most challenging thing you had while working on the project so far? It seems like the project has a pretty complex goal, so I wonder what things were the more difficult ones for you
Hi, why use a language (Zig) that is not yet ready for production? Even Andrew himself has stated that the standard library is not ready until v1. As of writing, the current release is 0.10.1.
We will eventually have a builtin Postgres client, but Postgres.js is also a great choice. I started to work on a `bun:sql` module, but ran out of time for now.
Hosting is the obvious answer. Deno is monetizing in the same exact way (https://deno.com/deploy/pricing) and they managed to raise much more money with the same playbook.
Not yet. MongoDB requires resolving SRV dns records and we haven't implemented support for that yet (just A/AAAA via getaddrinfo()-like APIs currently)
Not yet, we haven't released our docs site yet either. Probably won't be there in the first release of our docs, but this is something we should do
If you're familiar with Node, Bun should feel familiar except you don't need as much tooling to use it.
Things like TypeScript, jsx, loading .env files, Jest-like test runner etc just work. You can use the builtin TypeScript/JS LSP in your text editor instead of installing a separate extension. You can import packages from npm without the "npm:" specifier. It's worth mentioning that Bun doesn't support HTTPS imports yet, so you'll need to use npm - but bun has a very fast builtin npm client. Like deno, you can often skip running `bun install` or `npm install` entirely for bun because bun will automatically install dependencies from npm when there is no node_modules folder
Will Bun ever open up to non-proprietary communications? Since inception, there has only been Discord (and I suppose GitHub issues, but that's also proprietary). There is a whole host of reason from FOSS philosophy, to privacy/security, to moderation to not be locked into such a platform. Will future Bun include a IRC server/room on an existing platform like Liberal.Chat, a Matrix server/room, an XMPP server/room, Zulip, RocketChat, or Discourse?
Yeah, come on and label at least one unofficial, FOSS, non-corporate-owned option for users. Discord will be the next Slack; folks will want out after the hype dies down and more interest in protecting one's person data continues to rise.
Their reasoning is explained in the issue you linked.
IMO this sounds like a YAGNI thing. You can pass extra information via the URL, query parameters, cookies work just like normal HTTP, etc... And if those options don't work you can just exchange whatever information you want inside the websocket connection. I can't think of a use case that requires a custom header.
I'm working on a project with websockets and I hate working around unsupported headers. biggest problem is passing json web tokens, requiring us to have short lived cookies just for authenticating. Yes, we can always "just exchange information" but this requires custom, non-standard logic, for such a ubiquitous use case.
dgram & UDP sockets will happen, though honestly probably not until v0.7
We’ll likely do AsyncLocalStorage and make the rest of async_hooks a no-op. async_hooks are detrimental to event loop performance, but important for observability tooling. I think a better approach here is designing a more specific API for the top usecases
if you're leaving this kind of comment on a v0.5 project you may need to reevaluate how you present to a forum for early adopters. "ignore new things until they have some traction" comes off very dismissive.
We spend an absurd amount of time profiling, benchmarking, and making stuff run fast in Bun
Most of Bun is written in native code (zig) rather than JavaScript. We leverage modern CPU features like SIMD, closely watch syscall overhead and spend a lot of time reading about system calls and platform-specific system APIs
Bun is still pretty early - we are not at 1.0 yet. There are crashes and many bugs to fix, but we are making steady progress towards a stable release
I think the main difference is that while Node and Deno embed Chrome's V8 engine, Bun embed's Apple's JavaScriptCore. Bun also uses "a new JavaScript parser based on esbuild’s JavaScript parser but ported to Zig"
However, it's worth noting that those benchmarks have been critized a lot for being cherry-picked and not very representative of real-world use-cases
I've tried to look it up a number of times but I've yet to come across any benchmarks done by an independent party (please share if you find some)
I'd complain about them and I don't work on either of those projects.
But I have worked _with_ node for a very long time, and I am intensely familiar with the JS ecosystem's "flavour of the day" culture.
I think people are rightfully suspicious of such bold claims. Particularly as Deno came out to much fanfare and self promotion but like...I barely hear of anyone actually using it in production as opposed to node.
Not saying that node will be King forever, just that I'm taking a grain of salt.
Agreed! Just noting that there's conflict of interests all around the place, not just on one side.
What seems clear though is that Bun/Jarred really care about performance, since it's a big part of the tweeting/public communication. Maybe the tests are not the best from a real-world comparison, but the fact that he's constantly trying to make every small thing high performance would suggest that performance IS important for Bun. So people might disagree on "how much better", but I'd not be surprised at all if a system built from the ground up with a big focus on performance is faster than the competition.
In my general experience, JSC is 20-50% faster in a lot of things, but uses about 2x the memory. I'm not sure how much of that is memory/speed tradeoff, but I suspect a lot of it is "we spent our budget on fast and skipped working on a better garbage collector".
It's probably a decent tradeoff in a lot of applications, but probably not in all of them.
The memory usage difference you're seeing is likely a GC scheduling issue in Bun (not a JS engine thing)
Bun isn't scheduling the garbage collector between microtask ticks and we might need to start doing that to reduce memory usage. We did that in Bun v0.3 for the event loop, but we didn't do it for the microtask queue.
Sounds like a common tradeoff just theoretically. Usually you can cache more things to increase speed aka increase space complexity to reduce time complexity. I don't think it's necessarily a sign that Apple skimped out on something but rather made a design decision
But you bring up a good point and I'd like to see a more holistic benchmark that takes both space and time complexity into account (preferably done by an independent party)
v8 is compacting while JSC is not. I think it's telling that v8 released a new GC in 2018 to massively improve their GC performance while in 2019 JSC redid their bytecode and execution engine to radically improve execution performance.
There's limited resources on each team and I suspect the biggest difference here is differing priorities for those resources. There's not many third-party comparisons, but here's two.
Wow thanks for the links. The first one had a good comparison but only compared Bun and Node. However it's pretty telling that Bun's margins aren't nearly as significant as they are in the benchmarks being paraded around. Also seems like you're right about Bun using more memory to achieve faster speed
Edit: That same blog also did a comparison of Bun and Deno directly. Looks like Deno usually outperformed Bun pretty significantly:
I'm not saying you're wrong, but I'm having trouble squaring this analysis with Chrome's notoriously high memory usage compared to Safari. What's gunking up Chrome if not V8's memory needs?
The bulk of the browser's memory usage is the rendering engine and surrounding stuff rather than the JS on the page.
v8 has a compacting GC[0] while JSC does not[1]. This was the result of the v8 team taking out a bunch of time to write a new GC that was released in 2018 (Orinoco).
Here's a comparison of a simple job. With lots of concurrency, Bun is 20-30% faster, but uses 60% more memory.
> Here's a comparison of a simple job. With lots of concurrency, Bun is 20-30% faster, but uses 60% more memory.
That benchmark is out of date. In Bun v0.3, memory usage in situations like that dropped by 4x - https://bun.sh/blog/bun-v0.3.0, meaning it uses around half as much memory as Node.
Prior to Bun v0.3, Bun wasn't scheduling the garbage collector in conjunction with the event loop and that led to memory not being reclaimed correctly on idle
Jarred is approaching this from a fundamentally performance (due to targeting of Edge runtime) and DX perspective. If you follow his twitter or bun discord, you can see he spends an enormous amount of time studying, profiling, and tweaking features so he can squeeze as much performance out of it as he can.
I would ask the other way ... why use Bun if the other products are mature and good enough? I've seen Node forked (to Deno I think) and then eventually they merged it back.
Seeing the perf benchmarks for `vite build` with and without bun will be the ultimate practical test of bun for me, excited for the next release where we'll hopefully see that support.
Awesome to see workspaces get some love, but kinda odd they shipped it without support for globs. Guess I'll keep waiting to try it out on my projects.
We'll add glob support in v0.6. We didn't include it because we need to implement a glob matcher in native code and we needed to descope some stuff because it was already a little more than 3 weeks since the last release
The problem is that Bun currently treats every file as an ESM module, which means everything uses strict mode but Node-RED relies on sloppy mode features like implicit global variables (if you omit "var", "let", or "const" in sloppy mode, variables are assigned to globalThis). Many of the other things with sloppy mode are handled by Bun's builtin transpiler (such as legacy octal literals), but this one is harder to do
Yes, I figured it would be something like that. I don’t have the bandwidth to even attempt to clean that up and submit a PR to Node-RED (I have no clue as to how many files I’d need to wade through, only hacked red.js a little to figure out what was going on), but it is something I rely on and where moving away from NodeJS would be beneficial - besides being a great showcase for performance improvements.
I see Oven (creator's of Bun) are hiring. I imagine the pool of javascript developers that they could hire from is tiny. Add in Zig and it's even smaller.
It's a different criteria, not necessary a plus. It's domain knowledge based hiring, knowing Zig can be worse than not knowing Zig but with experience of writing low level stuff (especially things from scratch requires protocols implementation experience)
I wish I could support Bun but I honestly can't ethically support someone who explicitly wants to hire people to work insane hours, and has right-wing billionaire bootlicker tendencies.
I mean he's a Thiel Fellow, which should give you an idea of what I'm talking about.
why is this project constantly benchmarking against deno and node? it seems to attract good attention this way but I wonder what else it offers besides performance.
