Engineering / Gray

Gray’s architecture

Live Gray runtime Connecting

Grayworth develops Gray’s language, bytecode, native compiler, networking, database continuations, and browser delivery tools.

Execution path

01Gray sourceTyped or immediate

02CompilerVerified bytecode

03Native backendW^X security · SIMD · executable

04ReactorHTTP, TLS, DB

05ResponseBinary-safe

Implemented surface

Platform components

Language, runtime, native execution, I/O, data, and tooling move together instead of arriving as separate infrastructure decisions.

LanguageClasses, modules, collections, BigInt, regex, typed errorsImplemented

ExecutionLive, Adaptive, Static, JIT, bounded AOT, SIMD and program-specific native executablesLatest work

NetworkHTTP/1.1, HTTP/2, TLS, WebSockets, epoll and kqueueImplemented

DataPostgreSQL continuations, SQLite, Redis, cache and sessionsImplemented

ToolingFormatter, linter, LSP, tests, docs, trace and profilerFoundation

PortabilityLinux release target with macOS native qualification; Windows IOCP remains openScoped

Runtime qualification

Runtime benchmarks

Gray is shown beside the same-host runtimes it was actually measured against: PHP-FPM, Node.js, Go, and Gray under the published plaintext qualification rule.

The claim is deliberately narrow: one fixture, one host class, exact responses, corrected latency, and a fixed acceptance boundary. It is evidence for this runtime path, not a universal language ranking.

one pinned server CPU wrk2 corrected latency exact-response gate p99 < 100 ms same digest-pinned image

Same host / plaintext

Throughput ceiling

higher is better

2× Gohighest qualifying requested rate before either delivery or corrected-p99 exits the acceptance band

PHP-FPM8k/s

Node.js12k/s

Go30k/s

Gray60k/s

Highest plaintext request rate meeting the qualification threshold
Runtime	Requested	Achieved	p99
PHP-FPM	8k req/s	7,961 req/s	48.03 ms
Node.js	12k req/s	11,940 req/s	10.04 ms
Go	30k req/s	29,844 req/s	5.68 ms
Gray	60k req/s	59,260 req/s	85.76 ms

Corrected tail latency

p99 acceptance boundary

lower is better

<100 ms at 60k/sGray remains inside the published corrected-p99 acceptance boundary

PHP-FPM48.03 / 48.03 ms

Node.js6.46 / 10.04 ms

Go2.84 / 5.68 ms

Gray3.13 / 85.76 ms

Plaintext p99 latency at shared and qualifying pressure
Runtime	p99 at 8k/s	p99 at qualifying point
PHP-FPM	48.03 ms	48.03 ms at 8k/s
Node.js	6.46 ms	10.04 ms at 12k/s
Go	2.84 ms	5.68 ms at 30k/s
Gray	3.13 ms	85.76 ms at 60k/s

Performance work

Profiling and latency

Latency profiles turn architecture choices into visible operating constraints.

Database architecture

802.82 ms
became 4.60 ms.

Synchronous PostgreSQL exposed the blocked-reactor queue. Readiness-driven libpq removed the architectural bottleneck. Compiler-hidden continuations then restored ordinary-looking handler code without assigning waits to general task workers.

p99 by architecture stage

PostgreSQL continuation path

lower is better

174× lower p99from the original synchronous path to compiler-hidden continuation

Synchronous802.82 ms

Readiness-driven32.80 ms

Compiler continuation4.60 ms

Database p99 latency by architecture
Architecture	p99 latency
Synchronous	802.82 ms
Readiness-driven	32.80 ms
Compiler continuation	4.60 ms

Separate qualification runs documenting the architectural progression. Not a controlled causal A/B.