RFC: Native async/await (coroutines) for V — making V competitive for I/O-bound workloads

[rroblf01]

Summary

I'm proposing native async/await support in V, and I already have a
working (synchronous) prototype. The goal is to let V programs handle
100K+ concurrent I/O-bound tasks (HTTP servers, database queries, file
processing) with a small number of threads, instead of being capped at
the number of OS threads.

This is a discussion first. I want to align with maintainers before
investing months in the state-machine transform.

Why this matters for V (not just for one use case)

V is already fast and simple, which makes it attractive for servers,
tools, and infrastructure. But today, concurrency in V is spawn/go,
i.e. one OS thread per task. That caps real-world concurrency at the
number of cores (typically 4–16) and adds context-switch overhead. For
I/O-bound programs — which are most server programs — this is the main
bottleneck, not CPU.

Other languages V competes with (Go, Rust, Zig, JS) all have cooperative
coroutines. V already has the building blocks (channels, spawn, fast
compilation). Adding async/await would let V compete in the
server/infrastructure space without giving up simplicity.

Concrete V programs that would benefit:

• veb / HTTP servers: 10K+ concurrent connections on a few threads.
• db.sqlite / db.pg / db.mysql: non-blocking queries, connection
  pools without thread-per-request.
• File processing / log pipelines: mmap + async read, zero-copy.
• Network proxies, crawlers, chat servers, game servers.
• CLI tools that do many parallel I/O calls (fetch, copy, transform).

What I'm proposing

async fn fetch(url string) string {
    resp := await http.get(url)
    return resp.body
}

fn main() {
    f1 := fetch('https://example.com/a')
    f2 := fetch('https://example.com/b')
    // both run concurrently; await blocks only until ready
    println(await f1)
    println(await f2)
}

• async fn foo() T returns Future[T].
• await expr suspends the coroutine without blocking the thread.
• spawn async fn() launches a coroutine on the scheduler.
• Cooperative scheduler (epoll/kqueue, later io_uring) drives tasks.

Prototype status

A first, conservative prototype already exists (in my fork of v, on the feature/async-await branch):

• async fn / await expr parse and type-check.
• async fn returns Future[T]; body is wrapped so callers get a Future.
• Future[T] is a shared handle, so await observes completion from
  background work.
• spawn_async(f) and sleep_async(ms) run work on background threads.
• await blocks until the Future is ready.

The prototype keeps synchronous semantics first, so it's safe to review
and adjust without risk.

Performance goal

The bar is: equal or better than today's synchronous/threaded model,
not worse. Concretely:

• Concurrency ceiling: from ~cores threads to 100K+ tasks.
• Per-task memory: target < 1KB (stackless state machines, allocated on
  the heap, GC-friendly).
• No regression in single-threaded throughput. State-machine overhead
  must be measured and kept in check.
• Benchmarks will follow the vself_speed.md methodology (paired runs,
  instructions retired, fixed fixture).

Roadmap (incremental, PR-sized)

1. Syntax + Future[T] type (done in prototype).
2. Checker: wrap async return types in Future[T] (done).
3. Codegen: track async functions (done).
4. State-machine transform in vlib/v/transform (the big one) — split
   into many small PRs, each with tests.
5. Scheduler + wakers (single-threaded executor).
6. Non-blocking I/O in net (epoll/kqueue, then io_uring).
7. GC safety + debugging + docs.

Each step will be a small PR with tests, not one monolithic change.

Open questions for maintainers

1. Are you open to async/await as language keywords, or do you
   prefer keeping async at the library level (vlib/x/async)?
2. If language-level: do you want an RFC approved before any PR, or are
   incremental syntax PRs acceptable?
3. Preferred coroutine model: stackless (state machines, lower memory,
   more compiler work) vs stackful (fibers, simpler, more memory)?
4. Should io_uring be a separate backend (-d/flag) or integrated into
   net behind a flag?
5. Any constraints I should respect (e.g. "no new keywords", "keep
   compilation fast", "don't touch thirdparty")?

What I'm asking for

• Direction on whether this aligns with V's goals.
• Feedback on the keyword/type design (Future[T], await, spawn).
• Any constraints I should respect.

I'm happy to adapt the design to whatever the maintainers prefer. The
prototype is intentionally conservative (synchronous semantics first) so
it can be reviewed and adjusted without risk.

Thanks!

[Jengro777]

Thanks for the detailed RFC and for having a working prototype already — that makes this much easier to discuss concretely.

I'd strongly suggest using Tokio (Rust) as the primary reference design when working through the open questions below. Tokio is the most battle-tested async runtime in a systems language, and V's constraints (fast compilation, simplicity, no GC-heavy design) are close enough to Rust's that many of Tokio's lessons transfer directly.

Concrete points where Tokio's experience is worth borrowing:

1. Stackless coroutines (state machines) over stackful fibers.
   Tokio chose stackless (async fn → compiler-generated state machine, polled by an executor). This matches your <1KB/task memory goal — stackful fibers typically reserve KBs per task. It's more compiler work, but your roadmap already puts the state-machine transform as the big item, so this is consistent. Recommend committing to stackless early so the transform design isn't reworked later.

2. Separate the "future" from the "executor".
   Tokio's key architectural split is:

· Future trait: poll(self: Pin<&mut Self>, cx: &mut Context) -> Poll — a pull model.
· Executor: drives futures, owns the run queue, handles waking.

Your prototype's Future[T] as a "shared handle + await blocks until ready" is closer to a push/blocking model. Consider adopting the poll-based contract internally even if the surface syntax stays await expr — it makes the waker mechanism (your roadmap step 5) natural rather than bolted on.

3. The waker mechanism is the hard part — budget for it.
   Tokio's Waker/Context is what makes epoll integration clean: the I/O driver registers interest, and when an event fires it wakes the task. If V's await is built on a blocking primitive instead, you'll end up with a thread pool underneath, which defeats the 100K-task goal. Recommend designing the waker (or V's equivalent, e.g. a TaskHandle + wake callback) as an explicit, early deliverable, not a late roadmap item.

