13 ms·

Bun v0.5

330 points by cyclecity 4y ago

mmmeff 4y ago
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.
- Jarred 4y ago
  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
  - lhnz 4y ago
    You might be interested in @devongovett's `glob_match` library (written in Rust): https://github.com/devongovett/glob-match https://github.com/devongovett/glob-match
    - sebdufbeau 4y ago
      Seems to already be on his radar: https://twitter.com/jarredsumner/status/1615071897859018753 https://twitter.com/jarredsumner/status/1615071897859018753
Jarred 4y ago
I work on Bun. Happy to answer any questions or feedback
- junon 4y ago
  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.
- ptrwis 4y ago
  Do you plan to support http3 in the (near) future?
- christkv 4y ago
  Is it possible to connect to Mongodb yet?
  - Jarred 4y ago
    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) Tracking issue: https://github.com/oven-sh/bun/issues/1822 https://github.com/oven-sh/bun/issues/1822
    - christkv 4y ago
      Awesome thanks for answering it.
- edvards 4y ago
  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
- Thaxll 4y ago
  What was the decision making of chosing Zig for Bun, a very promising but immature language?
  - Jarred 4y ago
    Zig is great for writing fast software and I’m really productive in Zig.
    - thayne 4y ago
      Are you worried about breaking changes in zig requiring large changes in bun, or getting stuck on an old version of zig?
- mattlondon 4y ago
  Is there a migration guide for Deno users?
  - MuffinFlavored 4y ago
    do you think it might be too “living on the cutting edge” to adopt this yet?
  - Jarred 4y ago
    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
- culi 4y ago
  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 [0] https://scikitjs.org/ https://scikitjs.org/
  - adenozine 4y ago
    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.
    - sublinear 4y ago
      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.
- rmorey 4y ago
  What are some good resources to learn zig?
  - Jarred 4y ago
    - Ziglings is great - https://github.com/ratfactor/ziglings https://github.com/ratfactor/ziglings - zig.news has some good posts https://zig.news/ https://zig.news/ - Zig's language docs: https://ziglang.org/documentation/master/ https://ziglang.org/documentation/master/ - Zig's standard library code https://github.com/ziglang/zig/ https://github.com/ziglang/zig/
- danielEM 4y ago
  Out of curiosity - how do bun plan on monetization? Is that even possible in the age of node.js, deno and who knows what else? :-) 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 :-)
  - TAForObvReasons 4y ago
    Hosting is the obvious answer. Deno is monetizing in the same exact way (https://deno.com/deploy/pricing https://deno.com/deploy/pricing) and they managed to raise much more money with the same playbook.
- danielEM 4y ago
  And a side note, before got to this thread was looking into bun code and saw your commits, you're very productive man, congrats!
- detrites 4y ago
  Are there any plans for a REPL? And thanks for bun! It's been impressive and inspiring to watch.
  - Jarred 4y ago
    This is something we need to do, but haven't prioritized yet For now you can do bunx bun-repl
- tiffanyh 4y ago
  Any plans to collaborate with just-js?
- Yahivin 4y ago
  Civet just added a bun loader https://github.com/DanielXMoore/Civet/blob/main/source/bun-civet.coffee https://github.com/DanielXMoore/Civet/blob/main/source/bun-c... I'm curious to hear your thoughts about Bun/Civet integration to explore improvements to the language frontend as well as the language backend?
- deworms 4y ago
  [dead]
- henry_viii 4y ago
  A couple of reasons that contribute to Bun's performance are: 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?
  - kamikaz1k 4y ago
    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.
- leidenfrost 4y ago
  How far is Bun to run a NestJS project? (Leaving adapters like Mongo aside)
- ushakov 4y ago
  I have a question. Does Jarred ever have a vacation? Really concerning to see how much you work lately. Wishing you a more relaxed time
  - forrest2 4y ago
    I don't wanna speak for them, but for some people, going in deep on something is the only way to stay healthy / happy / sane. Different strokes for different folks
    - aarpmcgee 4y ago
      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.
    - girvo 4y ago
      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
  - Jarred 4y ago
    I love working on Bun and find it very energizing
  - vcryan 4y ago
    Somehow being coerced to work long hours had been conflated with choosing to work long hours. Some people really enjoy working. I know, it's hard to believe :)
- 999900000999 4y ago
  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.
  - swyx 4y ago
    "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/ https://oven.sh/
    - okhuman 4y ago
      One downside: core devs only prioritize bun features which can enable use cases for running your code in their edge/hosted platform. Missing some of the other general purpose use cases that devs would want to build - which wouldn't fit into bun's flavor of hosting.
    - 999900000999 4y ago
      >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
      - ZephyrBlu 4y ago
        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?
- jonasb 4y ago
  Will Postgres.js be the way to go for using Postgres, or do you expect to build a custom Postgres client library?
  - Jarred 4y ago
    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.
    - jonasb 4y ago
      Great, thanks! I'll start with Postgres.js then.
- 2h 4y ago
  [flagged]
- nequo 4y ago
  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] https://bun.sh/ https://bun.sh/ [2] https://github.com/nodejs/node https://github.com/nodejs/node
  - hiccuphippo 4y ago
    He has an answer in this talk around the 11:30 mark: https://youtu.be/eF48Ar-JjT8&t=690 https://youtu.be/eF48Ar-JjT8&t=690
  - nonethewiser 4y ago
    This is a great question, hope he answers.
  - culi 4y ago
    Those benchmarks may not actually hold up to independent analysis: https://medium.com/deno-the-complete-reference/node-js-vs-deno-vs-bun-server-side-rendering-performance-comparison-f80a5abc766f https://medium.com/deno-the-complete-reference/node-js-vs-de...
    - Jarred 4y ago
      Two things about the linked benchmark: 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. PR: https://github.com/facebook/react/pull/25597#issuecomment-1302816780 https://github.com/facebook/react/pull/25597#issuecomment-13... Source of Bun's homepage benchmark: https://github.com/oven-sh/bun/blob/9ef33312b1b199931c29c182c4bc3984a944bb9a/bench/react-hello-world/react-hello-world.jsx#L1-L7 https://github.com/oven-sh/bun/blob/9ef33312b1b199931c29c182...
