Companies & Languages | Prakash Suresh

Roblox chose Lua around 2006 because it was small, fast, easy to embed, and simple enough for a new programmer to learn. Children could write a script and make something move inside a game. That was the job.

Fifteen years later, Roblox open-sourced Luau, a language derived from Lua. By then the company had rewritten the interpreter and compiler, added a gradual type system, built a linter and formatter, introduced native code generation, and kept old scripts working. Roblox did not begin with a grand plan to create a language. Its platform kept placing the same demands on Lua until changing the language became part of running the business.

That sequence is more useful than the usual programming-language debate. A language does not become a good company decision because it has elegant syntax, wins benchmarks, or attracts a large community. It becomes defensible when a repeated business problem is expensive enough, the language can address that problem, and the company is prepared to maintain everything around it for years.

Only a few company-language relationships meet that standard: Jane Street and OCaml, Ericsson and Erlang, Google and Go, NeXT and Objective-C, Apple and Swift, Meta and Hack, and Roblox and Luau. Each arrived there by a different route.

The useful question is what each company had to do before its language could keep working inside that company.

In How Programming Languages Actually Work, I followed source code through tokens, types, intermediate representation, and machine code. The companies here face the next problem: when is it worth taking responsibility for that machinery?

An obscure language can still win

Popularity is an attractive score because it is public. We can count GitHub repositories, Stack Overflow questions, job listings, package downloads, and conference talks. A company can spend twenty years building valuable software in a language and still look like a loser on most of those charts.

Jane Street exposes the problem with that measure. The firm reports more than 500 OCaml programmers and over 30 million lines of OCaml. OCaml remains a minority language outside a few research and commercial communities. Inside Jane Street, it carries research, trading, risk, accounting, developer tools, and infrastructure.

That is a successful language decision, even if OCaml never catches Java or Python.

Jane Street’s experience shows that a language does not need wide adoption to be successful. If it solves the company’s problems and the company is willing to sustain the ecosystem around it, internal use is enough. The harder question is what makes that arrangement work. Five questions help:

Did the company face a frequent and expensive constraint? A new language is difficult to justify for an occasional inconvenience.
Did language design address that constraint directly? Taste, fashion, and fewer characters are not enough.
Did the company build the missing system around the language? Compilers, runtimes, libraries, editors, debuggers, tests, deployment tools, documentation, and training all count.
Did the choice survive production for years? A launch announcement proves intention. It says little about maintenance.
Would the work still be valuable without mass adoption? External users can share costs, but the business case must start closer to home.

The cases that pass tend to look old. Erlang began in the 1980s, Objective-C entered NeXT in the late 1980s, Jane Street adopted OCaml in the early 2000s, Go started in 2007, and Swift started in 2010. This is partly selection bias, but it is the useful kind. A language needs time to accumulate libraries, compatibility promises, trained engineers, ugly failures, and repaired mistakes. Recent languages can publish goals. Older ones can show a bill and an outcome.

Jane Street kept the research code

Yaron Minsky joined Jane Street part-time in 2002 and began his statistical work in Python. When Python became too slow, he switched to OCaml, which he had learned in graduate school. The move was tactical. He expected the research code to be thrown away after it identified a profitable idea.

The program grew to roughly 80,000 lines and became operationally useful. Jane Street hired more people to work on it. Around 2005 and 2006, the firm had to decide whether OCaml would remain a research language or carry production trading systems.

The choice was not simply about speed. In his Why OCaml talk, Minsky describes a combination that mattered more: code as concise as a dynamic language, native compilation, automatic memory management, and a type system that catches mistakes without filling every function with annotations. Engineers could read and refactor the program. Research code could become production code without a rewrite into another language.

That continuity mattered to Jane Street’s work. A tool might begin with a market researcher, move into a trading system, and later feed risk, monitoring, or accounting. Each translation between languages creates another boundary where the model, assumptions, and implementation can drift apart. OCaml covered enough of the route to remove many of those translations.

