The Pragmatic Engineer

C# was designed by a 6-person team. Anders Hejlsberg - creator of C#, TypeScript, Turbo Pascal & Delphi - on the benefits of working collaboratively from the start: They worked in short sessions, regularly: “Early on, we decided that we want to have a team of people design this language, not just one. I was sort of the guy who ran the group of designers, but we put together a group of six people or so, and we got in a room three times a week for two hours and just started the design. Literally, let's start from the top." Language design is iterative on previous languages you’ve built: “These were all people who had built or worked on programming languages before and had seen all of the things you're supposed to do and all the things you're not supposed to do. And quite honestly, language design is 90% the same and 10% new for pretty much every language. Every language you build still has to have a compiler. The compiler is still built pretty much the same way. And of course as time marched on, people demand more and more. You have to have IDEs, you have to have frameworks… So there's a lot of experience you want to pull in, and there's a lot of work that you're doing that isn't really new, but every time around you try to fix the problems that you've been exposed to.” The team worked together for years and tested each other’s ideas vigorously: “This language design group worked together for years on end, and it was lovely to come into work with a new idea and then immediately have five or six people that you could sit down and have a deep discussion with without first having to spend an hour level setting. That worked really well because we could just jump right in and have two hours of technical discussion. Everyone was cognizant of, okay, if someone comes up with a new idea, now it's our job to try to shoot it down - what’s wrong with this idea? If it could stand the test of that, then it was probably a decent idea. And so that was kind of how we ran the design.” Learn more about the history of C# with Anders Hejlsberg on The Pragmatic Engineer podcast • YouTube: https://lnkd.in/e4jr9RXA • Spotify: https://lnkd.in/e2WZitaE • Apple: https://lnkd.in/eHjrJFVX • Summary and transcript: https://lnkd.in/emUAMReZ

OpenCode operates in an AI-native space but, as co-founder Dax Raad tells us, no one is using AI so well that they’re crushing the competition: “In the past six months, we operated very differently than we ever have. A lot of stuff went wrong because of that. So now we're pulling back and figuring out, okay, what from the old world still makes sense? We're figuring out what we should be doing and I definitely don't feel like, oh yeah, we're killing all our competitors, we're using AI so much better than everyone else. And by the way, none of our competitors are crushing us either. No one out there is using AI so well that we can't even compete. And we're in the coding agent space. All our competitors are super into AI. So you would think in our space there would be a huge gap, but there just isn't.” Learn more about building OpenCode with Dax Raad on The Pragmatic Engineer podcast: • YouTube: https://lnkd.in/g2YYwPFp • Spotify: https://lnkd.in/gBwKfEHN • Apple: https://lnkd.in/gAN9SzVa • Summary and transcript: https://lnkd.in/gp5qZtus

Even with AI agents, Dax Raad - co-founder of AI coding agent OpenCode - says the daily bottleneck is still deciding what you should do, not doing it: "I think the bottlenecks are still there, they're still figuring out what you should be doing. You can spend a year just figuring out the right thing to do. Then, once you figure it out, maybe it's fast to actually build it. I think the joke I made was that pre-AI, I would spend 95% of my energy thinking about what to do and 5% of my energy doing it. Now I spend 96% of my time thinking about what to do, 4% of my time actually doing it. So it's like a 20% improvement, but day to day it feels as hard as ever." Learn more about building OpenCode with Dax Raad on The Pragmatic Engineer podcast: • YouTube: https://lnkd.in/g2YYwPFp • Spotify: https://lnkd.in/gBwKfEHN • Apple: https://lnkd.in/gAN9SzVa • Summary and transcript: https://lnkd.in/gp5qZtus

