The Dark language and coding platform launched this week, and I couldn’t be more excited. (I had half a mind to fly to St. Louis and see them launch in person at StrangeLoop.) For a while, I’ve been following what Paul Biggar (founder of CircleCI) and Ellen Chisa (a product leader whom I respect) have been building in Dark: a product to democratize software development and make it easier for everyone, particularly for folks who haven’t previously coded before. The frustration Paul expresses in his launch video –- about infrastructure and today’s delivery process getting in the way of delivering code – resonated deeply, particularly when I think about how we used to “deploy” in the early days of web software engineering (FTP-ing PHP files to production). Obviously, that was risky.
Today, however, in the name of risk reduction, we have complicated CI/CD pipelines, Kubernetes and rolling deploys, thousands of lines of AWS CloudFormation and Chaos Monkey to kill it all, and a million other extraneous guardrails that developers today need to learn just to get something into production. An end-to-end, low-friction developer experience such as what Dark is providing is certainly appealing, not just for new developers, but for old folks like me who would like to program again occasionally but find today’s frontend and backend stacks daunting.
In this post, I’d like to give my thoughts in just three areas: what did Ellen and Paul and their team build? In what way could they reasonably go to market? And also – to address some of the early criticism about Dark, e.g. that it’s a closed ecosystem and not open source – does it matter? Are there are other valid criticisms and how could they overcome them?
What did they build?
Dark (a totally un-Googleable name, by the way, not that I know anything about that) is a complete programming environment for backends that comprises a new language, an in-browser integrated development environment (IDE) with which to write that language, code hosting (including a built-in database), and deployment mechanism to get from the IDE to hosting. The deployment semantics are the most interesting because deployments are implicit, not explicit: every syntactically correct line of code you write is automatically and immediately deployed in under 50ms. I’ll leave out all the details about how this works and why it’s safe – if you’re interested in the implementation, go watch Paul’s video.
This is exciting because it restores programming and deployment to the experience that we all used to have before the Internet exploded in popularity. Like I said, I used to “deploy” by FTP-ing interpreted language files to production, and it was a great experience, because you could get immediate feedback as to whether something was working. This is terribly unsafe, because if you make mistakes in your code, they show up immediately in production — not to mention that this workflow makes it impossible to collaborate with other people. But for the lone developer, the experience is glorious.
Dark focuses on providing a similar experience but puts all the safety and collaboration guardrails under the hood. Like Rust, the Dark language makes syntax errors nearly impossible (although obviously, logical errors are still possible). And it enables forwards and backwards code compatibility by versioning everything automatically, including method signatures and invocation semantics, such that callers invoking older versions of a method will continue to do so until they can be upgraded to work with the new one. That’s the promise, at least. Obviously, one of the challenges they have is “will this work over time as teams of people actually use it?” But that is the promised developer experience, and it, like the bad old days of PHP and FTP, is amazing.
How could they go to market?
That’s what Dark has built. The next question is “who could it be ostensibly for, and who would be willing to pay for it?” Dark is not going to be for everyone; many developers want to have more control over deployment processes and are accustomed to writing code in mainstream languages. Frankly, there is already a whole industry dedicated to creating and maintaining deployment complexity (Paul, as the co-founder of CircleCI, is as culpable as anyone ;-)), and many an engineer has built a career on this. (I’m also looking at you, Jenkins.)
Dark is also currently only for backends. The React frontend Ellen uses in her demo had to come from somewhere. I see other people like Glitch trying to solve the frontend complexity problem — just try to understand what it takes to be a frontend developer in 2019 — so perhaps there’s a natural partnership between the two firms.
Where I really see Dark shining is serving cohorts of people who don’t currently code today, don’t work in an engineering function, but have an increasing need to write code occasionally as part of their jobs – say, if you’re a financial analyst or even a product manager/product marketing manager. (Hello.) This is the target market today of categories like Robotic Process Automation (RPA) and low-code/no-code platforms like Pega or Salesforce’s force.com. Many of these products, however, are still unfriendly to the population I described; too complicated, too many steps, or in some cases, are 20-30 year old legacy products rebadged as “low-code” purely for marketing reasons. I think these are incumbents ripe for disruption.
What are some of Dark’s challenges? Which ones matter?
Obviously, there are a lot of folks complaining about Dark not being open-source, that it’s a closed ecosystem with high vendor lock-in, and so on. These facts are 100% correct and yet none of it matters because I don’t see Dark as being for the existing cohort of developers today. It’s for the larger unaddressed market of developers that don’t exist yet – the person who has yet to write their first line of code. If Dark can make the development experience so easy that they capture even 10% of enterprise users who are blocked by not having traditional development resources and are willing to self-serve, it adds up to quite a bit of revenue.
One gap in Dark’s public business model so far is how they will price and to a lesser degree, package their offering. I expect they will price based on seats and with an all-inclusive price that includes code hosting. After all, if their target user is someone who doesn’t identify with the label “developer”, simple packaging and pricing will be key. If Dark is smart, they’re using some kind of on-demand code execution engine (like AWS Lambda) that allows them to realize profit based on the difference between a premium monthly per-seat price and the low costs of relatively infrequent code execution by “business” users. (They might eventually need to consider a resource execution limit to deliberately steer heavy, traditional developers away from their solution.)
What’s next?
As I said in the introduction, I was excited enough about the launch of Dark that I wrote this whole blog post about it. So far, the team has executed brilliantly, focusing on development ergonomics for folks who I expect aren’t traditional developers. The amount of engineering work needed to pull off what they’ve pulled off is incredible. Now, I think they need to define their target market and pursue that with zeal. That’s probably going to involve heavy investments in increasing safety (e.g. unit testing, collaboration, interfaces to unpack the implicit versioning magic under the hood, etc.) as well as developing a community from scratch in a population that doesn’t code today.
There’s also the question of how some of the sector incumbents I mentioned previously will react. How much will existing low-code/no-code vendors try to market aggressively against it? The key differentiation thus far is in the developer experience, and if Dark continues to nail that and out-innovate others (they have a 12-16 month advantage right now), then the future is bright for them.
I think they need to define their target market and pursue that with zeal. That’s probably going to involve heavy investments in increasing safety (e.g. unit testing, collaboration, interfaces to unpack the implicit versioning magic under the hood, etc.)