The language still arrived with gaps. Jane Street needed stronger standard libraries, concurrency support, serialization, testing, profiling, editor integration, build tools, and a way to teach new hires. The firm responded with Core and Base, Async, Dune, inline tests, benchmarking tools, compiler teams, training courses, and nearly a million lines of released code.

By 2015, Jane Street had a group dedicated to OCaml’s compiler and development tools. In 2025 it publicly named its compiler branch OxCaml. OxCaml adds controls for allocation, memory layout, parallelism, and optimization while keeping ordinary OCaml as its base. Engineers can use those controls where measurements demand them without splitting the company across an unrelated language and ecosystem.

Jane Street did not create OCaml, and it does not own the language. Academic groups, open-source maintainers, industrial users, and companies such as Tarides all contribute to it. Jane Street became responsible for the parts on which its own systems depended. Minsky calls this the “you break it, you bought it” effect: once a minority technology carries important work, waiting for someone else to repair it becomes a business risk.

Multicore OCaml shows how this shared responsibility can work. K. C. Sivaramakrishnan began the project at Cambridge OCaml Labs in 2014 after earlier research on multicore functional-language runtimes. The work continued with researchers at IIT Madras and other institutions, while Jane Street funded research and contributed production experience and compiler engineers. OCaml 5 brought shared-memory parallelism and effect handlers into the main language in 2022.

Jane Street did not order a private feature and accept a patch. Researchers had their own questions, maintainers protected compatibility, and industrial users supplied code that could expose regressions. The language improved because those interests overlapped. Owning every line was unnecessary; staying close enough to the work to influence and support critical layers was enough.

OCaml gave Jane Street useful properties in 2002. The institution built around OCaml is what makes the decision hard to copy in 2026.

Ericsson put failure into the language

Erlang is a closer example of a company creating a language for its own repeated problem. During the 1980s, a group at the Ericsson Computer Science Laboratory studied which programming-language features made telecommunications software easier or harder to build. Joe Armstrong, Robert Virding, and Mike Williams began the work that became Erlang.

Telecom systems had an unusual operating contract. They handled many concurrent activities, communicated across machines, ran continuously, met soft real-time deadlines, and recovered from faults while the rest of the system stayed available. These were not isolated performance hot spots. The same requirements appeared across products.

Erlang made lightweight processes, isolated state, and message passing normal. A failed process could be restarted under supervision without treating every failure as a reason to stop the whole machine. OTP supplied reusable behaviours, release handling, middleware, and libraries for building systems in that style.

The language and its runtime encoded an operating model. Teams did not have to recreate that model through conventions around shared memory, threads, callbacks, and defensive error handling in each application.

Ericsson’s AXD301 telecom switch became the industrial proof. Erlang’s official history describes the language and OTP as battle-tested in Ericsson products, while Armstrong’s doctoral thesis examines how the programming model supported reliable distributed systems. Exact reliability numbers often repeated online belong to particular deployments and periods. The durable result is simpler: Ericsson shipped a large, long-running telecom system using the language built for that class of work.

Erlang was released as open source in 1998 and found users in messaging, databases, queues, and web infrastructure. It never became a mainstream replacement for Java or C++. It did not need to. Ericsson had already supplied the demanding workload, the runtime investment, and the production evidence.

Go started during a long build

Go came from a different kind of repetition. In 2007, Robert Griesemer, Rob Pike, and Ken Thompson were working inside a Google codebase with huge C++ programs, large teams, complicated dependencies, network services, and slow builds.

Pike’s account, Go at Google, records one large binary that sent eight gigabytes of data to the compiler from 4.2 megabytes of source. A distributed build took 45 minutes in 2007 and 27 minutes several years later, even after extensive build-system investment. The company could keep scaling the machinery around C++, but the language kept making dependency control and program understanding difficult.

Go attacked those costs with a small language, fast compilation, explicit packages, garbage collection, built-in concurrency, formatting and testing conventions, and a standard toolchain. Its designers deliberately left out features they thought would make large programs harder to read or tools harder to build. Go was designed for software engineering at Google, not as a programming-language research programme.

