'Deployless'​ software and beyond with Dark’s founder. Plus, open-source or bust and dead coding languages.

A software development startup called Dark emerged from stealth this week to announce it raised $3.5 million to finally bring to light the all-in-one programming language, editor and infrastructure package it had been building for two years. With an eventual goal to "make coding 100x easier," the splashiest feature Dark will launch with is "50ms" deployment – or what has been dubbed by some early fans as "deployless" software development.

To find out more about the "deployless" software future we're headed for – and what more we can expect from Dark, in particular – I grabbed Dark founder and CTO Paul Biggar.

The Q & A below has been lightly edited.

How did you develop the idea for Dark? Did it come from some of your own frustrating experiences with building software?

It came from lots of places. One was thinking about cool side projects I wanted to build. Every time I'd get started, I'd see that after a few hours that all I had done was set up projects and hosting, and I hadn't written any interesting code. I typically gave up on the projects as a result.

When I was at CircleCI, I'd think about internal tooling that we wanted. Unfortunately, the cost of building that internal tooling never seemed worth the effort – there would be more infrastructure to maintain, more silos for data to live in, more things that could break and needed monitoring if they got into our workflow.

At the same time, I thought a lot about the language that we were using – Clojure – and how it had these really cool concurrency primitives. However, we found a mismatch with the cloud: If you turn off a machine which is waiting a few minutes to retry a notification, you lose the notification. So I realized that our languages were typically designed around single machines, and I started to think about a language where the runtime sat "above" the cloud. Essentially one that abstracted the cloud in the way that Java and most subsequent languages abstracted over memory.

These were a few of the, maybe, seven different lines of thought that led to creating Dark. I had been thinking about them for several years and eventually realized all the problems were the same one: that it was too hard to build software with the tools we have today.

Can you lay out some of the specific pain points that Dark's "deployless" architecture is hoping to remove from today's process of software engineering?

The most important thing in any technology company is the speed of iteration. We started with the idea of removing accidental complexity from coding, and a main area of accidental complexity is all the steps between writing code and it being available to test in production with customers. We asked ourselves: "What if this was instant?" And that became the root of the deployless concept. The obvious follow-up to that is: "How can we make that safe?" And we designed a system around that. The system pulls in everything – language, an editor and running all the infrastructure – because that's what it took to make it instant and safe.

The result is a 50ms deploy and a suite of continuous-delivery tooling that allows it to be safe and easy.

Which types of engineers and engineering teams will be the ideal users for Dark's platform – or at least the first versions of it?

Although Dark is eventually aimed at all software, we're initially targeting engineers who are building backends for frontend HTML/CSS/JS apps in React, Vue, etc. We have this thing we call the "Dark flow" where you build your backend and frontend together, passing data back and forth between the two. It's hard to convey, but it's a really magical experience.

We are testing as well with people building new services in existing microservices-based architectures, especially in companies that use many languages. The fact that Dark hosts the infrastructure means that the time to spin up a new project – and crucially the effort to maintain it – is dropped to almost nothing.

How do you see code reviews for QA and security changing in a "deployless" software future?

A big change for code review will be the ability to actually run the code in production, behind a feature flag. Many companies are working on enabling dev and staging environments from branches in traditional workflows, and this just comes for free from Dark.

Security also improves significantly. Today, there's a delicate dance of how to share credentials and control access to code with team members, especially with distributed teams and contractors. The current situation is that you can provide access to code at the repo-level. In Dark, you'll be able to set extremely precise access control – and you'll need it because the amount of data available about the run-time system will be so much greater.

What more should engineers interested in Dark know about its programming language?

Our goal with our programming language is to be uninteresting. The interesting things come from the intersections of the language and editor, editor and infrastructure and language and infrastructure.

We've based our language primarily on OCaml and Elm, and a little bit of influence from Clojure, Ruby, Haskell and Rust. We picked these because they allow incredibly powerful abstractions with extremely simple constructs, though they may be unfamiliar to many coders. Primarily, we believe that the language needs to be simple to reason about and understand. We use immutable values and functional programming as our core. In particular, this allows us to eliminate Nulls and Exceptions, which are both the plague of modern OO languages.

The general campaign you've set with Dark is to "make coding 100x easier" and empower "a billion people to build software." What other features are you dreaming up to help reach those goals?

The main one that we haven't gotten to yet is making calling APIs really accessible. We think it should be as easy to use an API as it is to call a function. Unfortunately, calling a remote API in a distributed system is not simple, and requires dealing with rate limits, retries, backoffs, complex auth, etc. We aim to make that as simple as we've made the rest of the platform.