Bun v1.3.9 | alt.hn

2/8/2026 at 6:57:21 PM

Parallel and sequential, especially at the command level, are really the wrong abstractions for running scripts. If you have multiple packages, each with builds, there's a high chance you have dependencies and multiple packages depending on common ones.

What you really want is a way for scripts to describe their dependencies, and then the runner figures out what order to run them in, and cache scripts that don't need to be run because their inputs didn't change.

Wireit[1] is an npm script runner that adds that incrementally on top of package.json. I can't manage an npm monorepo without it now.

Deno started integrating the idea directly into their built-in script runner. I think this is an important enough feature that more runtimes should follow Deno's lead.

[1]: https://github.com/google/wireit

by spankalee

2/8/2026 at 8:50:06 PM

> What you really want is a way for scripts to describe their dependencies, and then the runner figures out what order to run them in, and cache scripts that don't need to be run because their inputs didn't change.

DAG + content-addressing, final binary being the target and everything resolved from there. We could have some beautiful build system that just works and is fast, but seems it never magically appears by itself although it seems so elegant. Guess Nix/NixOS is the closest we've gotten so far, works well enough, missing concurrency and parallelism though.

by embedding-shape

2/8/2026 at 9:40:48 PM

Google's build system Bazel is what you describe.

by dpe82

2/8/2026 at 10:45:39 PM

I should really give it another look, I usually ended up not adopting it for projects because of the boilerplate and high setup overheard, but those are both things that ai agents can usually be trusted with. Maybe the calculus has changed.

by mattnewton

2/9/2026 at 1:41:56 AM

Yeah Bazel is a PITA to do yourself. I haven't tried but I'm confident Claude et al. would handle it just fine. By similar logic I recently adopted NixOS for a lot of my servers; Claude is perfectly happy to slog through the pain of Nix configs for me.

by dpe82

2/9/2026 at 2:47:45 AM

I’m not a fan of generative AI for the use case because it’s rote enough to do deterministically, but deterministic code generation is getting better and better.

Gazelle, the BUILD file generator for Go, now supports plugins and several other languages have Gazelle plugins.

I’ve used AI to generate BUILD file generators before, though. I had good luck getting it to write a script that would analyze a Java project with circular dependencies and aggregate the cycle participants into a single target.

by hxtk

2/9/2026 at 2:50:33 AM

It’s gotten easier of late because Bazel modules are nice and Gazelle has started support plugins so it can do build file generation for other languages.

I don’t like generative AI for rote tasks like this, but I’ve had good luck using generative AI to write deterministic code generators that I can commit to a project and reuse.

by hxtk

2/8/2026 at 11:00:53 PM

Could you clarify what you mean about Nix missing concurrency and parallelism? I often run builds using nix-output-monitor and it definitely looks like things are running in parallel, although I could be mistaken.

by sestep

2/10/2026 at 11:31:03 AM

I meant as part of the language itself, not just the runtime or for specific parts. Say I'm processing 100 JSON files, it'd be great if I could fire that off wrapped in 'parallel' or whatever, similar to Clojure and others I guess.

by embedding-shape

2/8/2026 at 10:31:49 PM

Wireit does both DAG and content-addressing. It figerprints the inputs and outputs of dependencies. And you run scripts externally with plain `npm run` commands. It's really beautiful.

by spankalee

2/9/2026 at 6:57:52 AM

`make` can do exactly the same.

by silverwind

2/8/2026 at 7:48:14 PM

If only we could make something like that

But now we would need each script to independently do their own caching, which isn’t all bad. At least you have more cross runner compatibility and resilience

by pyrolistical

2/8/2026 at 10:30:41 PM

Wireit really is that. The script declares dependencies and input, Wireit caches based on the direct inputs and dependency outputs.

by spankalee

2/8/2026 at 11:49:59 PM

Why didn't I know about this before

by aziis98

2/8/2026 at 6:18:27 PM

Genuine question out of curiosity. Why do I want parallel and sequential when I can just write a simple bash script to accomplish the same thing? Is there some additional complexity I’m missing?

by johnfn

2/8/2026 at 6:55:28 PM

