Why aren’t there more programming languages startups?

This piece first appeared on the Akita blog in July 2021. At the time, I was founder and CEO of Akita Software, an API observability company backed by Andreessen-Horowitz.

Before starting Akita, I had been a professor doing research in programming languages at Carnegie Mellon University. While in academia, I spent years contending with the question of why seemingly useful cutting-edge technologies take so long to reach mainstream developers—and why some never become popular at all. My take: what developers want is often different than what developers need. And because there is so much discourse around what developers want, discourse around what they need becomes secondary. This makes it look like there’s low adoption of necessary technologies, when we should really be spending more time talking about what developers need.

Since the original publication of this essay, Postman acquired Akita. This blog post represents a shared vision between Akita and Postman. If you want to see what we’re now working on together, you can sign up to be an early user of the Akita team’s beta Postman Live Insights here.

---

A few weeks ago, I moderated a panel where someone asked, “Why aren’t there more startups coming out of the programming languages community?”

This was at a panel about career paths, associated with the Programming Language Design and Implementation (PLDI) conference. What the person was asking was why we don’t see more cutting-edge programming language and software analysis technologies getting commercialized.

There’s clearly a lot of programmer pain. But why don’t we see more tech transfer of these “deep” technologies from research into industry? This is something I have been thinking about since I was in college, when I decided I wanted to spend my life making programmers’ lives better. Many other fields, from robotics to databases, have clearer paths to commercialization. But when it comes to new programming languages or software analyses, the path of tech transfer is often decades-long, if it exists at all. I thought about this as a programming languages PhD student, then as a professor, and now as the founder of Akita, an API-centric observability company based on applying software analysis techniques to API traffic.

But alas, I was just the moderator, so I had to focus on questions actually intended for the panelists. Last week, I did a Twitter thread answering this question. This post is an elaboration of that thread. I’ll talk about how, even though investment and buying for developer tools is on the rise, “deep tech” tools aren’t seeing their share of the growth. There are many things we can do to fix it—and I’d love to do that together.

In this blog post, I’ll focus on why we don’t see more high-growth startups focused on the kinds of languages and tools coming out of the PLDI community, the “deep tech” side of programming tools. There are many other kinds of developer tools that are doing great as high-growth startups. There are also other successful avenues of tech transfer (big companies; open-source projects) that I will not cover here.

Software teams are buying tools

There’s a popular narrative that companies don’t pay for developer tools (for instance see here), but this is decreasingly true. Even a few years ago, people were writing about the challenges for venture-backed dev tools companies and how it was hard to build big businesses around developer tools.

By 2021, it’s generally agreed that there’s money in developer tools. Over the last few years, we watched Salesforce acquire Heroku for US$212 million and Microsoft acquire GitHub for US$7.5 billion. Today, the private company Postman is valued at US$2 billion and HashiCorp is valued at US$5.1 billion. Developer-first companies have also gone public and done well: the market cap of New Relic is over US$4 billion; the market cap of Datadog is over US$32 billion.

But what people aren’t shelling out the big bucks for is anything based on new programming languages and technologies, especially technologies focused around helping people write code with more guarantees. The entire static analysis market size in 2020 is estimated at US$748.1 million in 2020 and is projected to reach only US$2002 million by 2027. And programming languages development largely happens supported by big companies, as in the case of Go and Python, or by enterprising language developers who find some other way to support themselves as they corral their open-source communities, as in the case of Ruby, Elm, and Julia.

There’s clearly programmer pain—and pain that some of these new languages and tools could solve. What gives?

But programmers are voting with their budgets

Could it be that engineering leaders are choosing tools against the wishes of their developers? This is what many people say (for instance, see here).

But the data doesn’t support this. According to the State of the Developer Nation in 2017 (via SlashData), 77% of developers now have a say in tool selection. And they’re choosing to spend that tool budget on products that make their work lives easier, rather than tools that make their code higher quality. For better or for worse, these two concerns are not the same.

It’s worth calling out the difference between programmer aspirations and programmer needs. I would love to have an aviary in my backyard where I can keep pet owls. But what I need to do right now is write some emails and eat lunch. Similarly, programmers would love to ship bug-free code on time that always runs as fast as it did in test. But what they need is to fix their hair-on-fire incidents, then make up time on the roadmap so they can get their scheduled features out the door ASAP. The eyes of a software developer may widen at the mention of a tool that can magically reduce their bugs to zero, but a software developer grounded in reality knows that the truth is their users seem to have quite a high tolerance for certain bugs. A software developer might use that nice shiny research language to blow off steam on weekends, but they know in their heart of hearts that adopting it in their messy work code base isn’t the best way to advance their career.

So why are developers choosing to spend money on certain tools and not others?

Working developers aren’t buying “luxury goods”

Some will say that it’s just a matter of time before we see adoption of the fancier, deep-tech stuff. My two cents: the programming languages community currently holds some assumptions that are at odds with programmer needs.

Here are a few programmer needs that don’t fit with the PL worldview:

