Forem: osvfelices

Pulse 2.0: Building a Deterministic Runtime for JavaScript Without Losing Your Mind

osvfelices — Tue, 25 Nov 2025 12:15:47 +0000

(A real-world story of rewriting how async JavaScript should work)

If you’ve ever tried to build a truly concurrent system in JavaScript, you probably discovered three things very quickly:

Promises are great until you actually need to orchestrate them.
Promise.race has exactly one personality: chaos.
Debugging async behaviour in Node feels like archaeology.

Pulse 2.0 started as a private experiment to answer a simple question:
Can we build a runtime for JavaScript applications that behaves predictably under load?

The answer became “yes”, but the road was much longer than expected.

After months of work, runtime audits, stress testing, and a full rewrite of HTTP handling, we now have something real: a deterministic runtime designed for modern backend apps.

Documentation:
https://osvfelices.github.io/pulse/

Why Pulse Exists

At its core, Pulse is about one idea:

Same inputs → Same outputs. Every time.
Even under concurrency. Even under load. Even when 100 tasks compete for channels.

Pulse introduces:

A deterministic scheduler
CSP-style channels
Select operations with strict ordering
Structured concurrency
A real HTTP server integrated with the scheduler
A debugger/inspector with predictable state snapshots

JavaScript was not built with this in mind, so Pulse had to build the missing pieces.

Deterministic Concurrency (Without Magic)

Pulse includes a scheduler that models async execution as a series of logical time steps, not wall-clock time.

Instead of letting Node decide task ordering, Pulse controls:

Task creation
Task wakeup
Channel send/receive events
Resolution of select operations
Cancellation cascades

The benefit is immediate:

If a program runs correctly once, it runs correctly every time.

We verified this with a 100-run determinism test. All runs produced identical output hashes.

Channels and Select: CSP Done Properly

Channels in Pulse behave like in Go:
blocking send, blocking receive, predictable ordering, safe close behaviour.

Example:

import { channel, spawn, sleep, select, selectCase } from 'pulselang/runtime';

await scheduler.run(async () => {
  const ch = channel(1);

  spawn(async () => {
    await sleep(50);
    await ch.send("hello");
  });

  const result = await select(
    selectCase(ch, 'recv', value => `received: ${value}`)
  );

  console.log(result);
});

Even this simple snippet has a lot happening under the hood: task registration, channel waiters, deterministic state transitions, select resolution priority, etc.

Pulse ensures all of it happens in a fixed, reproducible order.

The HTTP Server Is Not Node’s HTTP

Pulse 1.x had a limitation:
HTTP handlers ran outside the deterministic scheduler.

Pulse 2.0 fixes this completely.

import { createServerWithScheduler, spawn, sleep } from 'pulselang/runtime';

const server = createServerWithScheduler(async (req, res) => {
  const value = await fetchSlowValue();

  spawn(async () => {
    await sleep(500);
    console.log("background work");
  });

  res.writeHead(200);
  res.end(JSON.stringify({ value }));
});

Inside the handler you can use:

spawn
sleep
channels
select
structured concurrency

Each request gets its own isolated scheduler context.
Kill the request → all its tasks get cancelled automatically.

This is the kind of thing you normally need a custom Go server for.

⸻

Debugging Without Pain

Pulse includes an Inspector that produces consistent snapshots of the runtime:

task tree
channel states
select waiters
scheduler time
performance metrics

Everything is deterministic and serializable.

These snapshots feed into:

PRS (Pulse Runtime Server)
The future VSCode debugger extension

There is no “async black box”. Everything is visible.

Real-World Stress Testing

Pulse was tested with:

1000 concurrent tasks
nested channel topologies
worker pool patterns
HTTP burst load
SSE realtime streams
batch processing apps
retry/backoff workflows

Results were consistent across runs, including under adversarial stress.

Pulse passed:

98 runtime tests
14 PRS tests
12 debugger tests
12 HTTP client tests
100-run determinism
232K jobs/sec worker benchmark

Memory remained stable, cancellation cascaded correctly, no deadlocks were observed.

What Pulse Is (And Isn’t)

