7 Lessons from Anders Hejlsberg on Building Languages That Last

TL;DR

• Fast feedback loops matter more than language elegance — Turbo Pascal and TypeScript both won by shortening the edit-compile-run cycle
• TypeScript extended JavaScript instead of replacing it because improvements that respect existing workflows spread faster than wholesale replacements
• In AI-driven development, type systems and refactoring tools become guardrails that constrain generated code correctly
• Essential for anyone building developer tools or choosing languages for long-term projects

The Big Picture

Anders Hejlsberg has shaped how millions of developers write code. He created Turbo Pascal, designed Delphi, led the architecture of C#, and built TypeScript. His work spans four decades and multiple paradigms, yet the same patterns emerge repeatedly.

In a long-form interview with GitHub, Hejlsberg reflects on what language design looks like after the initial excitement fades. When performance limits appear. When open source becomes unavoidable. When AI changes a tool's original function.

What emerges isn't theory. It's a set of principles for building systems that survive contact with scale. These lessons apply whether you're designing a language, choosing a framework, or evaluating tools for your team.

The most striking insight: the technical decisions that matter most aren't about elegance or purity. They're about feedback loops, behavioral compatibility, and visible tradeoffs.

How It Works

Fast Feedback Changes Everything

Hejlsberg's early instincts were shaped by extreme constraints. In the era of 64KB machines, there was no room for abstraction that didn't pull its weight. Turbo Pascal's impact didn't come from the Pascal language itself. It came from shortening the feedback loop.

Edit, compile, run, fail, repeat. No disk access. No waiting for tooling to catch up. That tight loop respected developers' time and attention.

The same idea shows up decades later in TypeScript, though in a different form. Much of TypeScript's value comes from its tooling: incremental checking, fast partial results, and language services that respond quickly even on large codebases.

Fast feedback changes behavior. When errors surface quickly, developers experiment more, refactor more confidently, and catch problems closer to the moment they're introduced. When feedback is slow, teams compensate with conventions, workarounds, and process overhead.

Scaling Means Letting Go of Personal Taste

As Hejlsberg moved from working alone to leading teams during the Delphi years, the hardest adjustment wasn't technical. It was learning to let go of personal preferences.

"You have to accept that things get done differently than you would have preferred," he explains. "Fixing it would not really change the behavior anyway."

C# didn't emerge from a clean-slate ideal. It emerged from conflicting demands. Visual Basic developers wanted approachability. C++ developers wanted power. Windows demanded pragmatism. The result was not theoretical purity. It was a language that enough people could use effectively.

Languages don't succeed because they're perfectly designed. They succeed because they accommodate the way teams actually work.

Why TypeScript Extended JavaScript Instead of Replacing It

TypeScript exists because JavaScript succeeded at a scale few languages ever reach. As browsers became the real cross-platform runtime, teams started building applications far larger than dynamic typing comfortably supports.

Early attempts to cope were often extreme. Some teams compiled other languages into JavaScript just to get access to static analysis and refactoring tools. That approach never sat well with Hejlsberg.

Creating a brand-new language in 2012 would have required not just a compiler, but years of investment in editors, debuggers, refactoring tools, and community adoption. Instead, TypeScript took a different path. It extended JavaScript in place, inheriting its flaws while making large-scale development more tractable.

This decision was practical, not ideological. TypeScript's rise to become the top language on GitHub in 2025 happened because it worked with the constraints developers already had, rather than asking them to abandon existing tools, libraries, and mental models.

The broader lesson: improvements that respect existing workflows tend to spread. Improvements that require wholesale replacement rarely do.

Open Source Means Making Decisions Visible

TypeScript didn't take off immediately. Early releases were nominally open source, but development still happened largely behind closed doors. That changed in 2014 when the project moved to GitHub and adopted a fully public development process.

Features were proposed through pull requests. Tradeoffs were discussed in the open. Issues were prioritized based on community feedback. This shift made decision-making visible. Developers could see not just what shipped, but why certain choices were made and others weren't.

"We have 12 years of history captured in our project," Hejlsberg explains. "If someone remembers that a discussion happened, we can usually find it. The context doesn't disappear into email or private systems."