That distinction explains both Go’s appeal and its limits. Garbage collection, a restricted type system, and the preference for simple mechanisms make Go productive for many network services and command-line tools. They also make it unsuitable for work requiring manual memory layout, hard real-time behaviour, or the lowest predictable latency. Google continues to use C++, Java, Python, JavaScript, and other languages beside it.

Go later became far more popular outside Google than OCaml became outside Jane Street. External success broadened its library supply and divided maintenance across a community. The original case did not depend on predicting that outcome. Google had a recurring internal cost, designers who understood it, and enough code on which to test whether the language changed the work.

Even self-hosting followed that proof rather than preceding it. Go’s first implementations relied on other languages. The team later moved the compiler and parts of the runtime to Go once the language, tools, and community could support the transition. Writing the compiler in its own language improved profiling, testing, and the ability of Go programmers to contribute, but it was not what made the first version useful. A company can gain control in stages.

NeXT bought more than syntax

Steve Jobs did not commission Swift. The company-language story associated with Jobs begins earlier, at NeXT, and the language is Objective-C.

Brad Cox and Tom Love created Objective-C at Productivity Products International, later called Stepstone. It combined C with the message-passing object model associated with Smalltalk. NeXT licensed the language in 1988 rather than inventing one from zero.

The version NeXT licensed was not enough for the platform it wanted to build. Stepstone engineer Steve Naroff changed the compiler and added features needed by NeXTSTEP and Interface Builder. He later joined NeXT. Other engineers added language and runtime capabilities while NeXT developed its application frameworks, visual interface tools, operating system, and development environment.

The Computer History Museum’s account shows why the relationship matters. Objective-C might have remained obscure without NeXT, but NeXT also benefited from starting with a working language. C preserved low-level access, compiler knowledge, and familiar tools. Dynamic messaging and runtime reflection fit the application framework and Interface Builder.

Developers experienced the combination. An interface object created visually could connect to application objects through the same runtime model. Framework classes, compiler features, serialized interface files, and developer tools were designed with one another in mind. Objective-C was valuable because it sat inside a coherent platform.

Apple acquired NeXT in 1997. NeXTSTEP’s technical line became central to macOS and later iOS, while Objective-C became the main application language for both. A language that began with a small vendor and a niche workstation company eventually reached every iPhone developer.

That later reach should not obscure the first success. NeXT selected a language that fit the system it wanted, then changed the language and the surrounding system together. It owned enough of the stack for each layer to reinforce the others.

Swift began where Objective-C stopped

By 2010, Objective-C had served the NeXT and Apple line for more than two decades. Apple had improved it through Clang, blocks, automatic reference counting, modules, literals, and better tools. Chris Lattner initially explored whether the next set of ideas could fit there too.

Lattner started Swift as a side project in July 2010. A few engineers knew about it at first, more joined in 2011, and it became a major Apple Developer Tools effort in 2013. Apple announced Swift in 2014. Steve Jobs died in 2011, and the public chronology supplies no evidence that he asked Apple to create Swift or shaped its design.

Correcting that myth leaves a more useful history. Apple created Swift after years of improving Objective-C had exposed a boundary. Objective-C’s identity came from its C foundation. Stronger memory and type safety could be added around that foundation, but making safety the default while retaining all of C’s semantics was a different problem.

Swift offered automatic memory management, stronger typing, value types, optionals, generics, pattern matching, and a modern concurrency model while compiling to native code. It still needed Apple’s installed world. Swift could call Objective-C frameworks, coexist with Objective-C files, import Apple APIs, and enter an application one component at a time.

Compatibility did not make the transition cheap. Apple had to build and stabilize the compiler, standard library, debugger support, Xcode integration, package manager, runtime, migration tools, API import rules, language-evolution process, module stability, and binary interface. Swift 5 ABI stability finally allowed Apple operating systems to ship a stable Swift runtime in 2019, five years after the public launch.

Those five years matter. Applications written against early Swift releases sometimes needed source migration as the language changed. Apple could supply automated converters, update Xcode, revise SDK annotations, and teach the new model through its developer conferences. Even with control of the platform, the company could not skip the compatibility work. It could only coordinate that work across more of the system than an ordinary application company could.