- toastal 4y ago
  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?
  - thatoneguytoo 4y ago
    C'mon dude.
    - toastal 4y ago
      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.
  - icemelt8 4y ago
    haha
- aitchnyu 4y ago
  Whats the plan for wasm build? We are using quickjs-emscripten for running sandboxed scripts and we would love top level async and crypto.
maherbeg 4y ago
Is there a roadmap to getting to a 1.0 stable release?
1vuio0pswjnm7 4y ago
Please add musl build here: https://github.com/oven-sh/bun/releases/expanded_assets/bun-v0.4.0 https://github.com/oven-sh/bun/releases/expanded_assets/bun-...
- Jarred 4y ago
  The last time I looked into adding musl support, there were some difficult to narrow down crashes in bun's linux aarch64 build it's worth revisiting though since its been a little while
muhammadusman 4y ago
As is with all things in the JS world, I usually ignore new things until they have some traction. Is Bun ready to be used for production projects?
- wetpaws 4y ago
  Ahaha no
- swyx 4y ago
  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.
  - skerit 4y ago
    I see no problem in someone asking a simple question like this. I've seen far more dismissive posts here anyway
Alifatisk 4y ago
Makes me happy seeing newer alternatives to Node, it’s exciting!
thiago_fm 4y ago
Anybody care to explain on how it achieve such numbers in comparison to node and deno? 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.
- EGreg 4y ago
  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.
  - klohto 4y ago
    Node forked to Deno? And merged... back? What are you talking about?
  - zdragnar 4y ago
    You might be thinking of io.js, which was a fork almost entirely due to politics. The advisory board came out of it, and a push for semver, but it started here: https://github.com/joyent/libuv/commit/804d40ee14dc0f82c482dcc8d1c41c14333fcb48 https://github.com/joyent/libuv/commit/804d40ee14dc0f82c482d...
  - ramesh31 4y ago
    >I've seen Node forked (to Deno I think) and then eventually they merged it back. You're thinking of the io.js debacle
- kamikaz1k 4y ago
  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. 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
- 4y ago
pictur 4y ago
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.
- francislavoie 4y ago
  Because it's positioning itself as a faster, leaner, modern drop-in replacement for Node.
- vexna 4y ago
  Because its for running server side javascript, just like node/deno. It would make sense to compare itself to its competition.
- kamikaz1k 4y ago
  what else would you see it compared to?
  - davesnx 4y ago
    versus other than JavaScript stuff: Java, C++, OCaml or Go
    - francislavoie 4y ago
      But why? It's a JS runtime. Obviously you'll compare yourself to the other competing JS runtimes.
- intelVISA 4y ago
  easy targets I would guess
