Dark is a programming language with an integrated editor and infrastructure for developing and delivering backend applications. Dark, made available for private beta in September, aims to simplify the development of backends by minimizing complexity.
Dark focuses on four primary infrastructure concerns: HTTP endpoints, datastores, background workers, and scheduled jobs. Infrastructure is implemented, hosted, and automatically scaled by Dark, abstracting the infrastructure configuration and implementation from the developer experience.
Application code is written in the Dark structured editor and the Dark programming language is tightly integrated with the editor and infrastructure. As a result, autocomplete in Dark is aware of the full application infrastructure. Live request by users can be viewed in the editor in real-time. Code changes are immediately deployed and then enabled with feature flags, eliminating the need for deployment pipelines while maintaining deployment safety.
InfoQ reached out to Dark cofounder Ellen Chisa to learn more about Dark’s philosophy and design.
InfoQ: How did the idea for Dark originate and what motivated you to create the company?
Ellen Chisa: My cofounder, Paul, and I came to the space in separate ways. For him, after years in software (including a PhD in compilers and founding CircleCI) he still felt the work needed to set up backends meant writing so much of the same boilerplate code and creating the same toolchains over and over again. For me, having been in consumer product companies, I saw too many instances where infrastructure and tooling prevented us from shipping to customers as quickly and effectively as we wanted to.
InfoQ: When describing the problems Dark is trying to solve, you reference Frederick P. Brooks’s concept of "accidental complexity". What elements of today’s accidental software complexity is Dark addressing?
Chisa: Yes! Accidental complexity originally was meant to refer to any task related to making code work on a computer (like memory management) rather than tasks for what you were trying to write. At the time, Brooks argued that you couldn't make things an order of magnitude better because most tasks weren't accidental. Today, with the movement towards public clouds and distributed systems, we see developers spending a ton of time on challenges related to the system rather than to business logic: infra, deployment, API retry logic, dev/production parity, and dependency management just to name a few. We often describe Dark as a "lack of complexity" rather than something specific.
InfoQ: Dark makes extensive use of feature flags, from dev environments to database migrations. Can you tell me more about this design decision and why it’s such an important feature for Dark?
Chisa: Feature flags are a best practice in the modern software development cycle and a big shift to how we ship software. Historically, we used deployment to decide when users got a piece of software (when it was in prod). With feature flags, we have much more nuance. We can give features to a test group or a specific set of users. By adding feature flags, deployment itself became accidental complexity rather than about delivery to users. In Dark we see the feature flags as a fundamental part of the language. They can be used the classic way for rolling out to users, but also as a way of collaborating with your team.
InfoQ: How does Dark balance removing complexity from the user while still providing users adequate control and observability into their applications?
Chisa: Whenever we're thinking about an experience in Dark, we think about the core of what a developer is trying to do, and its potential impact on the software they're delivering. For instance, consistency or availability might be more or less important for a given service. We also prioritize heavily based on feedback from developers who are using Dark.
Dark is in private beta, open to projects that are well-scoped and ready to be started. To apply for private beta access or learn more about using Dark, visit the Dark website.