4. Runtime layering: reactor + executor + timer.
   Tokio is explicitly three components:

· Reactor (I/O driver, epoll/kqueue/io_uring),
· Executor (scheduler),
· Timer (hierarchical timing wheel).

Keeping these as separate vlib modules (even if the syntax is unified) will make it far easier to test each in isolation and to swap backends (e.g. add io_uring later as -d use_io_uring). This also aligns with your question 4 — I'd vote for io_uring as a separate reactor backend behind a flag, not baked into net.

5. Multi-threaded executor vs single-threaded first.
   Tokio ships both (current_thread and multi-threaded work-stealing). Recommend: single-threaded executor first (your roadmap step 5), but design the Future/Task types so a work-stealing multi-threaded scheduler can be added later without changing user code. Tokio's Send + 'static bound on spawned tasks is what makes this possible — worth considering an analogous bound in V (or at least documenting why V doesn't need one, e.g. if the GC is shared/thread-safe).

6. On the keyword question (your Q1/Q2).
   Tokio itself is a library, and Rust's async/await are language keywords — the split works because the syntax is language-level but the runtime is pluggable (Tokio, async-std, smol). I'd recommend the same for V: async/await as language keywords (they're needed for the state-machine transform in the compiler), but the executor/reactor/scheduler as vlib modules (e.g. vlib/x/async or vlib/runtime). That keeps the language surface small and lets the runtime evolve independently — and it's a cleaner answer to "no new keywords" concerns than putting async at the library level, which would require macro/transform tricks the compiler may not support cleanly.

7. Cancellation and structured concurrency.
   Tokio's JoinHandle::abort, select!, and Drop-based cancellation are notoriously subtle. Worth deciding early whether V wants:

· Future cancellation (dropping a future cancels it), or
· explicit cancel(fut) — and whether spawn tasks are detached or joined.
Tokio's experience is that cancellation-safety is a per-operation property that must be documented for every await point. If V adopts await, this needs to be in the docs from day one, not added later.

8. Benchmarks: compare against Tokio, not just V's own baseline.
   Your perf goal ("equal or better than today's sync model") is necessary but not sufficient. Since the whole point is competing with Go/Rust for I/O-bound workloads, I'd suggest benchmarking a V async HTTP server against a Tokio-based Rust server (hyper + tokio) and a Go server on the same hardware/connection counts. That's the number that will actually convince maintainers.

Summary of concrete recommendations:

· Stackless state machines (Tokio model), not stackful fibers.
· Poll-based Future internally (pull model) with a real waker, even if surface syntax is await.
· Reactor / executor / timer as separate vlib modules; io_uring as a flag-gated reactor backend.
· Single-threaded executor first, designed for later work-stealing.
· async/await as keywords, runtime as library — mirrors Rust/Tokio split.
· Decide cancellation semantics early and document cancellation-safety per await point.
· Benchmark against Tokio/hyper and Go, not just V's own sync baseline.

Happy to help review the state-machine transform design when you get to roadmap step 4 — that's where the Tokio comparison will matter most.

[nunsez]

Thanks for the RFC.

The goroutines module already ships a GMP scheduler translated from Go's runtime.

Given that, have you considered extending goroutines instead of adding async/await?
Go's model solves the same problem - 100K+ I/O tasks without infecting functions.
You write plain sync code, and the runtime handles the rest.
async/await is viral: every function that awaits must itself become async, and it spreads.

Was this alternative considered? If so, what were the arguments against it?
I'd personally prefer V to stay simple.

[JalonSolov]

Look at the numbers on that page. async/await can handle thousands of routines... goroutines can handle millions. async/await requires 2 MB overhead per thread... goroutines need 2 KB.

Can you get async/await down to less than 2 KB per thread, while ramping up 100X on number of threads?

[rroblf01]

You're mixing up OS or thread-pool threads with async/await tasks. A standard thread pool thread has a 1–2 MB stack, sure, but async/await doesn't spawn a thread per operation. It compiles into a tiny state machine struct (often just tens of bytes) running on an event loop

Because of that, async/await actually handles millions of concurrent tasks with less memory per operation than a goroutine (which starts at 2 KB and can grow). Stackless coroutines use virtually zero stack overhead because there's no stack allocation at all—just a flat state machine

[JalonSolov]

None of this matters. Every time async/await has come up, the answer has been No.

goroutines (otherwise known as "coroutines" or "green threads") are what V uses and will continue to use. There is no "event loop" involved, just a runtime that understands how to multiplex goroutines onto system resources.

[rroblf01]

Fair enough—if that's the community consensus and the core design philosophy, then it is what it is. I just think it's worth acknowledging the trade-off: bypassing event loops and stackless models means V will likely lag behind other modern system languages in peak high-concurrency I/O performance down the road. But if keeping the Go-like simplicity is the ultimate goal, that's a deliberate choice.

[rroblf01]

Hello @JalonSolov

I’ve been looking around and it doesn’t seem like work on goroutines has begun yet. I’d like to be able to use this feature in my projects; should I go ahead and start developing it, and then show you a proof of concept for goroutines in V?