Dark
A startup effort around a service-oriented language and web development environment.
From the blog:
"Dark Inc has officially run out of money. Dark Inc is the company we founded in 2017 to build Darklang, a statically-typed functional programming language built to strip all of the bullshit from backend coding.
"To ensure continuity for users and fans, as well as to continue building what we regard as an important technology, Dark Inc has sold the assets – the Darklang language, the blog, the hosted service, the Discord, etc, darklang.com, etc – to a new company started by Dark Inc's former employees.
"The new company, Darklang Inc, was started recently by Stachu and Feriel to continue building Darklang in its new exciting direction. Rather than be tied to a single proprietary cloud backend and editing environment, Darklang will be open sourced, and designed to safely run anywhere - your laptop, your cloud, our cloud, etc."
Docs
Events
What is an Event?
Events are generated any time a handler calls emit or automatically by a cron handler on a set interval. They have a specific destination handler and a lifecycle of processing. Events are stored mutably in Postgres, in the events table, with each event being updated as it goes through the processing pipeline. See the events schema for full details, but events importantly have the following attributes:
statusis the current state of the event, beginning withnew. See "Event Lifecycle" below.canvas_id,nametogether specificy the exact handler (name) on which canvas to execute when this event is processed.valueis the emitted value (DObj) that was emitted by the handlerdelay_untilis used to delay processing of an event until a specified time, frequently for error conditions.retriescounts the number of times this event has been retried on error
Event Lifecycle
An event's status is a FSM that begins in the new state. new events are created either by a handler (HTTP or worker) calling emit or when the cron-checker process determines that a cron handler's scheduled time has elapsed.
Next, the queue-scheduler transitions the event to scheduled based on it's scheduling priorities. The scheduler exists to ensure fair processing of events, avoiding problems like head-of-line blocking that come from having a single, global queue for all handlers across the platform. See "Event Scheduling" for details.
The queue-worker processes actually execute the Dark code that is targeted by each event. On completetion, the event transitions state, recording it's value if successful. See the follow state diagram for a complete picture:
Here's a sequence diagram showing the various system components involved. Each entity is run as a separate process (in a separate k8s pod, with a different replica count).
Event Scheduling
Event scheduling is currently very simple: every second, the scheduler schedules any events that are 1) new and 2) are passed their delay_until time.
Tags: language services
Last modified 13 August 2025