As a note here, there are a lot of resources that make bash seem incredibly arcane, with custom functions often recommended. But a simple interruptible script to run things in parallel can be as simple as:

    (trap 'kill 0' INT TERM; cmd1 & cmd2 & cmd3 & wait)

Or, for 1+2 sequentially, in parallel with 3+4 sequentially:

    (trap 'kill 0' INT TERM;
      (cmd1 && cmd2) &
      (cmd3 && cmd4) &
      wait
    )

(To oversimplify: The trap propagates the signal (with 'kill') to the process group 0 made by the () parens; this only needs to be set at the top level. & means run in background, && means run and continue only on success.)

There are other reasons one might not want to depend on bash, but it's not something to be afraid of!

by btown

2/8/2026 at 6:48:07 PM

I get where you're coming from and if this was a package I'd agree - but having this built in/part of the tooling is nice - one less dependency - bash isn't as ubiquitous as you assume.

by rafaelmn

2/8/2026 at 6:24:16 PM

This is cleaner and you don't have to write a bash script. It's one (well, several: the script, bash, and it's dependencies) less thing, which is important in containers and for scale.

by runjake

2/8/2026 at 6:28:50 PM

It lets developers on Windows also build and test your package in parallel mode. If you make your build scripts bash, they're Linux-only.

by an_ko

2/8/2026 at 6:33:01 PM

> if you make your build scripts bash, they’re Linux only

Git bash exists on windows and is perfectly usable.

by maccard

2/8/2026 at 6:44:09 PM

It's still much less dependable compared to something fully supported like Bun.

by hu3

2/9/2026 at 8:47:22 AM

I’m no bash lover, but I’ve used git bash as my primary driver on windows for I don’t know many years. It has its quirks (like any tool) but I don’t think I’d say it’s less dependable. Anecdotally I’ve had way more issues with node on windows than I have with git bash and node is fully supported.

by maccard

2/9/2026 at 1:06:00 PM

Fully supported, until they sell it to someone.

by throw20251220

2/9/2026 at 2:23:22 PM

I mean, Anthropic now own it

by maccard

2/9/2026 at 4:21:33 AM

Yes, bash is the near-universal language for build scripts as long as git is the near-universal source control tool.

by dundarious

2/9/2026 at 7:19:58 AM

That is an interesting point... but if I do development on windows it usually happens inside WSL :)

Seriously, my number one windows shell is WSL. Distant second and third are cmd and powershell which I only use to diagnose WSL issue.

by throwa356262

2/8/2026 at 6:45:52 PM

> when I can just write a simple bash script to accomplish the same thing

At this point you don't need most things...

by re-thc

2/8/2026 at 7:16:30 PM

But this is no more than 5 lines of code. If it was 100 I’d understand.

by johnfn

2/8/2026 at 6:31:27 PM

A few reasons.

1. Minor speed boost from not needing bun multiple times (or extract the build/test/lint commands from package.json).

2. You can query/filter commands. E.g. run all my tests (both unit and integration).

3.You avoid needing a separate Bash install (for Windows).

by paulddraper

2/8/2026 at 6:06:45 PM

Is it more common in English to use there terms Parallel and Sequential or Parallel and Series ? Made a React Library to generate video as code and named two components <Parallel> <Series> I was wondering if those were two best terms two use...

by giorgioz

2/8/2026 at 6:28:11 PM

Electric engineering talks about parallel and series. (including the old parallel and serial ports on computers, before almost everything became serial)

Programming talks about parallelism or concurrency or threading. (single-threading, multi-threading)

Or synchronous and asynchronous.

The legal system talks about concurrent and consecutive.

Process descriptions might use "sequential" rather than consecutive or series.

"Linear" is another possibility, but it's overloaded since it's often used in reference to mathematics.

by harshreality

2/8/2026 at 6:22:37 PM

Both would be understood and are roughly interchangeable.

"Sequential" feels more appropriate to me for the task runner scenario where we wait for one task to finish before running the next.

"Series" suggests a kind of concurrency to me because of the electrical circuit context, where the outputs of one are flowing into the next, but both are running concurrently. Processes that are Unix piped into each other would be another thing that feels more like a "series" than a "sequence".

by gradys

2/8/2026 at 6:20:06 PM

