Gray is available for production migrations

Grayworth has opened commercial access to Gray through a hands-on preview for production server applications. Customers bring an existing API, worker, gateway or data service; Grayworth moves that workload into Gray and supports the deployment through cutover.

The engagement is designed around working software rather than a language demonstration. Grayworth establishes the current service contract, recreates it in Gray, validates response and failure behavior, and runs the new service under production-shaped pressure before traffic moves.

Gray is developed and commercially published by Grayworth. The same team owns the language, virtual machine, native backend, networking stack, database path, developer tools and release process.

One product across the server path

Gray combines Live, Adaptive and Static execution with HTTP/1.1, HTTP/2, WebSocket, TLS, structured tasks, readiness-driven PostgreSQL, JSON, classes, packages, a formatter and a language server. Eligible typed code can lower through Gray’s versioned native runtime ABI while unsupported code retains VM fallback.

That vertical design lets Grayworth tune the application language and the pressure-critical runtime together. A database wait, connection deadline, worker replacement or native transition is part of one product contract rather than an integration assembled separately for every service.

Adaptive mode provides the production replacement path. Gray compiles a candidate, waits until the new worker is ready, publishes it, and drains the previous worker while preserving in-flight work.

How a customer engagement runs

The first step is a workload review: application boundaries, traffic shape, dependencies, data contracts, deployment topology and the result the customer needs. Grayworth then defines the migration plan and the production acceptance criteria.

During implementation, the original service remains available. Grayworth builds the Gray version, exercises correctness and failure cases, records corrected latency and resources, and prepares a side-by-side cutover with a rollback path.

The finished engagement includes the Gray application, deployment guidance, a reproducible operating record and direct runtime support. The product roadmap is tied to the workload the customer is actually shipping.

Commercial access starts with the service

Grayworth is accepting server applications where integrated HTTP, TLS, JSON and PostgreSQL can replace meaningful runtime assembly or pressure cost. Production APIs, internal services, gateways and workers are the strongest starting points.

Teams can begin through the commercial preview page with the current stack, service shape and performance or deployment goal. Grayworth scopes and prices the engagement directly.

Read on Grayworth News

Three routes completed the full hour

Gray’s Static-mode route matrix completed three sequential one-hour qualifications: plaintext HTTP, native JSON and a parameterized PostgreSQL query. The complete run lasted 10,858 seconds, including warmup, settling and transition work between routes.

The runner performed an exact-response preflight before each load phase. During the hour it preserved wrk2’s corrected-latency output, sampled the Gray process after connection ramp, and failed the route if delivery, response status, process health, memory growth or file-descriptor growth violated policy.

Plaintext achieved 49,997.81 requests/s against 50,000 requested. Corrected p50 was 1.34 ms, p99 was 7.00 ms and p99.9 was 23.87 ms.

JSON held the same operating shape

The JSON route encoded a new response for every request through Gray’s native JSON path. It achieved 39,993.57 requests/s against 40,000 requested, or 99.984% delivery.

Corrected p50 was 1.31 ms, p99 was 4.09 ms and p99.9 was 17.30 ms. The Gray process remained at 10,316 KiB RSS across all 358 steady-state samples, with 262 open file descriptors and zero measured growth.

The plaintext process produced the same resource result: 10,284 KiB RSS in every steady-state sample and no descriptor growth.

PostgreSQL exposed the queue

The original PostgreSQL route delivered 3,999.85 requests/s against 4,000 requested with flat resources, but corrected p99 reached 802.82 ms and p99.9 reached 1.55 seconds. The route delivered the work; it did not deliver an acceptable tail.

That result identified a blocking architecture in the first database path. Each synchronous query occupied a reactor worker until libpq returned, allowing requests to queue even while CPU remained available.

Grayworth subsequently replaced that path with readiness-driven libpq and compiler-hidden handler continuations. The later continuation qualification is reported as a separate product milestone rather than being substituted into this original record.

The record is reproducible

The report records the Gray binary SHA-256, application and runner hashes, execution mode, duration, requested rates, connection count, CPU topology, database configuration and all route summaries. The publication renderer refuses incomplete or tampered matrices.

This is a same-host Gray product qualification, not an official TechEmpower result or a universal language ranking. Its purpose is to establish sustained delivery, corrected latency and resource stability for the declared applications and environment.

The raw comparison data, methodology and route report remain linked so readers can inspect the result behind the headline.

Read on Grayworth News

