What It Takes to Build a Programming Language and a Company at the Same Time
When we started building Gray, it was tempting to think of the language as the product and Grayworth as the company that would eventually package it. That split did not survive contact with the work. A server language needs installation, documentation, release evidence, deployment paths, and someone accountable when those pieces disagree. We were building the company every time we made a technical promise.
Grayworth develops the Gray language, an integrated server language and runtime. Our Co-Founder and CTO, Annabella Proctor, leads engineering across the language, runtime, networking, database, tooling, and deployment systems. We chose that broad surface because the seams between those systems are exactly where server development becomes harder than the application idea itself.
The familiar startup advice is to begin with one sharp pain. Ours is the accumulated cost of fragmented server development. A request handler, a background task, a PostgreSQL notification, a Redis subscription, and a direct process connection often require different libraries and mental models. None of those pieces is necessarily bad. The friction appears in their composition: different cancellation rules, different buffer policies, different shutdown behavior, and different debugging stories.
RC14 is our clearest attempt yet to turn that pain into a product principle. It creates bounded, multiple-producer/single-consumer channels and uses the same channel shape for task communication, PostgreSQL LISTEN/NOTIFY, Redis or Valkey pub/sub, and direct Gray-to-Gray connections. When a developer moves from a local producer to a database event or a peer process, the surrounding infrastructure changes, but receiving a value does not become a completely different programming exercise.
For a small company, that scope is risky unless it is governed by strict boundaries. So RC14 does not use “simple” to mean “unbounded.” Channel capacity is explicit. Backpressure does not silently drop a message. A closed and drained channel ends normally; a send after close fails clearly. Connection failures carry a close reason. Direct peers authenticate through TLS and a pre-shared token, and they appear as two unidirectional channels so send and receive retain one meaning.
This is also why our company and language must be built together. A language feature is only trustworthy when documentation, tests, qualification, release evidence, and product communication agree about what it does. Grayworth cannot outsource that coherence to a future ecosystem. It has to be an operating habit now, while the system is young enough to form those habits deliberately.
That includes admitting what RC14 does not finish. Its channel waits are cancellable, but they currently park native operating-system threads instead of cooperatively suspending VM continuations. Cooperative scheduling for waits is planned for a later milestone. Direct Gray-to-Gray TLS is supported in Live mode and macOS Static mode, but not Linux Static mode because of a qualified glibc/OpenSSL static-linking boundary. Channels themselves, PostgreSQL notifications, and Redis subscriptions remain available across those modes.
Founders are often encouraged to polish the story until the rough edges disappear. Infrastructure founders should resist that instinct. A limitation hidden in marketing does not disappear in production; it simply arrives later, when a user is paying the debugging cost. We would rather name a boundary, qualify it, and give the next architectural step a real design cycle.
We use bold language about RC14 inside Grayworth because the design changes how we think about the product. The more grounded version is this: a server language can reduce the number of communication models a programmer actively manages without pretending the underlying systems are identical. We believe that can change day-to-day programming. The belief still has to earn its value in developers' hands.
The founder lesson extends beyond Gray. Vertical integration is valuable only when it removes user-visible complexity and makes responsibility clearer. Owning more layers creates more ways to fail. It is justified when one team can establish common semantics, verify them together, and publish the exceptions rather than sending users between maintainers.
Our near-term goals are therefore architectural and institutional at once. We want cooperative channel suspension, broader NativeIR coverage, stronger cross-platform qualification, clearer release evidence, and a developer path that remains comprehensible from installation to deployment. Each goal must become a testable capability before it becomes an unqualified claim.
That changes how we think about growth. The first valuable users of a language do more than increase a signup number; they encounter combinations the core team did not predict. The company has to convert those encounters into documentation, tests, and durable contracts without letting every request fragment the design. We want an ecosystem, but not one built on ambiguity. A clear center makes extension safer because package authors and application teams can see which behavior belongs to Gray and which choices remain theirs.
Annabella's technical profile, ORCID record, and ISNI identity connect the founder to the work. Grayworth connects the work to a durable organization. Gray connects the organization to a daily developer experience.
The company and the language now give each other a useful constraint. Gray pushes Grayworth to make durable technical commitments. Grayworth pushes Gray to become more than an interesting compiler. Building both at once is slower in some places, but it gives users one accountable home for the system and its edges. For us, that is the business model as much as it is the engineering model.