What is the “best” language for AI? Anders Hejlsberg - creator of many languages including C#, TypeScript, Turbo Pascal & Delphi - explains why AI does well with languages like TypeScript: “My flippant answer there, is that the language that's most suited for AI is the language that AI has seen the most of in its training set. That's why you could argue AI does really well on JavaScript, TypeScript and Python because it's seen an awful lot of it, and there's an awful lot of that still. And that just reinforces itself. And you could argue, well, the reason TypeScript and JavaScript are popular, is mostly to do with a browser and not so much to do with AI, but it's interesting to look at why is AI targeting TypeScript versus just JavaScript? And there I think the types actually help guide the AI to producing better programmes. And I think our combination of the ability to type something when there's no context, but also our ability to infer it when there is context is just the right combination. Because if you were to force AI to write a type annotation on everything, then it would probably get it wrong more often, because now it has to keep track of all these types and it has to just repeat itself over and over and over. And so types are important where there's no context, but inference is super important for the DRY or do not repeat yourself principle. And fewer tokens generally makes AI more efficient. And so I think we have a very nice combo there in how you can just sort of type the outermost parameter and then everything flows from there on in.” Hear more from our conversation with Anders Hejlsberg on The Pragmatic Engineer podcast: • YouTube: https://lnkd.in/e4jr9RXA • Spotify: https://lnkd.in/e2WZitaE • Apple: https://lnkd.in/eHjrJFVX • Summary and transcript: https://lnkd.in/emUAMReZ

TypeScript was open-sourced at a time when Microsoft had a strong anti-open-source reputation. Anders Hejlsberg, creator of C#, TypeScript & Turbo Pascal, on how they ended up on GitHub: TypeScript creators wanted to open-source TypeScript, but Microsoft was resistant: “Microsoft was slowly waking up to the fact that open source was not going to go away. Open source was where developers wanted to be, and they were voting with their feet. Yet, there's a collective DNA that has been trained to pull you in the other direction. And so that battle - we were right in the centre of that. We full well knew that there was absolutely zero chance that we would appeal to the JavaScript ecosystem with a proprietary programming language licensed from Microsoft. No, no one was going to come. It had to be open source. There was just no two ways about it, but getting that off the ground inside Microsoft, it took some pulling and we paid some taxes.” Initial open sourcing was far from ideal: “We did eventually get the okay to do open source because we had two technical fellows, myself and Steve Luco - who was the other co-inventor of TypeScript - insisting. So, okay, people weren't going to debate that, but of course you have to pay the tax and be on Microsoft's open source repository called CodePlex, where exactly no one was. We were there for the first two years and it kind of was crickets. It wasn't until 2014 when we moved on to GitHub that things really started to get moving with adoption." Being on GitHub changed their workflow, to TypeScript’s benefit: “Honestly, it totally changed our workflow. There's open source and there's open development. We were technically open source in the beginning, but it was not open development. We would sort of lop the source code out of its repository and scrape the issues off of that and put it into our internal issue tracker. But, once we switched to GitHub, the entire workflow moved to open development, and that I love that workflow. We've been there now for over a decade and it's been fantastic, and it's what made the product as good as it is.” Learn more about the history of TypeScript, C# and Turbo Pascal from our conversation with Anders Hejlsberg on The Pragmatic Engineer podcast Hear more from our conversation with Anders Hejlsberg on The Pragmatic Engineer podcast: • YouTube: https://lnkd.in/e4jr9RXA • Spotify: https://lnkd.in/e2WZitaE • Apple: https://lnkd.in/eHjrJFVX • Summary and transcript: https://lnkd.in/emUAMReZ

Why did JavaScript become so popular? Anders Hejlsberg - creator of C#, TypeScript & Turbo Pascal - tells us what happened in the early 2000s to make the language take off: “I think it was a confluence of a number of things that happened in the early 2000s. First of all, the JavaScript platform, execution platform, matured a lot. Google did excellent work on V8 and all of a sudden made JavaScript a fairly performant programming language. HTML five got ratified, and we were getting to a point where you could actually build real UIs in JavaScript. And there was this device revolution that the iPhone set off, and all of a sudden we have all of these different form factors. It's not just Windows PCs on the desktop anymore, it's all sorts of diverse devices, but lo and behold, they all run browsers with JavaScript. And, lo and behold, the real cross platform language isn't Java, it's JavaScript.” Learn more about the history of TypeScript, C# and Turbo Pascal from our conversation with Anders Hejlsberg on The Pragmatic Engineer podcast • YouTube: https://lnkd.in/e4jr9RXA • Spotify: https://lnkd.in/e2WZitaE • Apple: https://lnkd.in/eHjrJFVX • Summary and transcript: https://lnkd.in/emUAMReZ