wdb 4y ago
Starting to look promising. Work projects not working yet due to the need of `dgram` and `async_hooks`. Would leveraging `async_hooks` be possible in the future with the used non-v8 engine or would there be some alternative?
- Jarred 4y ago
  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
  - stephen 4y ago
    Amazing. Getting just AsyncLocalStorage and the rest of async_hooks later / or not all would be great, as that's currently blocking us from bun. 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.)
gmaster1440 4y ago
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.
viksit 4y ago
as a newbie to bun, is there a reason to use it beyond it being an alt to node/deno? i mean, i don’t know how many people even use deno, let alone bun.
msoad 4y ago
Does Bun also generate standalone executables? I'm interested in using it for CLI apps.
- httgp 4y ago
  This will be a killer feature. One of the big reasons Deno was appealing to me was `deno bundle`. If bun can crack executable generation (along with code signing and notarization), it’ll unlock a whole new dimension for bun apps.
gardenhedge 4y ago
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.
- aphexairlines 4y ago
  They don't have to hire people who already know Zig -- just people capable of learning it.
  - Existenceblinks 4y ago
    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)
- saagarjha 4y ago
  I assume they are looking for the profile of a browser engineer, which is not that rare
  - gardenhedge 4y ago
    Is it not? Seems pretty niche to me. For example, I know lots of types of engineers but never a browser engineer.
    - saagarjha 4y ago
      Generally someone with a strong C++ background and understanding of some portion of the browser stack (DOM/compilers/networking/security/…)
xg15 4y ago
Really appreciating bun's ability to set custom WebSocket headers. 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? [1] https://github.com/whatwg/websockets/issues/16 https://github.com/whatwg/websockets/issues/16
- RedShift1 4y ago
  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.
  - danr4 4y ago
    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.
cdelsolar 4y ago
can bun be used for front-end? i.e. to replace create-react-app + Webpack + etc
- madeofpalk 4y ago
  To replace webpack? I don’t think that makes sense. 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
  - iamgopal 4y ago
    Means, in future, will there be a browser?
    - madeofpalk 4y ago
      A bun browser? Bun is like NodeJS. There is no ‘node browser’ Bun uses JavaScriptCore from WebKit/Safari, similar to how Node uses V8 from Chrome
- reducesuffering 4y ago
  I thought I read that v0.6 will include Vite support, so you'll be able to do a SPA front-end with Vite + Bun.
serverholic 4y ago
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.
rcarmo 4y ago
Still can’t run Node-RED, which would be a key use case for me.
- Jarred 4y ago
  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
  - rcarmo 4y ago
    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.
    - fennecfoxy 4y ago
      Eslint the hecky out of it

330 points by cyclecity 4y ago

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.

Jarred 4y ago
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
- lhnz 4y ago
  You might be interested in @devongovett's `glob_match` library (written in Rust): https://github.com/devongovett/glob-match https://github.com/devongovett/glob-match
  - sebdufbeau 4y ago
    Seems to already be on his radar: https://twitter.com/jarredsumner/status/1615071897859018753 https://twitter.com/jarredsumner/status/1615071897859018753

Jarred 4y ago

I work on Bun. Happy to answer any questions or feedback

junon 4y ago
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.
ptrwis 4y ago
Do you plan to support http3 in the (near) future?
christkv 4y ago
Is it possible to connect to Mongodb yet?
- Jarred 4y ago
  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) Tracking issue: https://github.com/oven-sh/bun/issues/1822 https://github.com/oven-sh/bun/issues/1822
  - christkv 4y ago
    Awesome thanks for answering it.
edvards 4y ago
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
Thaxll 4y ago
What was the decision making of chosing Zig for Bun, a very promising but immature language?
- Jarred 4y ago
  Zig is great for writing fast software and I’m really productive in Zig.
  - thayne 4y ago
    Are you worried about breaking changes in zig requiring large changes in bun, or getting stuck on an old version of zig?
mattlondon 4y ago
Is there a migration guide for Deno users?
- MuffinFlavored 4y ago
  do you think it might be too “living on the cutting edge” to adopt this yet?
- Jarred 4y ago
  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
culi 4y ago
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 [0] https://scikitjs.org/ https://scikitjs.org/
- adenozine 4y ago
  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.
  - sublinear 4y ago
    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.
rmorey 4y ago
What are some good resources to learn zig?
- Jarred 4y ago
  - Ziglings is great - https://github.com/ratfactor/ziglings https://github.com/ratfactor/ziglings - zig.news has some good posts https://zig.news/ https://zig.news/ - Zig's language docs: https://ziglang.org/documentation/master/ https://ziglang.org/documentation/master/ - Zig's standard library code https://github.com/ziglang/zig/ https://github.com/ziglang/zig/
