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 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] https://bun.sh/
https://medium.com/deno-the-complete-reference/node-js-vs-de...
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.
Different strokes for different folks
Some people really enjoy working. I know, it's hard to believe :)
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.
I'm curious to hear your thoughts about Bun/Civet integration to explore improvements to the language frontend as well as the language backend?
1) using JavaScriptCore instead of V8
2) porting esbuild from Go to Zig
I have a couple of questions about (2):
1. How long did it take you to port esbuild?
2. Why did you choose to port esbuild to Zig instead of another language e.g. V?
He chose Zig because it's a good language for performance sensitive applications and found himself to be very productive in it.
And thanks for bun! It's been impressive and inspiring to watch.
For now you can do
bunx bun-repl- zig.news has some good posts https://zig.news/
- Zig's language docs: https://ziglang.org/documentation/master/
- Zig's standard library code https://github.com/ziglang/zig/
I mean, I wish bun all the best, but trying to wrap my head around - who the heck and on what basis gave to bun project a money :-)
Tracking issue: https://github.com/oven-sh/bun/issues/1822
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
Why would anybody not use Bun, other than the cost of migration, given the performance improvement?
Nevertheless, amazing performance. Feels refreshing to see more improvements to the JS/TS community.
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
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)
It's probably a decent tradeoff in a lot of applications, but probably not in all of them.
From another comment:
Reasons not to use bun:
- it is pre v1, so unstable API
- it is unstable, so you will deal with crashes
- newer, so help articles will be hard to find
You're thinking of the io.js debacle
Is Bun ready to be used for production projects?
Bun is not a JavaScript bundler, it’s a JavaScript runtime, like NodeJS or Firefox.
You can (could, theoretically) run webpack with bun instead of node
Incidentally, what's up with the resistance against this from the standards maintainers? [1]
The request exists since 2017, there are tons of use cases and developer interest, but Chrome refuses implementation on technicalities. What gives?
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.
Would leveraging `async_hooks` be possible in the future with the used non-v8 engine or would there be some alternative?
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
Really appreciate the pragmatic approach!
(Instead of being dogmatic like "we just can't/won't deliver async_hooks unless its exactly right", so then it never happens.)
https://github.com/oven-sh/bun/releases/expanded_assets/bun-...
it's worth revisiting though since its been a little while
If bun can crack executable generation (along with code signing and notarization), it’ll unlock a whole new dimension for bun apps.
i mean, i don’t know how many people even use deno, let alone bun.
I mean he's a Thiel Fellow, which should give you an idea of what I'm talking about.