What are “editions” in Rust? Alice Ryhl - Rust for Android team at Google, Rust language advisor - on how editions enable the team to make breaking changes without breaking people: Rust has a strong commitment to backwards compatibility: “The thing about editions that is different from versions is that if you're using version 1.90 of the compiler, everything is using that version, but different crates can use different editions. I might have a crate using the 2025 edition of the language, and I can keep using that forever because Rust has a really, really high backwards compatibility guarantee. So, you write all of your code and the guarantee is that it's going to keep working forever. That's the idea anyway.” Editions let Rust make breaking syntax changes — without breaking existing code: “Editions are the way that Rust makes breaking changes without breaking people because they might change the syntax of the language. For example, async/await was added to one edition, and so code using the old edition can't use async/await there. You could have a variable called async (`let async= 5`) and then in the new edition you can't, but you can still mix and match code written in different editions so they work together. So I might have a library written in the 2021 edition and you can write your library in the 2024 edition, or your binary project, and then you can still use my library. Really, the big idea is to say: we want the old code to continue working, but we still want to change the language.” Learn how Rust is different with Alice Ryhl on The Pragmatic Engineer Podcast: • YouTube: https://lnkd.in/eBTx6RFD • Spotify: https://lnkd.in/eN5-VaTV • Apple: https://lnkd.in/eEPRs9dM • Summary and transcript: https://lnkd.in/euE-c6g2

Ever wondered why it's much easier to get a job January to June than July to December? Fresh data from our State of the software engineering job market in 2026 shows why: because historically 90%+ of hiring happens the first part of the year. A lot more fresh data: https://lnkd.in/ecWhy3Yq

Rust's memory safety eliminates a whole class of C++ vulnerabilities. Alice Ryhl (Rust for Android at Google, Rust language advisor & Tokio maintainer) tells us more: “Memory safety is this idea that no matter how stupid the code you write is, it's not going to have a certain class of bugs. This is the kind of bug that usually leads to security vulnerabilities. The kind of thing where you read past the array and you just look at random memory or you destroyed an object and then you used it afterwards, so now you actually touch the memory of some other random object [Gergely: And then an attacker who figures this out could populate something there, eventually get that code somehow executed or configuration read – and then boom.] The classic example in the kernel is let's say you have some object and you manage to make it so that the object that's actually there - because the original object is gone, so the memory got reused - and now it has a `task_struck`  and that's basically your process. And it has a field called `user_id` and it's pretty common for a code to write zeros to memory, but if you write a zero to the user id, now you're root. That’s a really classic way of exploiting this kind of vulnerability. [Gergely: And then once an attacker manages to do that, they can take over whatever your server or whatever is running, and then of course from there on it can just spiral out of control, right?] Once you're root, you’re lost." Learn how Rust is different with Alice Ryhl on The Pragmatic Engineer Podcast: • YouTube: https://lnkd.in/eBTx6RFD • Spotify: https://lnkd.in/eN5-VaTV • Apple: https://lnkd.in/eEPRs9dM • Summary and transcript: https://lnkd.in/euE-c6g2

TypeScript was inspired by a strange ask from the outlook team. Anders Hejlsberg - creator of C#, TypeScript, Turbo Pascal & Delphi - tells us how TypeScript was born: “The world started building larger and larger applications in JavaScript. We saw that externally, but also internally. One of the trigger events was when the outlook team came to see the C# team and asked us whether we would pretty please productize this thing called Script#. And we go, well, what is Script#? It's this cross compiler that allows you to cross compile C# into JavaScript such that you can basically treat JavaScript as an instruction language and run your C# apps in a browser. Why would anyone want to do that? Well, because then you can get a grownup programming language with grownup tooling. You can use Visual Studio, you can have projects. You can do all of these wonderful things that you can't do with JavaScript because JavaScript is just the scripting language with shitty tooling. And we thought, well, perhaps a better approach would be to fix JavaScript. I mean, surely you're not going to be best of breed in the JavaScript ecosystem by telling people to write in a different programming language” Learn more about the TypeScript with Anders Hejlsberg on The Pragmatic Engineer podcast • YouTube: https://lnkd.in/e4jr9RXA • Spotify: https://lnkd.in/e2WZitaE • Apple: https://lnkd.in/eHjrJFVX • Summary and transcript: https://lnkd.in/emUAMReZ