danielEM 4y ago
Out of curiosity - how do bun plan on monetization? Is that even possible in the age of node.js, deno and who knows what else? :-) 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 :-)
- TAForObvReasons 4y ago
  Hosting is the obvious answer. Deno is monetizing in the same exact way (https://deno.com/deploy/pricing https://deno.com/deploy/pricing) and they managed to raise much more money with the same playbook.
danielEM 4y ago
And a side note, before got to this thread was looking into bun code and saw your commits, you're very productive man, congrats!
detrites 4y ago
Are there any plans for a REPL? And thanks for bun! It's been impressive and inspiring to watch.
- Jarred 4y ago
  This is something we need to do, but haven't prioritized yet For now you can do bunx bun-repl
tiffanyh 4y ago
Any plans to collaborate with just-js?
Yahivin 4y ago
Civet just added a bun loader https://github.com/DanielXMoore/Civet/blob/main/source/bun-civet.coffee https://github.com/DanielXMoore/Civet/blob/main/source/bun-c... I'm curious to hear your thoughts about Bun/Civet integration to explore improvements to the language frontend as well as the language backend?
deworms 4y ago
[dead]
henry_viii 4y ago
A couple of reasons that contribute to Bun's performance are: 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?
- kamikaz1k 4y ago
  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.
leidenfrost 4y ago
How far is Bun to run a NestJS project? (Leaving adapters like Mongo aside)
ushakov 4y ago
I have a question. Does Jarred ever have a vacation? Really concerning to see how much you work lately. Wishing you a more relaxed time
- forrest2 4y ago
  I don't wanna speak for them, but for some people, going in deep on something is the only way to stay healthy / happy / sane. Different strokes for different folks
  - aarpmcgee 4y ago
    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.
  - girvo 4y ago
    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
- Jarred 4y ago
  I love working on Bun and find it very energizing
- vcryan 4y ago
  Somehow being coerced to work long hours had been conflated with choosing to work long hours. Some people really enjoy working. I know, it's hard to believe :)
999900000999 4y ago
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.
- swyx 4y ago
  "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/ https://oven.sh/
  - okhuman 4y ago
    One downside: core devs only prioritize bun features which can enable use cases for running your code in their edge/hosted platform. Missing some of the other general purpose use cases that devs would want to build - which wouldn't fit into bun's flavor of hosting.
  - 999900000999 4y ago
    >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
    - ZephyrBlu 4y ago
      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?
jonasb 4y ago
Will Postgres.js be the way to go for using Postgres, or do you expect to build a custom Postgres client library?
- Jarred 4y ago
  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.
  - jonasb 4y ago
    Great, thanks! I'll start with Postgres.js then.
2h 4y ago
[flagged]
nequo 4y ago
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] https://bun.sh/ https://bun.sh/ [2] https://github.com/nodejs/node https://github.com/nodejs/node
- hiccuphippo 4y ago
  He has an answer in this talk around the 11:30 mark: https://youtu.be/eF48Ar-JjT8&t=690 https://youtu.be/eF48Ar-JjT8&t=690
- nonethewiser 4y ago
  This is a great question, hope he answers.
- culi 4y ago
  Those benchmarks may not actually hold up to independent analysis: https://medium.com/deno-the-complete-reference/node-js-vs-deno-vs-bun-server-side-rendering-performance-comparison-f80a5abc766f https://medium.com/deno-the-complete-reference/node-js-vs-de...
  - Jarred 4y ago
    Two things about the linked benchmark: 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. PR: https://github.com/facebook/react/pull/25597#issuecomment-1302816780 https://github.com/facebook/react/pull/25597#issuecomment-13... Source of Bun's homepage benchmark: https://github.com/oven-sh/bun/blob/9ef33312b1b199931c29c182c4bc3984a944bb9a/bench/react-hello-world/react-hello-world.jsx#L1-L7 https://github.com/oven-sh/bun/blob/9ef33312b1b199931c29c182...
toastal 4y ago
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?
- thatoneguytoo 4y ago
  C'mon dude.
  - toastal 4y ago
    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.
- icemelt8 4y ago
  haha
aitchnyu 4y ago
Whats the plan for wasm build? We are using quickjs-emscripten for running sandboxed scripts and we would love top level async and crypto.

maherbeg 4y ago

Is there a roadmap to getting to a 1.0 stable release?

1vuio0pswjnm7 4y ago

Please add musl build here: https://github.com/oven-sh/bun/releases/expanded_assets/bun-v0.4.0 https://github.com/oven-sh/bun/releases/expanded_assets/bun-...