Swift fits the company-language pattern, but Apple has an advantage Jane Street does not. Apple controls the operating systems, SDKs, IDE, documentation, frameworks, application-distribution rules, and a large developer channel. Swift is both an internal engineering investment and a language offered to everyone building for Apple’s platforms.

This is where scepticism about new languages should become more precise. Apple did not justify Swift by claiming that a cleaner language would make ordinary applications shorter. It had an old platform language, a safety boundary that incremental improvements could not fully remove, millions of existing developers to protect, and control over the migration path.

Hack and Luau stayed close to home

Meta reached its language decision from the opposite direction. Facebook already had millions of lines of PHP and valued its fast edit-refresh cycle. Rewriting that codebase in a fashionable static language would have discarded years of working product behaviour and slowed development while two systems coexisted.

Facebook developed Hack on HHVM to add static types, navigation, refactoring, and earlier error detection without abandoning the PHP code. Most PHP files were initially valid Hack. Typed and dynamic code could coexist, even inside one file. A persistent local type-checking service returned results quickly enough to remain part of the normal edit cycle.

The 2014 Hack announcement says Facebook migrated nearly its entire PHP codebase within about a year through voluntary adoption and automated refactoring tools. The migration path was a product feature. Without it, the type system would have been an attractive demonstration aimed at the wrong codebase.

Hack later stopped pursuing PHP compatibility. That gave Meta more freedom to remove difficult PHP behaviour and design for its own systems. It also made Hack less attractive outside the small set of companies willing to adopt HHVM and its narrower package community. Hack remained valuable inside Meta without becoming the successor to PHP across the industry.

Roblox took a similar route from Lua to Luau. Lua had worked because it was embeddable and approachable. As Roblox grew, the language had to serve novice creators, professional studios, internal application teams, and a platform that executed untrusted code on several kinds of hardware.

Those users pulled in different directions. Beginners needed a small language. Large projects needed types, linting, navigation, and faster execution. Roblox needed a secure sandbox, tight control over resource use, portability, and backward compatibility for years of existing scripts.

The Luau team explains that LuaJIT did not meet its combined needs for portability, maintainability, sandboxing, and tools for large programs. Roblox rewrote much of the compiler, analysis system, and interpreter while following Lua 5.1 syntax and semantics closely. It kept old code useful and added complexity mainly through tools and optional types.

Luau went open source in 2021, but Roblox remains its main distribution channel and proving ground. Millions of experiences can use it because it is built into Roblox Studio and the runtime. Wide adoption outside Roblox would be welcome. The internal case does not require it.

Hack and Luau reveal the same discipline. Both companies began with a language that had already made the product possible. They changed it only after the cost of preserving compatibility became smaller than the repeated cost of working around its limits.

Dart needed a platform

Google’s Dart supplies a useful countercase because the first strategy did not work as intended. Google released Dart in 2011 with the web as its first target. The language could run in a virtual machine or compile to JavaScript, and its designers hoped browsers might eventually run it directly.

Browser-native Dart did not become a web standard. Google controlled Chrome, but it did not control the whole web. A language for web applications had to meet other browser vendors, JavaScript’s installed code, standards bodies, existing libraries, and developers who could not require users to install a new runtime.

Dart could have remained an expensive answer without a compelling home. Flutter supplied one. A cross-platform UI framework benefited from fast reload during development, ahead-of-time native compilation for release builds, predictable application performance, and one language across mobile targets. Dart’s virtual machine, compilers, tooling, and embeddability matched those needs.

The Dart team called Dart 2 a rebirth in 2018, focused on productive client development for mobile and web. Dart did not defeat JavaScript in the browser. It found a platform where the language, framework, compiler, widgets, tools, and distribution story could move together.

This pivot prevents an easy conclusion from the successful cases. A capable language and a large sponsor can still miss. The company must control enough of the problem, or offer enough value at the boundaries it cannot control, for adoption to begin.

Why Microsoft feels different