Pulse is not a TypeScript competitor.
It’s not a new language with its own ecosystem.
It’s not trying to replace Go or Rust.

Pulse is:

A deterministic runtime
A concurrency model
A set of APIs that sit on top of JS
A scheduler that removes async randomness
A predictable foundation for real backend systems

If you’re building APIs, worker queues, realtime apps or orchestrators, Pulse gives you the tools JavaScript never shipped with.

Want to See It?

Documentation:
https://osvfelices.github.io/pulse/

Repository:
https://github.com/osvfelices/pulse

Final Thoughts

Pulse 2.0 is the result of many hours of testing, rewriting, auditing and verifying the same principle:

Concurrency doesn’t have to be unpredictable.

JavaScript developers deserve a runtime that behaves the same in development, staging and production.

If you want to try Pulse, clone the repo, run the examples, break things, open issues, or contribute ideas.

Pulse 2.0 is stable, battle-tested, and ready for real workloads.

Pulse 1.5: A Deterministic Runtime You Can Actually Rely On

osvfelices — Wed, 19 Nov 2025 14:33:51 +0000

After a long cycle of refactoring, cleanup, and verification, Pulse 1.5 is finally out. This release focuses on one thing: making the runtime fully deterministic, predictable, and stable for real work. No magic tricks. No vague ideas of “maybe this works.” Everything is now measurable, testable, and reliable.

If you tried Pulse early on, this is the version that fixes the rough edges, standardizes the APIs, and brings the runtime to a place where you can actually build things without guessing how the scheduler will behave.

What Pulse Tries To Solve

JavaScript async is powerful, but it can also be chaotic. Tasks interleave in ways that are hard to reason about, timing bugs appear randomly, and reproducing issues can be painful. Pulse was created to give developers a model where:

The same input always produces the same execution.
Concurrency behaves in a predictable way.
Channels, select, and tasks follow deterministic rules.
Async code can be tested without racing conditions.

Pulse 1.5 is the first version where all of this is solid.

What Changed in Pulse 1.5

A fully deterministic scheduler

The scheduler is no longer a mix of helpers. It is now a proper deterministic engine:

Logical time is advanced tick by tick.
Tasks are executed in a stable order.
Sleep operations follow predictable wake times.
Channel operations follow strict FIFO rules.
Select always resolves using well defined priority rules.

There are zero hidden timers or tricks. Everything is explicit.

A complete internal cleanup of concurrency primitives

Channels, select, spawn, sleep, and task lifecycles were rewritten so they behave exactly as documented. No shortcuts. No undefined behaviors. All operations now return consistent data structures and error shapes.

Stable and copy paste friendly documentation

All documentation examples were updated to sync with the actual runtime:

All examples now use the real version of select.
No more old syntax from early experiments.
No more DeterministicScheduler references.
All examples compile and run exactly as written.

In short, if you copy it, it works.

A complete refactor of the scheduler internals

The runtime now has:

A SchedulerCore base class.
A GlobalScheduler for CLI tools.
A unified task model.
A predictable microtask flush mechanism.
Task completion promises.
Task trees for parent and child relationships.
Automatic cancellation and cleanup.

This gives us a strong foundation to build the next major feature: server-side scheduling.

Fixes across the entire codebase

We removed every broken, outdated, or inconsistent piece of the concurrency API. Select now returns the correct values everywhere. Channels clean themselves up when closed. Error handling is consistent.

All tests pass with zero tolerance for failure

All deterministic scheduler tests pass.
All channel tests pass.
All select tests pass.
New tests were added for determinism, task ordering, and edge cases.
All examples were rebuilt and verified.

Pulse 1.5 is now stable enough to build real tools and CLI applications without surprises.

What Pulse 1.5 Cannot Do Yet

I have to be clear. HTTP handlers still cannot use Pulse primitives like spawn, channels, or select. HTTP still runs on the Node event loop and is not yet integrated with the deterministic scheduler.

The next version will solve that.

What Comes Next: Runtime 2.0

The next step is a full rewrite of how Pulse interacts with Node. This is a large project and will take time, because it requires:

A cooperative scheduler that yields to Node.
A request scoped scheduler for HTTP.
Safe and predictable task cancellation.
Pools of schedulers for high concurrency.
Deterministic execution inside each request.