That visibility changes how systems evolve. Design debates, rejected ideas, and tradeoffs remain accessible long after individual decisions are made. For developers joining a project later, that shared context often matters as much as the code itself.

When to Break from Your Own Implementation

For many years, TypeScript was self-hosted. The compiler was written in TypeScript and ran as JavaScript. This enabled powerful browser-based tooling and made experimentation easy.

Over time, the limitations became clear. JavaScript is single-threaded, has no shared-memory concurrency, and its object model is flexible but expensive. As TypeScript projects grew, the compiler was leaving a large amount of available compute unused.

The team reached a point where further optimization wouldn't be enough. They needed a different execution model. The controversial decision was to port the compiler to Go.

This wasn't a rewrite. The goal was semantic fidelity. The new compiler needed to behave exactly like the old one, including quirks and edge cases. Rust, despite its popularity, would have required significant redesign due to ownership constraints and pervasive cyclic data structures. Go's garbage collection and structural similarity made it possible to preserve behavior while unlocking performance and concurrency.

The result was substantial performance gains from both native execution and parallelism. More importantly, the community didn't have to relearn the compiler's behavior.

What This Changes For Developers

How to Evaluate Tools in an AI-First World

Hejlsberg is skeptical of AI-first programming languages. Models are best at languages they've already seen extensively, which naturally favors mainstream ecosystems like JavaScript, Python, and TypeScript.

But AI does change things when it comes to tooling. The traditional IDE model assumed a developer writing code and using tools for assistance along the way. Increasingly, that relationship is reversing. AI systems generate code. Developers supervise and correct.

In that world, the value of tooling isn't creativity. It's accuracy and constraint. Tools need to expose precise semantic information so that AI systems can ask meaningful questions and receive reliable answers.

The risk isn't that AI systems will generate bad code. It's that they'll generate plausible, confident code that lacks grounding in the realities of a codebase. As AI agents take on more complex refactoring tasks, strong type systems and reliable refactoring tools become essential guardrails.

What This Means for Your Stack

When choosing languages and frameworks, responsiveness matters. Tools that shorten the distance between writing code and understanding its consequences tend to earn trust. Tools that introduce latency, even if they're powerful, often get sidelined.

The most valuable tools in an AI-assisted workflow aren't the ones that generate the most code. They're the ones that constrain it correctly. Strong type systems, reliable refactoring tools, and accurate semantic models provide the structure that allows AI output to be reviewed, validated, and corrected efficiently instead of trusted blindly.

For teams evaluating new tools, ask: Does this shorten feedback loops? Does it accommodate how we actually work, or does it demand we change everything? Are decisions and tradeoffs visible? Can we understand why things work the way they do?

Try It Yourself

If you're working in JavaScript and haven't tried TypeScript, the barrier to entry is lower than you think. TypeScript is a superset of JavaScript, which means you can adopt it incrementally.

npm install -D typescript
npx tsc --init

Start by renaming a single .js file to .ts. You don't need to add types immediately. TypeScript will infer what it can and flag obvious errors. Add types gradually where they provide the most value: function signatures, API boundaries, complex data structures.

The feedback loop is what matters. Watch how quickly your editor surfaces errors. Notice how refactoring becomes safer. Pay attention to how much time you save not hunting down typos or undefined properties.

That's the lesson Hejlsberg has been teaching for four decades: fast feedback changes everything.

The Bottom Line

Use TypeScript if you're building anything larger than a few hundred lines of JavaScript. The tooling alone justifies the switch. Skip it if you're prototyping throwaway code or working in an environment where the build step adds friction you can't afford.

The real insight here isn't about TypeScript specifically. It's about recognizing the patterns that make tools endure. Fast feedback loops. Behavioral compatibility. Visible tradeoffs. Accommodation of imperfect code written by many people.

These aren't secondary concerns. They're fundamental decisions that determine whether a tool can adapt as its audience grows. For anyone building tools they want to see endure, those fundamentals matter as much as any breakthrough feature. The risk isn't picking the wrong language today. It's picking tools that can't evolve with you tomorrow.

Source: GitHub Blog