Microsoft has several important company-language relationships: C# with .NET, F# from Microsoft Research, and TypeScript on top of JavaScript. They belong in a complete history, but they answer a different business question.

C# helped Microsoft establish .NET as a developer platform. TypeScript made large JavaScript programs easier to navigate and change while preserving the browser and package ecosystem. Their success depended partly on external adoption because selling platforms, cloud services, operating systems, and developer tools is part of Microsoft’s business. The language is one of the products through which the company attracts other companies.

Jane Street has no comparable need to make OCaml dominant. Roblox can justify Luau through the quality of its creator platform. Ericsson could justify Erlang through telecom products. Their languages primarily earn their keep through the systems the company operates or sells, even when outside communities help maintain them.

Other relationships sit between these groups. Shopify funds YJIT to keep Ruby productive. Dropbox and Stripe built type checkers around Python and Ruby. Nubank adopted Clojure and later acquired Cognitect, its corporate steward. WhatsApp used Erlang at unusual scale without creating the language. Bell Labs developed C with Unix, perhaps the strongest historical example of a language and system growing together.

These are valuable cases, but placing all of them in one list hides the choices. Creating a language, adopting one, extending a compiler, building a checker, funding an upstream runtime, and distributing a developer platform carry different costs. The narrower set here shares a harder commitment: the company’s recurring work changed the language, and the changed language became part of how the company continued that work.

The ten-year bill

A new language is easy to overestimate at the beginning. Syntax is visible. A small compiler can demonstrate the main idea. Benchmarks can show a striking result on the workload the designers chose. A type system can reject an example that looks painfully familiar.

The missing work arrives later.

Production users need error messages they can understand, a debugger that works after optimization, stable package rules, editor support, profilers, security updates, build caching, deployment integration, foreign-function interfaces, migration tools, documentation, training, governance, and people who will maintain old behaviour they no longer like. Hardware changes. Operating systems change. Dependencies change. The first compiler team moves on.

The seven successful relationships paid that bill in different ways:

Jane Street funded libraries, tools, training, upstream work, and its own compiler extensions around OCaml.
Ericsson paired Erlang with OTP and tested the model in telecom systems that could not simply stop for maintenance.
Google designed Go together with packages, formatting, testing, documentation, and a standard toolchain.
NeXT connected Objective-C to its runtime, application frameworks, Interface Builder, and operating system.
Apple carried Swift through interoperability, source migration, ABI stability, IDE integration, and years of language evolution.
Meta built Hack with HHVM, fast incremental checking, code-modification tools, and a path through its PHP codebase.
Roblox tied Luau to its sandbox, engine, creator tools, runtime, type checker, and old Lua scripts.

The common move was selective ownership. None of these companies rewrote every database, operating system, compiler backend, or third-party component in one house language. Erlang reused the operating systems and native components below its virtual machine. Swift kept Objective-C and C interoperability. Go programs still depend on operating systems and external packages. OCaml relies on a public compiler and package community even when Jane Street carries private extensions.

Control came from deciding which layer expressed the repeated constraint. Ericsson needed a runtime model for faults and concurrency. Apple needed a safer application and systems language that could enter an existing platform. Roblox needed the scripting language, sandbox, and creator tools to move together. Rewriting unrelated layers would have increased the maintenance bill without strengthening the original case.

None of these companies received certainty at the start. Jane Street had 80,000 useful lines before it made OCaml strategic. Ericsson studied telecom programming before Erlang settled into its model. Google had measured build pain. NeXT had a platform to ship. Apple had spent years improving Objective-C. Meta and Roblox had enormous codebases proving both the value and the limits of their existing languages.

That sequence offers a demanding standard for a new language. The constraint should already be visible in real systems. A library, framework, checker, code generator, runtime improvement, or narrow service should have been considered first. Compatibility needs an engineering plan. The organization must be willing to fund the unglamorous parts long after the designers have proved the central idea.

Mass adoption can reduce that cost, but it cannot create the original reason. A company earns a language when its work keeps testing the language, its investment keeps improving the language, and the improved language keeps making that work safer, faster, or easier to change.

Until that cycle exists, a new language is still a proposal.