When talking in terms of software parallelism, "parallel" and "sequential" are more common to describe, for example, multi-threaded vs. single-threaded implementations.

by smlavine

2/8/2026 at 9:55:23 PM

The electronics terms parallel and series are about static physical connections (things are connected in parallel or series — the more grammatical form would be in a series).

The software terms parallel and sequential are about the temporal relationship of activities (things are done in parallel or sequentially). That’s why in software we also have the term “concurrent” which means something different from “parallel”.

by wrs

2/9/2026 at 1:34:44 AM

Series would be perfectly fine, though out of context it might be a bit confusing because it's also used to describe data on a chart.

Using the singular "Sequence" might also be appropriate for a component name, as the component represents the collection entity, rather than referring directly to the things within the collection itself (which I presume are either a prop or the children of the component).

by zdragnar

2/8/2026 at 6:24:00 PM

I think your average person knows what sequential means but might not remember what series means. Personally I always remember the meaning of series in “parallel vs series” because it must be the opposite of parallel. I’m not proud of the fact that I always forget and have to re-intuit the meaning every time, but the only time I ever see “series” is when people are talking about a TV show or electronics.

by cornstalks

2/8/2026 at 9:09:18 PM

Sequential is a fuzzier word. It can imply that a series of steps feeds output from step A into step B and so on. But at the same time it can also drift into areas typically defined as linearization. Where a task runs in parallel but applies in series, in sequence.

by hinkley

2/8/2026 at 6:10:47 PM

Parallel and Series makes sense to me; it's also the terminology used for electrical circuits.

by richbell

2/8/2026 at 10:00:53 PM

Well, that speeds things up a lot. But I agree with spankalee, it should be a DAG.

  < "ci": "CI=true bun run check && bun run test && bun run build && bun run docs && bun run zip && bun run zip:firefox"
  > "ci": "CI=true bun run --parallel check test build docs && bun run --parallel zip zip:firefox"

by oj-hn-dot-com

2/9/2026 at 9:42:05 AM

The problem is that whole thing should have been its own script, which it coulda been with npm-run-all:

https://github.com/mysticatea/npm-run-all/blob/HEAD/docs/npm...

"scripts":{ "buldrun":"run-p check test docs && run-p zip zip:firefox" }

I guess you can put `bun run --parallel` into the script too but it's a bit more verbose.

by hdjrudni

2/9/2026 at 3:52:38 PM

Why would I want to add an external dependency?

by oj-hn-dot-com

2/9/2026 at 8:02:06 AM

even though it's at 1.x release, Bun still has so many critical issues (segfault, etc...)

by tuananh

2/9/2026 at 11:32:13 AM

Going 1.0 was a requirement for cashing out, don't worry about it. And segfaults don't really even matter as long as you run the code in production with -OReleaseSafe and turn on ubsan, it's fiiiiineee

by dmit

2/8/2026 at 8:01:03 PM

This is nice to see, but I'm curious to check if the web socket bugs are all gone (I had a watch on a particular one that stopped me from running Node-RED in some circumstances, but can't find it on mobile...)

by rcarmo

2/9/2026 at 2:21:35 AM

It's fascinating to see a project like Bun, already mature enough to run in production, and yet still improving everyday even if it's a 1.1x speedup. To me, that shows how committed the team is to deliver performance.

by _bittere

2/9/2026 at 3:31:12 AM

Is it mature?

I’m genuinely curious because there’s currently 63 open issues of reported segfaults.

https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

by tiffanyh

2/9/2026 at 8:00:16 AM

It's also built on an unstable language. I'm a big fan of Zig, for what it's worth, and also it's important to take into consideration.

by harrisi

2/8/2026 at 9:34:34 PM

Why does Anthropic even need Bun? Is Claude not good enough to write something far superior very fast?

by dude250711

2/8/2026 at 10:11:43 PM

Think you answered your second question with your first.

by dmit

2/8/2026 at 9:45:01 PM

Their C compiler project proves the opposite.

by attractivechaos

2/9/2026 at 6:16:28 PM

You must have read headings only. It’s a useless slop past hello world. Lots of slop.

by throw20251220

2/8/2026 at 9:42:56 PM

IIRC Claude actually did write a lot of it.

by TurdF3rguson