Database waits disappear from handler syntax

Gray HTTP handlers can now call PostgreSQL in direct source order while the compiler and runtime preserve the suspended continuation. The source reads like a synchronous query, but the reactor is released whenever the database socket is not ready.

The application does not maintain a pending-request map, write a polling loop or assign every database wait to a general worker. Gray captures the handler state, associates it with the nonblocking libpq operation and resumes the exact continuation when the socket advances.

The result is a server model in which direct code and cooperative I/O are the same product feature rather than competing programming styles.

Readiness runs through the whole connection lifecycle

Connection creation uses PQconnectStart and PQconnectPoll rather than blocking the process. Query execution sends work nonblockingly, consumes input only when the database socket is ready and returns the connection to the pool after the complete result is decoded.

When all pool connections are occupied, new work waits in the Gray scheduler instead of failing immediately or consuming task-worker capacity. A cancellation discards the active connection and replaces it safely before another request can inherit uncertain protocol state.

Typed query failures resume through Gray’s normal error path. Live, Static and Adaptive modes preserve the same language behavior.

The first qualification cleared 8,000 requested

The Static fixture used PostgreSQL 16, a pool of 64 connections, four wrk2 threads and 256 persistent HTTP connections. At 8,000 requested requests/s, Gray achieved 7,961.48 requests/s, or 99.519% delivery.

Corrected p50 was 1.43 ms, p99 was 4.60 ms and p99.9 was 8.74 ms. The sampler observed as many as 164 simultaneously suspended handlers and no general task workers.

After the run, active tasks and continuations returned to zero. RSS and file-descriptor counts remained within the gate’s declared limits.

Failure behavior shipped with the fast path

The protocol suite exercises overlapping database handlers in Live and Static modes, typed errors after suspension, independent HTTP/2 multiplexing, automatic 404 and 500 responses, and Adaptive replacement while an old handler remains in flight.

Cancellation tests verify that unfinished database work cannot leak a connection back into the pool. Sanitizer builds cover the same ownership path, and the optimized suite proves the result through the actual HTTP reactor.

Real service capacity will still depend on query cost, database placement, schema, pool size and topology. What changed in Gray is the architecture: one waiting query no longer owns the HTTP reactor.

Read on Grayworth News

Native loops now preserve Gray semantics

Gray’s x86-64 backend can lower typed loops, local mutation, integer comparisons and control flow into machine code through the documented native runtime ABI. Unsupported functions continue through verified VM fallback.

The backend does not accept a loop merely because it can encode a backward branch. Every generated backedge calls the runtime’s stop-token safepoint and returns a structured cancellation exit when work should stop.

That contract keeps native execution inside Gray’s structured task model. A hot loop can lose bytecode dispatch without becoming an uninterruptible island inside the process.

The same loop ran 25.918 times faster

The diagnostic computed an identical 100-million-iteration integer sum in fresh, CPU-pinned Gray processes. One policy enabled native lowering; the other disabled the JIT and executed the same function through the VM.

Seven accepted samples produced a 210.511 ms native median and a 5,456.099 ms VM median. Dividing those medians yields a 25.918× end-to-end improvement for this workload.

The measurement includes a stop-token safepoint on every loop backedge. The reported gain therefore includes the cost of retaining cancellation rather than benchmarking an unsafe stripped-down loop.

Cancellation is part of the differential

A dedicated test starts a typed loop with a nine-quintillion-iteration ceiling, waits 20 milliseconds, requests cancellation and requires a CancelledError. The test passes with native lowering enabled and with interpreter-only execution.

Live JIT, Live VM, Static JIT and Static VM produce the same result. ASan and UBSan builds exercise native relocation, generated frames, structured exits and the spawned-loop cancellation path.

The runtime ABI identifies exit kind, ABI version, source function and instruction. Native calls therefore preserve source-located errors and cancellation identity as execution returns to the VM.

The benchmark marks backend progress

This is a Gray-native-versus-Gray-VM diagnostic. It does not compare Gray with C++, Rust, Go or another compiler, and it does not claim that every Gray application becomes 25.918 times faster.

The result demonstrates that VM dispatch was the dominant cost in an eligible sustained loop and that Gray’s backend can remove it without changing the cancellation contract.

Broader value lowering, more native call paths and additional platform backends remain active compiler work. Each expansion keeps the same differential rule: native execution must match the VM before its speed is accepted.

Read on Grayworth News