Jarred 4y ago
The last time I looked into adding musl support, there were some difficult to narrow down crashes in bun's linux aarch64 build it's worth revisiting though since its been a little while

muhammadusman 4y ago

As is with all things in the JS world, I usually ignore new things until they have some traction. Is Bun ready to be used for production projects?

wetpaws 4y ago
Ahaha no
swyx 4y ago
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.
- skerit 4y ago
  I see no problem in someone asking a simple question like this. I've seen far more dismissive posts here anyway

Alifatisk 4y ago

Makes me happy seeing newer alternatives to Node, it’s exciting!

thiago_fm 4y ago

Anybody care to explain on how it achieve such numbers in comparison to node and deno? 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.

EGreg 4y ago
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.
- klohto 4y ago
  Node forked to Deno? And merged... back? What are you talking about?
- zdragnar 4y ago
  You might be thinking of io.js, which was a fork almost entirely due to politics. The advisory board came out of it, and a push for semver, but it started here: https://github.com/joyent/libuv/commit/804d40ee14dc0f82c482dcc8d1c41c14333fcb48 https://github.com/joyent/libuv/commit/804d40ee14dc0f82c482d...
- ramesh31 4y ago
  >I've seen Node forked (to Deno I think) and then eventually they merged it back. You're thinking of the io.js debacle
kamikaz1k 4y ago
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. 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
4y ago

pictur 4y ago

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.

francislavoie 4y ago
Because it's positioning itself as a faster, leaner, modern drop-in replacement for Node.
vexna 4y ago
Because its for running server side javascript, just like node/deno. It would make sense to compare itself to its competition.
kamikaz1k 4y ago
what else would you see it compared to?
- davesnx 4y ago
  versus other than JavaScript stuff: Java, C++, OCaml or Go
  - francislavoie 4y ago
    But why? It's a JS runtime. Obviously you'll compare yourself to the other competing JS runtimes.
intelVISA 4y ago
easy targets I would guess

wdb 4y ago

Starting to look promising. Work projects not working yet due to the need of `dgram` and `async_hooks`. Would leveraging `async_hooks` be possible in the future with the used non-v8 engine or would there be some alternative?

Jarred 4y ago
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
- stephen 4y ago
  Amazing. Getting just AsyncLocalStorage and the rest of async_hooks later / or not all would be great, as that's currently blocking us from bun. 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.)

gmaster1440 4y ago

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.

viksit 4y ago

as a newbie to bun, is there a reason to use it beyond it being an alt to node/deno? i mean, i don’t know how many people even use deno, let alone bun.

msoad 4y ago

Does Bun also generate standalone executables? I'm interested in using it for CLI apps.

httgp 4y ago
This will be a killer feature. One of the big reasons Deno was appealing to me was `deno bundle`. If bun can crack executable generation (along with code signing and notarization), it’ll unlock a whole new dimension for bun apps.

gardenhedge 4y ago

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.

aphexairlines 4y ago
They don't have to hire people who already know Zig -- just people capable of learning it.
- Existenceblinks 4y ago
  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)
saagarjha 4y ago
I assume they are looking for the profile of a browser engineer, which is not that rare
- gardenhedge 4y ago
  Is it not? Seems pretty niche to me. For example, I know lots of types of engineers but never a browser engineer.
  - saagarjha 4y ago
    Generally someone with a strong C++ background and understanding of some portion of the browser stack (DOM/compilers/networking/security/…)

xg15 4y ago

Really appreciating bun's ability to set custom WebSocket headers. 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? [1] https://github.com/whatwg/websockets/issues/16 https://github.com/whatwg/websockets/issues/16

RedShift1 4y ago
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.
- danr4 4y ago
  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.

cdelsolar 4y ago

can bun be used for front-end? i.e. to replace create-react-app + Webpack + etc

madeofpalk 4y ago
To replace webpack? I don’t think that makes sense. 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
- iamgopal 4y ago
  Means, in future, will there be a browser?
  - madeofpalk 4y ago
    A bun browser? Bun is like NodeJS. There is no ‘node browser’ Bun uses JavaScriptCore from WebKit/Safari, similar to how Node uses V8 from Chrome
reducesuffering 4y ago
I thought I read that v0.6 will include Vite support, so you'll be able to do a SPA front-end with Vite + Bun.

serverholic 4y ago

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.

rcarmo 4y ago

Still can’t run Node-RED, which would be a key use case for me.

Jarred 4y ago
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
- rcarmo 4y ago
  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.
  - fennecfoxy 4y ago
    Eslint the hecky out of it