Jarred

7 ms·

31.
by Jarred 10mo ago
Speaking as the creator of one of the largest Zig projects, I agree with antirez
32.
by Jarred 1y ago
Here is the code: https://github.com/oven-sh/bun/blob/7d5f5ad7728b4ede521906a4... We trust the self-reported size by gzip up to 64 MB, try to allocate enough space for all the output, then run it through libd
33.
by Jarred 1y ago
You can use `bun install --linker=isolated`, which we might make the default in Bun v1.3. The main downside is it makes your app load slightly slower since now every file path is a symlink. https://bun.sh/docs/install&#
34.
by Jarred 1y ago
I work on Bun and also spent a lot of time optimizing bun install. Happy to answer any questions
35.
by Jarred 1y ago
Playwright support will improve soon. We are rewriting node:http’s client implementation to pass node’s test suite. Expecting that to land next week.
36.
by Jarred 1y ago
Streaming prevents many optimizations because the code can’t assume it’s done when run once, so it has to suspend / resume, clone extra data for longer, and handle boundary cases more carefully. It’s usually only worth it after ~tens o
37.
by Jarred 1y ago
We probably will do similar in the Bun repo. We use AI tools a lot and don’t discourage it, but we also label when a PR was generated by claude both via github label and also by leaving in the “Generated with claude code” textual watermark
38.
by Jarred 1y ago
We’ve made a lot of progress on bun install over the last few months: - isolated, pnpm-style symlink installs for node_modules - catalogs - yarn.lock support (later today) - bun audit - bun update —interactive - bun why <pkg> helps f
39.
by Jarred 1y ago
This will ship as part of the Bun v1.2.19 release, which we are aiming for tonight. There is a Windows-only bug in the isolated install mode blocking us from using isolated installs ourselves in the bun repo, and we need to fix that before
40.
by Jarred 2y ago
No plans to do that. If you're worried about binary size from features you don't use: the binary size cost of Bun.sql is less than 50 KB (you can check this yourself via the .linker-map file in the *-profile.zip builds of Bun or v
41.
by Jarred 2y ago
I work on Bun. Happy to answer any questions.
42.
by Jarred 2y ago
I've been using Ghostty for several months now (used Alacritty before that). Ghostty is really, really good. It's fast, it gets the text rendering right (many cross-platform terminals struggle with this), and it has all the featur
43.
by Jarred 2y ago
I work on Bun. Happy to answer any questions. We honestly should've done the text-based lockfile awhile ago. The JSON parsing overhead was very obviously not the right tradeoff compared to the DX impact. But I'm happy with all the
44.
by Jarred 2y ago
> The site presents Deno 2 as if it has finally beat Bun in terms of performance Bun's HTTP server performs 51% faster before parallelism. Their benchmark is incorrect. They posted a correction, and their correction is also incorrec
45.
by Jarred 2y ago
This was an unplanned feature I worked on mostly a month ago on a Saturday for fun. Happy to answer any questions To get it out the door, ended up adding some patches to TinyCC to support .framework on macOS and fix a few things with dlopen
46.
Bun (YC S19) Is Hiring Systems Engineers in San Francisco(apply.workable.com)
1 points by Jarred 2y ago
47.
by Jarred 2y ago
Anyone can contribute to Bun, but we only hire IRL (and we help with relocation + visa). Bun is an extremely context-heavy product and being IRL makes it a lot easier to help each other when we get stuck and explain things. I think if we ha
48.
by Jarred 2y ago
Bun | Software Engineer (systems, runtime, i/o) | Fulltime | Onsite in San Francisco | https://bun.sh Bun is an open-source JavaScript tooling company focused on making programming simpler. Today, Bun is a JavaScript runtim
49.
by Jarred 2y ago
I work on Bun. Happy to answer any questions or feedback
50.
by Jarred 2y ago
Bun is a JavaScript runtime, bundler, transpiler, npm package manager, and test runner all-in-one. It isn't accurate to say Bun is a JavaScript engine. We use JavaScriptCore as the engine, which is the same engine used by Safari (WebKi
51.
by Jarred 2y ago
I work on Bun. Happy to answer any questions
52.
by Jarred 2y ago
I work on Bun Happy to answer any questions
53.
by Jarred 2y ago
One of the features missing in bun:ffi is inferring types for symbols from header files. This would let you import C libraries in JavaScript/TypeScript directly, without having to configure bindings. We embed TinyCC for FFI, but TinyCC
54.
by Jarred 2y ago
From the beginning, Bun was designed to be a drop-in replacement for Node.js. That’s why Bun implements Node’s globals. That’s also why Bun automatically detects when CommonJS is used in the entry point and ensures CommonJS is loaded. requi
55.
by Jarred 2y ago
The JS engine is impossible to leave out, as this is a JavaScript API and strings are very engine specific. We spend many hours reading JavaScriptCore (the engine)’s code and when we wrote the code for Buffer and related APIs we spent a lot
56.
by Jarred 2y ago
Bun does not wrap Node. Bun is a JavaScript runtime and suite of tools separate from Node. We do implement Node APIs and spend an enormous amount of time on compatibility. We have to use the same `code` property on many errors or libraries
57.
by Jarred 2y ago
I work on Bun. Happy to answer questions or feedback or anything
58.
Bun (YC S19) Is Hiring Systems Engineers in San Francisco(apply.workable.com)
1 points by Jarred 2y ago
59.
by Jarred 2y ago
I work on Bun. Happy to answer any questions. One of the things I’m happy about in our UDP sockets implementation is socket#sendMany. Internally, it uses sendmmsg on Linux and the undocumented sendmsg_x API on macOS which let you send multi
60.
by Jarred 2y ago
> the argument for using this over a regular stack trace is that they don't have to ship megabytes of debug symbols No, it’s because almost nobody has enough patience to upload a crash report for a GitHub issue. It has to be easy. M

More ›