TypeScript, C# and Turbo Pascal with Anders Hejlsberg

Anders Hejlsberg's journey into programming began in mid-to-late 1970s Copenhagen, where his high school offered students rare access to a Hewlett-Packard 2100 computer with 32 kilobytes of ferrite-core memory. The machine was so primitive it had no ROM; the bootloader had to be loaded from paper tape every time it started. Students programmed in Fortran, a slow BASIC interpreter, and Algol—HP's version of which lacked recursion support because the call instruction stored the return address in the first word of the subroutine.

By 1979, Hejlsberg had moved to the Danish Technical University and co-founded Denmark's first computer retail store, selling kit computers like the Z80-based NASCOM, Apple IIs, and Commodore 64s. He wrote a Pascal compiler that fit into a 12-kilobyte ROM, a precursor to Turbo Pascal. The key insight was already present: a programming language is not just a compiler, but an entire experience—editing, compiling, running, and debugging must fit together seamlessly.

Anders Hejlsberg joined Microsoft in 1996 to architect the company's Java development tools, working on Visual J++ 6.0. Microsoft built a class library (WFC) that allowed developers to create Windows desktop apps in Java, but the Sun Microsystems lawsuit changed everything. A judge in San Jose effectively ended Visual J++ as a viable product—no company would bet on a language that had been legally enjoined.

The lawsuit, combined with Microsoft's realization that licensing core technology from a competitor was strategically unsound, sparked the creation of .NET and C#. Microsoft wanted a language that rolled up the ease of Visual Basic with the power of C++, added garbage collection and exception handling, and introduced modern features like a unified object system with reflection. The design goal was explicit: create something that could compete with Java while giving developers both productivity and performance. C# launched as part of a simultaneous effort with the .NET runtime, designed from day one to be language-agnostic and standardized.

In the early 2000s, the world woke up to the fact that JavaScript, not Java, was the true cross-platform language. Google's V8 engine made JavaScript performant, HTML5 was ratified, and the iPhone triggered a device revolution. Every platform ran a browser with JavaScript. Microsoft's Outlook.com team came to the C# group asking them to productize Script#, a cross-compiler that turned C# into JavaScript. The request was revealing: developers wanted «a grownup programming language with grownup tooling»—Visual Studio, projects, statement completion, refactoring.

Anders and Steve Lucco proposed a better approach: fix JavaScript itself. JavaScript is a decent little language—Brendan Eich got functional programming right, and functions as first-class objects are a godsend—but it lacks a type system. Without types, you cannot build great tooling at scale. The insight was to create a superset of JavaScript that added an erasable type system. TypeScript would compile away the types, but the types would enable Visual Studio-class tooling: statement completion, go-to-definition, find-all-references, and refactoring. The productivity boost came entirely from better tools, not from runtime performance.

TypeScript became the most popular language on GitHub in November 2025, according to the Octoverse report. The reason is straightforward: tooling. Developers adopted TypeScript because it gave them statement completion, refactoring, go-to-definition, and find-all-references at scale—all powered by a type system that the runtime never sees. Other languages tried to compete (CoffeeScript, and many others targeted JavaScript), but TypeScript had two advantages.

First, it was a true superset of JavaScript—any valid JavaScript is valid TypeScript. Second, it combined explicit types where context is missing with type inference where context exists. This balance is critical: forcing developers to annotate every variable would make the language verbose and error-prone (especially for AI, which would have to track and repeat types constantly). But inference alone isn't enough for large codebases or tooling. TypeScript hit the sweet spot, and the fact that it was built in lockstep with VS Code—another open-source Microsoft project—created a symbiotic relationship that reinforced both products. The language and the IDE evolved together, just as they had with Turbo Pascal decades earlier.

Many languages are built around cooperative multitasking: an event loop dispatches events, you handle them, then yield back to the loop. The problem is long-running work. How do you pause in the middle, yield to the event loop, and resume when your result is ready? You have to build a state machine—move all your state off the stack into heap-allocated objects, add a big switch statement to track where you are, and handle continuation logic manually. It's a nightmare.

Async/await solves this by letting the compiler write the state machine for you. The «await» keyword says, «I want to yield here, and when this promise completes, resume here.» The compiler transforms your sequential code into a state machine automatically. This is why async/await spread so quickly to JavaScript, Python, Rust, and other languages. The tradeoff is function coloring—async functions and regular functions are incompatible, and once a function is async, everything that calls it must be async. Some environments like Go avoid this with green threads (lightweight, language-emulated threads), but for languages with existing event loops, async/await was the right solution.

Anders Hejlsberg sees developers increasingly becoming project managers who oversee an army of junior programmers called AI agents. The agents spit out reams of code, but someone has to have the big picture, review the output, and build the architecture. It's a different kind of craft and a different kind of enjoyment. Anders has always liked writing code—seeing it work is fulfilling—and AI robs a bit of that.

But he believes the review process can be made more interesting. Today, code reviews are a list of diffs in alphabetical order, and you make heads or tails of it. More pedagogical presentations are possible: AI-generated commentary that explains changes and guides you through the logic. The symbiotic relationship between human and AI needs work to keep the enjoyment in the craft. But one thing is certain: you cannot absolve yourself from understanding what's going on. Vibe coding works until it doesn't, and when the AI goes off track and you can't fix it, you're stuck. Responsibility lies with the programmer, not the AI. You can't fire the AI. Ultimately, AI is a tool to make developers more productive, but it will fundamentally change how programs are written.

The TypeScript team has spent the last year and a half porting the compiler from JavaScript to native code (Go). Early in the project, AI was nowhere near capable enough to help, but as the port progressed, AI became increasingly useful. Today, the team uses AI to code-review pull requests (which has gotten much better), implement or fix simple issues, and port backlogged PRs from the old codebase to the new native compiler.

AI also handles drudgery work: «Here's this feature. Write me tests in the same style as these other tests.» No one likes writing tests, but AI loves it and will pump out hundreds. The team uses AI to eliminate toil. But they are not at a point where AI absolves them from understanding what they're doing. When it comes to implementing new language features, figuring out how types, symbols, binding, and parsing relate, or choosing the most efficient data structure, AI isn't quite there yet. The TypeScript codebase is one big brownfield, and there are only so many compilers in AI training sets—unlike the gazillion React apps AI has seen.