Jarred

We are a team, but Dave wrote the code for this project so "I" makes sense

Currently, the REPL is an alias of `bunx bun-repl`, and bun-repl is a community-maintained npm package. We haven't had the time to do our own REPL. Honestly, we really need to hire more engineers. We're a small team and there's so much to do

We haven’t prioritized implementing a repl yet. The current repl is a community-implemented bun-repl npm package. `bun repl` internally does the equivalent of `bunx bun-repl`

Try simdutf. You’ll get a performance boost too.

If you like writing Zig, Bun is hiring systems engineers in San Francisco. We are one of the largest Zig projects.

https://bun.sh/careers

The timer heap currently lives on a different thread instead of the main thread, which means timers have to be allocated and scheduled separately for each one. Scheduling things to other threads is expensive. The reason it works this way isn't good and we will fix it but haven't prioritized it yet

We copied libxev's code for the timer heap implementation in Bun for setTimeout & setInterval, and it was a ~6x throughput improvement[0] on Linux compared to our previous implementation.

[0]: https://twitter.com/jarredsumner/status/1736741811039899871

What does the code do? 30-45 seconds to parse a 5k line text file into JSON sounds like something is going very wrong

We'll add cross-compilation support and Windows arm64 eventually. I don't expect much difficulty from Windows ARM once we figure out how to get JSC to compile on that platform. We support Linux ARM64 and macOS arm64.

I’m pretty sure issue #6842 was fixed in Bun v1.0.32 or so and we forgot to mark the issue as fixed

Will check once I get to my computer

Edit: was not fixed. We made other changes to fs.readSync to improve Node compatibility, but missed this. It will get fixed though

This is dead code from before Bun 1.0. This code exists but is not run and probably stripped from the final executable (Zig is great at dead code elimination). We do get the Linux kernel version to detect if syscalls like pidfd_open are supported and enable fast paths.

We’ll add the uncaught exceptions handler likely before Bun 1.2 and fix the issue with sourcemaps. Sourcemaps do work (with some rough edges) at runtime when running TS/JSX/JS files, but are in a worse state with “bun build” right now.

We’ve been so busy with adding Windows support that it’s been hard to prioritize much else

Ship an open-source Discord alternative that more people want to use than Discord and we’ll happily switch.

We need to do some form of this but I’m not exactly sure what yet. I suspect same process but multiple globals might work well. A lot of tests spend time sleeping or waiting for things. They might benefit from that kind of paralellism (like async/await, except between things it runs a whole other global object)

Threads could also work but the problem is you have to re parse & evaluate all the code. That’s a lot of duplicate work. It’s probably still worth it for large enough apps

Bun transpiles Typescript to JavaScript before execution, removing types and doing some dead code elimination

That is unrelated. This is a code signing / notarization issue because we don’t distribute Bun via the Mac App Store and likely the way it was installed was via npm or something other than .zip file we distribute. Code signing is necessary due to the JIT entitlement in Bun (otherwise Bun would be a whole lot slower)

Note that we do not currently send telemetry anywhere. The extent of what we track right now is a bitset of what builtin modules were imported and a count of how many http requests were sent with fetch(), and a few things like that. This is used in the message printed when Bun panics so we can have a better idea of what the code was doing/did when it crashed

I work on Bun and happy to answer any questions.

Note that Bun v1.1 is still compiling at the time of writing (probably for another 20 minutes)

Node.js Readable and Web API's ReadableStream both implement [Symbol.asyncIterator], which means you can usually use `for await` without extra code nowadays

Is this for all of WebKit or the non-Cocoa/Apple builds? It reads like WebKit on Mac (Safari) will not be impacted by this change

Bun Shell implements a cross-platform bash-like shell, using builtins for popular commands like `rm`, `cd`, `which`, `ls` etc which support the same flags on Linux, macOS, and Windows. A lot of why we made it was for `bun install` to work on Windows without needing polyfill packages like `rimraf` or `cross-env` in package.json scripts.

zx uses the system-provided shell, which means it isn't cross-platform

For the commands Bun Shell implements as builtins, they typically run something like 10x - 20x faster than in zx on mac/linux because spawning processes is expensive (even more expensive on Windows)

Bun (YC S19) | https://bun.sh | San Francisco | ONSITE | Full-time

Bun is an incredibly fast JavaScript runtime, package manager, test runner, and bundler. Our 2024 goal is to replace Node.js as the default server-side JavaScript runtime. We launched Bun 1.0 back in September: https://www.youtube.com/watch?v=BsnCpESUEqM, and it's been a really exciting 6-ish months seeing developers use Bun at companies like X (Twitter), Midjourney and Brex.

Today we have over 2,000 issues open in our GitHub repo https://github.com/oven-sh/bun/issues, and while we love seeing people use Bun, it's clear that we need to grow the team to help make Bun more reliable and implement missing features blocking companies from switching to Bun.

We are hiring systems engineers in San Francisco to help make Bun more reliable and implement new runtime APIs and services. Bun is written in a mix of Zig and C++, but experience with Zig is not required (People with a C/C++ background tend to pick up Zig quickly). Working on Bun often involves reading WebKit/JavaScriptCore source code, Zig standard library source code, Darwin XNU source code, and sometimes Linux kernel source code. We are a well-funded early-stage startup (9 people currently). Our office is in the financial district in San Francisco

Please apply here: https://apply.workable.com/oven/j/A7A1388873/

The -N flag tells hyperfine to not run it in a shell, which means it is not nested.

It’s nearly all in Zig.

The parser, lexer, interpreter, process execution and builtin commands are all implemented in Zig.

There’s a JS wrapper that extends Promise but JS doesn’t do much else.

The performance of the interpreter probably isn’t as good as bash, but the builtin commands should be competitive with GNU coreutils. We have spent a lot of time optimizing our node:fs implementation and this code is implemented similarly. We expect most scripts to be simple one-liners since you can use JS for anything more complicated.

We implement a handful of the most common commands like cd, rm, ls, which, pwd, mv. Instead of using the system-provided ones, it uses ours.

Unlike zx/execa, we have our own shell instead of relying on a system-installed one.

I work on Bun - happy to answer any questions/feedback

I work on Bun (though I did not work on this feature much outside of reviewing the PR), happy to answer any questions

You can use it today with containers in Lambda or a custom Lambda runtime, but both approaches have embarrassingly slow cold start. Lambda has special optimizations for Node which are not possible without official support.

I have no idea when Lambda would add an official runtime layer. But if you work at Lambda and are interested, feel free to email me - jarred@bun.sh

After Windows support is further along, but not that long from now

(I work on Bun)

A neat thing about tail calls in JavaScriptCore: there’s an explicit bytecode intrinsic for it.

  return @tailCallForwardArguments(MyConstructor, this);

To use this in Bun, you’d have to start Bun with the environment variable “BUN_JSC_useDollarVM=1” and then $vm.createBuiltin(mySourceCodeString)

When using this intrinsic, if any of the arguments are incorrect or it cannot otherwise enable it, the entire process will probably crash. In debug builds of JSC it will have a nicer assertion failure but that is not enabled in release builds

Example code: https://github.com/WebKit/WebKit/blob/17351231b4dedb62d81721...

also happy to answer any questions about Bun