• Zero bugs: usually not the top priority. A common goal in language design and software analysis is “soundness:” if there is a bug, the tool will find it. If you’re building a spaceship where a single bug means that you lose lives and millions of dollars, it makes sense to go through possible bugs with a fine-toothed comb. For the average web app, however, there’s a big tradeoff between fixing bugs and shipping features. Web app developers often need something that helps them build software quickly, without sacrificing too much correctness—not the other way around.
• People don’t want to know about all of their problems. I often see “fancy” techniques assume developers want to know about everything that’s wrong with a system. Is your friend who always tells you everything that could go wrong your most popular friend? People don’t want to know all of their problems, especially when not all of the problems matter. If you want to make developers happy, give them a prioritized list of what to do next, not an overwhelming list of potential issues that will make them mute your notifications.
• Tech stacks are organically evolving ecosystems, not centrally planned entities. Now for the question of why no single programming language or framework is going to take over. Just as it’s appealing to dream of silver-bullet solutions in any other domain, it’s fun to dream about The One True Language. But most systems of a certain maturity pick up a second language, then a third. Different layers of the tech stack pick up their own languages and technologies. This isn’t because organizations are disorganized, or haven’t thought things through. Languages evolve, the needs of a system evolve, and the next generation of programmers evolves.

From the point of view of working developers, the idea of zero bugs, having the kind of timeline that lets you address all bugs, and having complete control over the tech stack can seem like impossible luxuries.

The techniques that the programming languages community has been developing aren’t broken, but they need to adapt to the needs of working developers! In the next section, I’ll talk about how.

Tools need to fit into developers’ everyday lives

In order to fit into developers’ lives, programming-tool creators need to work backwards from the intended developer experience, rather than forwards from the technology we want to build. And in order to do this, we’ll need to engage a discipline that’s often considered a dirty word among technical people: design.

I often see programming-tools people ignore design, but I believe it’s because of a misunderstanding about what design is. Especially in programming tools, design means reducing friction to help developers get to where they need to go, not increasing prettiness or dialing up the trappings of good user experience, like cute error messages or dark mode.

Here are a few lessons I learned from doing user research and working with designers, that could help package existing technologies in a way that’s directly helpful to developers in their jobs:

• The problem that the tool is solving matters more than anything else. In technical programming languages communities, I often see more of an emphasis on what people are building than the problems they are solving—and it’s often acceptable to have a shadowy, hypothetical picture of the user. For instance, I often see functional programming enthusiasts make arguments about how their languages are better for developers for technical reasons (more guarantees; elegance) that aren’t related to the high-priority problems that software teams are experiencing. If people aren’t adopting these technologies, it might not be that they don’t “get it” about how cool the technology is, but how it can help them with their top-of-mind problems.
• Fitting into workflows matters more than the technical “wow.” Especially for “deep tech” tools, there’s often this focus on what they’re doing that is new or cool. After a few dozen user research interviews with developers, I came to appreciate just how much of an ecosystem each tool lives in. When I asked developers why they adopted tool X or Y, the answer was often that it worked with their programming language or infrastructure, or that it had the Slack/GitHub/Jira integrations they wanted. A lot of the “deep tech” tools I see assume a developer will switch to an entirely new toolchain to get a relatively small set of benefits. For most software teams, this is a nonstarter.
• Packaging often matters more than the technical solution. If you’re one developer running something a few times for the purpose of showing that something is possible, then it’s fine for the output to be clunky, and for you to have to query over it or hand-beautify it in order to understand it. If this is a tool you’re going to be using day-in and day-out and sharing the results with your team, then having a tool that has taken the time to smooth out the rough edges, makes it easy for you to see the output you need to see, and makes it easy for you to do what you want with the result makes a big difference.

As I’ve experienced with Akita, it’s quite difficult to take a design-oriented perspective while simultaneously building out deep technology—and I’ve primarily seen it done well in research labs affiliated with large companies, where there are nearly infinite resources. But I do believe it’s possible to do in a startup, especially with the kind of capitalization we’re seeing early-stage developer tools companies get these days, and I would love to see more of it. (And if you want to read more about my views on how developer experience relates to “deep tech” programming tools, I have another blog post here.)

The way forward

We’re entering a golden age of developer tooling—and I’d love to see “deep tech” dev tools get a piece of the pie. I left academia because I felt there’s a lot I could bring from my expertise in programming languages and software analysis to solving major problems for developers. And a big part of my motivation for writing this post is because the job is too big for one team alone! I deeply believe that, by marrying the right tech with the right problems, we can make software development a much more smooth—and even delightful—process than it is today.

From the programming tools side, here’s what tools need in order to get wider adoption:

• More meeting developer needs and workflows where they are
• More interoperability with existing dev tools
• More incremental improvements that work with what exists
• More design that fits developer priorities‍
• Less focus on 100% guarantees‍
• Less focus on building a “new universe” that requires the universal and homogeneous adoption of a single tech-stack element

And if you’re a programming tools consumer wishing there were better tools, there is a role for you too! Here’s what I believe needs to happen for the ecosystem to become more welcoming of “deep tech” programming tools:

• More acceptance of tools that are a little rough around the edges—it’s hard to create a good developer experience for something that hasn’t existed before!
• More acceptance of “complexity-exploring tools” (Stay tuned for a future blog post on this!)
• More feedback about the problems you want certain tools/classes of tools to solve
• Less belief in “silver bullets”
• Less dreaming about the “One Language to Rule Them All”
• Less patience with processes that lead to lower developer productivity, especially in ways that affect the business (and are thus easier to fix)

Obviously, this is all easier said than done. I’ve been on a multi-year journey of this at Akita—and we’re still figuring a lot of stuff out. But the more we talk about this, the more we have hope that the developer tooling enthusiasts can band together to make developers’ lives better with the cutting edge of what is possible!