This is a major change, and it is happening now.

If you want to help

If you tried Pulse before, I would really appreciate it if you could try version 1.5. I spent a lot of time fixing everything that felt unstable or unclear. This release is much stronger, and your feedback is very helpful for shaping Runtime 2.0.

You can check the docs here:
https://osvfelices.github.io/pulse/

How to try it out

npx create-pulselang-app my-app  
cd my-app  
node bin/pulse run server/main.pulse

If you find something broken, unclear, or surprising, please open an issue or share it with me. Everything helps.

Final thoughts

Pulse 1.5 is not the final vision of the language. It is the version where everything becomes solid and predictable. Before adding new features or making HTTP a first class part of the runtime, we needed a foundation that we can trust. This version finally delivers that.

If you try it, thank you. Improvements only happen with real usage and honest feedback.

Building Pulse — a small language for deterministic concurrency in JavaScript

osvfelices — Wed, 12 Nov 2025 09:44:47 +0000

Over the last few months, I’ve been working on something I’ve always wished JavaScript had by default: deterministic concurrency.

In most cases, JS async behavior depends on the event loop, Promise.race, or microtasks. That means timing, order, and scheduling aren’t truly predictable — even if your code looks flawless. Small differences can change execution order in ways that are hard to trace.

Pulse is a small experimental language that compiles to JavaScript (ES Modules) but runs on its own deterministic runtime. Under the hood, it’s reactive like Solid or Svelte, but it also brings in Go-style concurrency as a first-class concept.

Why I built Pulse

I spend most of my time switching between JavaScript and Python. I wanted something that felt as expressive as JS, but with concurrency I could actually rely on — no hidden race conditions or random task order.

When I say deterministic, I mean that the same program should behave the same way every time it runs. No invisible timing gaps, no unpredictable behavior.

Pulse started as a small experiment to explore what a fully predictable async model could look like inside the JS ecosystem. Over time, it grew into a full compiler, runtime, and standard library.

What’s new in 1.0.2

This release makes the runtime stable enough for real-world async workflows.

Deterministic scheduler (no Promise.race, no setTimeout)
for await ... of channel now works — channels are async iterable
spawn keyword for lightweight concurrent tasks
select {} statement with stable, source-order priority
Parser now supports optional semicolons
All examples from the docs compile and run
Fully reproducible npm package

You can install it now:

npm install pulselang

How it works (simplified)

A channel in Pulse works like a tiny pipe between concurrent tasks. When one side sends a message, the other side receives it in exact order. No event-loop juggling, no task stealing, no race conditions.

A scheduler runs all tasks in a cooperative round-robin queue — it decides precisely who runs next and when. That’s what ensures deterministic behavior: every run produces the same result.

Pulse doesn’t rely on any of JavaScript’s non-deterministic primitives. No microtask queue, no random scheduling — everything is explicit and predictable.

Example

import { DeterministicScheduler, channel } from 'pulselang/runtime'

const scheduler = new DeterministicScheduler()
const ch = channel()

scheduler.spawn(async () => {
  for (let i = 1; i <= 3; i++) {
    await ch.send(i)
  }
  ch.close()
})

scheduler.spawn(async () => {
  for await (const value of ch) {
    print('received', value)
  }
})

await scheduler.run()

Expected output:

received 1
received 2
received 3

All of this compiles down to plain ES Modules, so you can use Pulse with Node.js (v18+).

Determinism test rig

Before publishing version 1.0.2, I ran full fuzz and soak tests:

100/100 identical runs across buffered, unbuffered, and select scenarios
400/400 fuzz cases passed (FIFO ordering, select determinism, no lost wakeups)
19.4M runs at ~64,800 runs/sec — no memory leaks
No use of Promise.race, setTimeout, or setImmediate anywhere

Every .tgz package built from npm is bit-reproducible (same SHA-256 hash).

Try it

Docs & examples: https://osvfelices.github.io/pulse

Code: https://github.com/osvfelices/pulse

I’d love to hear what you think — especially if you enjoy runtimes, compiler design, or async patterns.

And if you can break it… even better. That’s how good runtimes evolve.