The Peterman Pod - Creator of Scala: Comparing Languages And How AI Will Impact Them | Martin Odersky

Episode Date: August 31, 2026

Martin Odersky is the creator of Scala and I interviewed him to compare different languages designs (Rust vs Zig vs Python vs Scala) and how AI will impact programming languages.• My ergonomic keyboard project I mentioned, you can follow along here: https://read.compose.llc/• The Kickstarter page for it: https://www.kickstarter.com/projects/ryanlpeterman/compose-simple-ergonomics-beautifully-donePodcast links:• YouTube: https://youtu.be/LdN4sPWM-WY• Apple: https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835• Transcript: https://www.developing.dev/p/creator-of-scala-comparing-languages?r=n49kyThank you to this episode's sponsors for supporting my work:• WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at https://workos.com/• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at https://jira.dev/Timestamps:(00:00) Intro(00:44) Why care about functional programming(06:35) Why should people learn Scala(09:26) Rust vs Scala(12:42) Rust vs Zig(15:45) Scala vs Python(18:31) The programming languages that influenced him(22:16) How running on the JVM works(26:33) Why writing a compiler is hard(29:19) Why Twitter adopted Scala early on(31:00) How he believes AI will impact programming languages(43:40) Will there be less engineers in ten years(44:34) Top programming languages to learn to grow(46:18) Top technical book recommendation(46:51) Why he chose academia instead of industry(48:28) Reflecting on Scala(55:42) Advice for his younger self(56:33) OutroWhere to find Martin:• Wikipedia: https://en.wikipedia.org/wiki/Martin_Odersky• Website: https://people.epfl.ch/martin.odersky• X/Twitter: https://x.com/odersky• GitHub: https://github.com/oderskyWhere to find Ryan:• Newsletter: https://www.developing.dev/• X/Twitter: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/• Threads: https://www.threads.com/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman• TikTok: https://www.tiktok.com/@ryanlpetermanReferenced in this episode:• Structure and Interpretation of Computer Programs: https://web.mit.edu/6.001/6.037/sicp.pdf• A Brief, Incomplete, and Mostly Wrong History of Programming Languages (book): http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html

We are at a moment where it's essentially very dangerous that we lose control as humans. This is Martin Oderski, the creator of Scala, and I asked him all about programming languages and how they're going to change in the future. I believe right now, Rust is actually overused. So Zick is, I believe, is much better because the inlining mechanism is much saner. This pisses off both communities and they're promptly declared jihad. If the code is AI generated, then the focus has to go elsewhere. And I think the focus will go to the interfaces and to the types.

10 years from now, do you think there will be more software engineers than today or less? Here's the full episode. What is functional programming and why should an imperative programmer care about the functional way of programming? So functional programming is programming with values. So you don't have state that changes, like new variables that change or arrays that change. you have values and you have functions and the functions transform these values into other values.

So it's a very restricted form of programming and most real functional programming languages are impure in the sense that yes, of course at some point you have to touch state and change things and write to standard out and things like that. But the idea is to do that sort of very late. So to have the largest part of your program

represented as values and functions that transform values. And the benefit you get from that is essentially much better predictability and fewer bugs because these side effects to, let's say, a global variable or a field and some object graph or things like that, they can really trip you up. They can essentially an undocumented effect of your function, so it's not reflected anywhere typically, but maybe you have a comment if things are good. and these things are very hard to keep in your head and generally reason about.

So the advice from functional programming is essentially to keep these things to the bare minimum and possibly to nothing if your function maps into these things. The other reason why functional programming is nice is that it's very directly linked to mathematics. So in mathematics, you have theories of, let's say, polynomials or strings or lists or things like that. And in none of these theories, you will find the concept of mutation. It just doesn't exist. So you can take a polynomial and you can transform it into a new polynomial, but you can't change a coefficient at 0.3 at the third coefficient

and pretend it's the same polynomial. It's not in mathematics, right? It's clearly something different. So functional programming, you could say, follows quite closely the way mathematics sees things. What would you say to someone that doesn't do functional programming because it's not convenient? I guess two things. One is it's a learning curve. So initially your sort of your brain is wired to be to do imperative programming from when you were very young. I imagine most

people learned an imperative language first. And then it's hard to see how you would express things differently. But if you persist in that a little bit, and it doesn't really take much, then you will essentially reap the benefits very quickly that you say, well, actually my program got a lot clearer. I can understand it better.

I don't really have to track some steps, go step by step through my program with a debugger or things like that to figure out what it does. Typically, I don't need a debugger when I write functional code. That's really not necessary.

The other thing is to essentially know when to stop. So there is a strand of functional programming called pure functional programming, which tries to express as much as possible in pure functions and to sort of delay the side effects to wrap them up in monads or whatnot. And that can get very inconvenient very quickly. So my answer to that would be,

It really depends, and in most cases it's completely okay to have your side effects as long as these are well documented and you use that. So basically use these things in moderation. I would say functional programming is great for 95% of your program, and if you need some side effect and some imperative feature for the last 5%, that's also okay. Is there any quantitative measure of the, I guess, the correctness benefits that functional programming gives you, over-imperative? I think there are some studies. It's not quite clear how significant they are. I think people criticize them a lot.

The studies tend to say that a language like Scala would have fewer bucks in a language like C or C++. But I don't really want to sort of insist on that because these studies are very hard to do and the methodology is very hard to get right. I believe the effects become more important in large programs and small ones. For small ones, you can do anything, really. You can write a loop, you can write a recursive function.

It doesn't really matter. And it's very much a matter of taste, which one you prefer. But in a large system, I believe, so I believe that, let's say, static types have certainly proven their worth. And even that, we don't really have a conclusive study that shows it. I mean, I can point you to a study, and if you're a dynamic typing enthusiast, then you can point, you will point to another that essentially claims the opposite. So it's very, very hard to do empirical software engineering on that scale. And so I'm afraid I can't really give a good answer.

I just have to feeling that mostly functional statically typed languages is sort of a sweet spot for getting programs right. Maybe the other thing is when you really need to get them absolutely right, like with proofs and things like that. If you do a rock or lean or any of these things, these are all functional languages. So people wouldn't even attempt to do something like C plus plus here. When you think about Scala in the environment of all programming languages,

what sets Scala apart or maybe put in another way? Why should someone learn Scala in 2026? Well, Scala is the only functional language that is also a very capable object-oriented language. In fact, it was born by the idea that we can actually make a fusion of the two in a way which is not a side-by-side, but which really combines the features in a nice synthesis. So that was what Scala was about. That's what I wanted to show. And I think that's been largely successful.

So you can write really beautiful programs in this. combination. Objectivity programming comes in when you talk about components and modules and essentially encapsulation, these sort of things, where functional programming typically doesn't really have a very strong story. I mean, there are languages like StandardML or KAML that do have very capable module systems, but other functional languages don't. And people when they think of functional programming, they don't really think much about components and interfaces and these sort of things, which are things that I believe also matter very much. Could you give an example, maybe like an object-oriented thing that you could do in Scala,

but you couldn't do in Haskell, which is pure functional? It's sort of ingrained in the whole fabric of the things, that everything is essentially objects, what you do. So one thing that you get is what I think Simon Pratton Jones called the power of the dot that you say, It's super convenient. You have an object and then you do dot, and then you have the environment that immediately tells you what are the methods and fields of that object that they can use them. So it focuses your mind, whereas in function programming, it's typically you have a C of functions that can be applied to arguments and you have to figure out what they are.

When you think about the systems programming languages like Rust, Zig, Go, C, C++, in your opinion, which one would you say is kind of the best one? and then maybe we can compare it to Scala. In this day, in the age of systems programming languages needs to be memory safe, guaranteed memory safe. So that would already exclude quite a few of them, but it would leave Rust and Go, I think. And Rust and Go are at different levels.

Goh is really not a sort of a nuts and bold systems programming languages, is more language in which you would write, let's say, an application server or some middleware or some cloud infrastructure or things like that. It's not something you would. use for embedded, say, which he would use Rust for. So I think in their domain, both of them are probably the ones that are the leading ones that I would take most seriously. And then when you compare, you know, Rust or Go with Scala, what are the pros and cons

of the different language designs? What's something that Rust does better than Scala, something that Scala does better than Rust? So Rust is closer to the metal. You have better performance guarantees, I guess. The fact that Scala is a garbage collected language means that you always have some pauses. I mean, garbage collectors have become quite capable. I mean, they're brilliant, and the pauses are really very, very small. But it's a fact that you do need a big chunk of memory to run fast, and I guess Rust could run in much, much smaller memory. So I believe that's better for embedded systems and things like that. I believe right now, Rust is actually overused because a lot of people push sort of rust for things higher up in the stack where

garbage collector is fine, but essentially you still want to write code without. And that is for me a bit an exercise in, I don't know, just intellectual that I can do it. I don't think we think there's a big sense in it that if you have the memory for a garbage collector, you should absolutely use one because it makes a lot of things simpler. So yes, of course, if given enough brains, I can write code around and I can do that, but why should you? I mean, it can be much simpler. So that was for RUT. For Go is sort of a language a bit that lags behind.

I mean, it was intentionally designed to be very, very small and essentially to be the standards of language. in the 90s. So now they have gotten generics, which is a big step. So I believe that sort of is sort of a step forward for that. But it's still a fairly limited language, what you can do, which has an advantage that essentially it forces

a very uniform style, because there's not much different things you can do, and there's probably a culture fostered to do things in a certain way, which makes it easier to essentially read one's other, programs and essentially jump in a new cold base and things like that. So I think that would be my main advantage of goal that I see there. Is it possible to turn off the garbage collector in Scala? Not in production.

So we have some research that would let you use essentially your own memory allocators and things like that, the way, let's say, Zig does it. The problem with that is always that you can leak reference. into memory that you reclaim and then all hair breaks use, you point to memory that's undefined. But in Scala, we now have a very good way to actually track these references, so we can actually prevent that statically by the type system, that this will never happen, and you can still have your own allocator.

That said, we haven't really shipped that in production yet. So right now, I would say, you'll use the garbage collector of Scala, yeah. I see a lot on the internet people comparing Rust and Zieg or kind of a fierce debate on which one is better. When you think about Rust versus Zieg, what are the merits of the two comparing to each other? So what I can see, Zick has a really nifty compile time construct for essentially inlining, where the compiler does smart inlining. and that is quite clean and quite powerful. And Rastas has macros, but I think they're more clunky than the Zick version.

In Scala, we have something quite close to Zick. We also have essentially a thing that's based on inlining and optimizations by the compiler. But we have a restriction which I believe Zick doesn't have, and that is that there cannot be additional type error. errors after inlining. So the thing is you inline and then the question is, is the inline program guaranteed correct? So type correct. Or might you have type errors. The typical example where you might have type errors is C++ templates. In fact, that's quite scary in C++ that you can expand the template and then you get very, very complex type errors and very, very hard to debug things. So Zick is I believe is much better because the inlining mechanism is much same. When you say inlining, can you explain the concept? Inlining just means that in Scala we can write inline in front of a function. And that means that the compiler will, before it starts code generating, so during the time when it looks at the type code, which are trees, it will take the function body.

When it sees a function call to that function, it will take the call and replace it by the body. And then we'll do some optimizations. It can say, okay, so here we have essentially an application to, let's say, a value, which is a lambda, but I know where the lambda points to. So let me forward the call right to the function. And with that, you can already do quite a bit of, essentially, optimizations, which are guaranteed because the in-liner must in-lines. And that's not a thing like an optimizer has essentially discretion whether they want

to inline things or not. So you can never rely on that. But an inliner, which is essentially a compile time based on the typeer must inline so you can rely on it. And const explore by in Zik and C++ plus is essentially very similar. Okay. So it's a way to get rid of the function call or the overhead of a function call and tell the compiler you can do more.

because it's all, I guess, in line. Yeah. You reveal the implementation, and that means you can, you can, the compiler can do something with that. When you think about all the dynamically typed languages,

which one stands out as one that you think is kind of the best among them? Python is ubiquitous, and it has a nice syntax. A lot of the Python programs look, like they're very easy to read, So that's definitely an advantage.

And the other one would probably be something like scheme, which is sort of very grounded in computer science theory and lambda calculus and things like that. So both of them are sort of interesting in their own way, but of course Python is 100 times more popular. If you compare Scholar to Python, for instance, I guess what are the tradeoffs that the two languages took? I think the gap is closing because Python now

actually has an optional type syntax and a number of type checkers that check that syntax. In Python is getting some of the features that Scala had since the beginning, like pattern matching is in one of the recent Python's. So I think actually the gap is closing, not just between Python and Scala, but between a lot of programming languages in general.

There's sort of all drift to a standard set of features which mostly come for functional programming, actually, pattern matching, for instance, strong type systems, generics, polymorphism. All these things came from closures, all these things came from functional programming. So the gap is closing in that sense. Python is, I think the main advantage of Scala over Python is that it has a strong type system that is always on and that gives you essentially guarantees that essentially certain bad states can't happen.

So I really can rely on it. Whereas I believe the Python type system, well, it's just syntax. It has a number of type checkers. But in general, you have fewer guarantees. And I believe it's also the ecosystem and culture that doesn't value types as much in Python. So I think that's probably the main difference.

Contractically, the two languages, I think with Scholar 3 are actually also quite close. So Scholar 3 looks a lot like Python. In that sense, you could say, well, can see it as a language that has strong types and runs on different runtimes than Python. Or I should say the other thing with Python, which is really great, is that Python is a fantastic glue language because I can essentially have very, very efficient linkages to high-performance, C++ libraries, Pandas or Nampai or things like that.

You mentioned a lot of the programming languages. They're kind of drifting or kind of being inspired by the other ones and adopting new features. In the design of Scala, is there a programming language that you admire most and influences Scala the most? Historically, Scala was essentially, you could say it was a blend of Java, Okamel and or StandardML, which is close an ML-like language and Haskell. So I'm by trade, well, I'm by trade an imperative program. My PhD is from Niklaus Wirtz. I know Pascal, Modular, that was sort of my first generation of languages, and I liked them a lot.

And then I became sort of a converted functional programmer. So I looked very closely at ML, O'Kammel, Haskell and these things. And then the scholar came about sort of, there was a predecessor language called Pizza. And I was working on that with Phil Warrick. Wadler, who's one of the Haskell original designers. And the idea was to have essentially an accessible functional language on a very widespread platform, which was a JLEM at that point. And in order to prepare for that, I wrote a Java compiler, so that's how I learned

a lot about Java and what Java was. And in the end, I had to say, well, it's actually quite useful. I was quite dismissive at first, but afterwards I found actually quite useful. I mean, this was very early Java, this was Java, even pre 1.0. So now Java is of course even more useful, but also a lot bigger than what it was at the time. So when we came up with Scana, which was sort of the second iteration after pizza, pizza was the language I did with for water, the ideas came mostly from the idea, Java, Okamel for the modules and the component model,

and Haskell a lot for the standard libraries. So if you look at the function names in the Scala standard library, then there's sort of a mixture of O'Carmel and Haskell, you could say. But you recognize a lot of things coming from both of these languages. If I recall correctly, Java was, had some sort of licensing with it or was owned by a company. How were you able to build on top of Java? Did you have to pay for licenses?

How did that ecosystem work? The language standard was open source. There was a lot of experimentation with Java at the time. I think the only thing that Sun was the company at the time, they're very particular about it, is that if you did something that was using Java and had Java in it, you had to call it Java and you couldn't have a different name.

So that's why initially, for instance, Microsoft clashed with them. And then Microsoft went away and designed C-sharp, which was sort of a Java on some steroids. They threw in a bit more than what Java had at the time. I think the nastiness came. The Sun was actually quite an open company. So at the time, we were not worried about that. So that was in the timeframe from 1998 to 2004, 2005, something like that.

And at the time there was no issue. I think the issue came later when Sun was acquired by Oracle and Google, Ford Scala on Android, Java on Android, and that's when the fight started. But that was much later. So when you say that Scala was using the JVM or built on top of it, like concretely in the tech stack, what does it mean that Scala used? the JVM, like how does Java source code eventually execute on a machine? So the JVM is essentially defined by its bytecode.

So the bytecode is essentially an intermediate format, which you can translate your program into. And then the bytecode is run first by an interpreter and then essentially by an optimized compiler, just in time compiler, JIT. So that's called JIT. they do that. And so if you know how to output bytecode, and that's not very hard,

then you can run on the JVM. So that's essentially the idea. The harder part then is interrupt that you say, okay, I run on the JVN. I have to make sense of all these Java libraries out there, so I have to somehow map a Java concept into a scalar concept so that the compiler can understand what it is. and I can document what it is for Scala programmers

that maybe don't understand much Java. So that is sort of a work that goes more into the details. That said, I mean, that's not the only Scala platform, so it was born on the JVM, but now it also exists on JavaScript and Node.js, on native. So it's really a multi-platform language. Open AI, Anthropic, Cursor, and Versailles all use this product to make their lives better. And the problem it solves is when you're building SaaS or an AI product and you want to sell to other companies, there's all these requirements you need to meet.

There's SSO, there's SCIM, there's RBAC, there's audit logs. These are all things that take time to integrate, but aren't the main focus of your app. WorkOS is an API layer that lets you meet all of these requirements in just a few lines of companies. in just a few lines of code. So let's say you have a new SaaS product and you want to sell to other companies, WorkOS will solve all of these critical feature gaps for you. You can check them out at WorkOS.com

to learn more and get started. And I appreciate them for supporting my work and sponsoring this podcast. Jira by Atlassian isn't just for tracking work anymore. Now you can pick your favorite AI agent to assign tasks to and they'll get access to the rich context that's already in Jira. When the agent is done, it surfaces a poll request.

That way, you can get more done with your favorite agents all in one place. Learn more at jira.dev. That's j-I-R-A.d-E-V. Appreciate them for sponsoring the podcast, and back to the show. Let's say I write a Scala program. I have the source code. I have to compile it, and then I have some Java byte code. And then I call, I don't know, JVM, and I pass in.

this bytecode and it just works. Yeah, yeah, exactly. What would the advantage be of compiling Scala to Java bytecode instead of doing something like C and C++ where you compile it all the way to machine code from source? We have that too, and so the Scala native compiles directly using LLVM to native code. The advantages of compiling to bytecode is is essentially, again, the interop can use all the Java libraries.

Then the garbage collectors, so the JVM has actually very good garbage collectors, high performance ones, and the runtime loading. So what I can do on the JVM is I can compile, let's say, a one-line thing into a little Java bytecode, and they can immediately load that by code and execute that. And that makes it very easy, for instance, to have a Rappel, because that's how a Rappel would work, a VD1 print loop. So I would just generate a snippet of Scala code to bytecode,

load it into the running JVM process, and it gets executed. And that's much harder if you go to binaries, basically. Binaries don't really have a concept for that. You mentioned that you wrote a compiler for Java, like before Scala, and I've heard that compilers are notoriously hard to build. Can you explain the hard parts and why they're hard?

Compilers are very intricate because I think there are a lot of requirements on a compiler. So you have languages which are already complex artifacts. Then you have a thing called type inference. So you have a type system. But essentially you demand the compiler to essentially infer a lot of of types that makes sense because you as a programmer thinks where the compiler should know that and it should but actually for the compiler to do that is quite hard. And then then you of course

you also demand that it would generate very efficient code for your program because again the compiler should know that right. So there's a lot of demands on that plus there's a demand that it should be very very fast and to square all these demands requires quite a bit of work basically. There are also things that make it easier for compilers because they're fundamentally deterministic programs. So essentially you run a compiler on a source and you always get the same output. So it means they're easier to debug. You can just replay things and repeat things. Whereas if I would have some cloud service or distributed application, that has other nightmares, right, that every run is different and how do you even figure out

what goes wrong? So when you wrote that compiler, I think express, for Java. How long did it take to write that by hand? At the time, it took me about three months, I think. Not full time, maybe half time, three months, half time, something like that. But that was a very simple compiler too. So that's the other thing with compilers. They typically start simple. And when you had the 10-year mark or 20-year mark, then there's lots and lots of,

essentially, other requirements to a compiler that make them more complex. Were there libraries that you could rely on to to kind of piece together components of it, or did you have to write everything from scratch? I wrote, there was a library to generate bytecodes, I think. I think I used that in that version. Yeah, I did, yeah. So there was a library that essentially a high-level library

to just assemble bytecodes and put them into the right format and things like that. But that was essentially it, the rest I wrote by hand. That's crazy because, well, I mean, these days a lot of people, even more so now we're thinking less, using AI more to kind of write the code. So that's pretty impressive. I saw one of the big, I guess, moments for Scala was that Twitter adopted it.

And I wanted to know the story behind that. How did they choose such an obscure language at that time? Well, it was very obscure at the time. That's true. So I believe the story was Twitter. Originally was written in Ruby. and it wasn't very reliable because I believe it's again a problem with garbage collector and memory management and things like that.

So the, and it was a small company at the time, so 25 people, including the ops people. And essentially the board and VC investors said you can't go on like this, being unreliable like that, you should do Java because Java was sort of the solid choice. at the time. But some of the engineers at Twitter, they wanted essentially something more fancy as a programming language. And there were some people who knew Okamo and liked Okamo. But of course Okama didn't run on the JVM. And then they found Skada and said, well, it's kind of quite a lot like Okamo. And we can tell our investors that we do Java because that's not a lie. We do JVM. JVM bytecoted. That's essentially what it comes down to. So

So that's why they picked it. And they were quite the first. But once they picked it, so if the flood gets opened, because at that time, they were a very, interesting company and a lot of people admired them. So a lot of people followed and did the same thing then. Mostly they came from dynamic languages. So Twitter came from Ruby, others came from B.HB or, yeah, JavaScript, things like that. I mentioned a little bit that AI is kind of generating a lot of code.

And I wanted to ask you what you thought maybe the future of programming languages might look like if you kind of speculated or drew out further into the future. Like if AI is generating more of the code, how do you think that might affect the programming language ecosystem? Yeah. I think right now we're sort of in an existential crisis, right? So we have AI generating the code, but humans being asked impossible tasks like to review all these mountains of code and things like that,

which will never work. And at the same time, AI has also gotten extremely good at exploiting vulnerabilities in code, like we all heard of fable and things like that, that you can't use it anymore because it's too dangerous, it will exploit things. So we are at a moment where it's essentially very dangerous that we lose control as humans

of what actually happens here. And that's a challenge that I think programming languages can help meet. And probably definitely not only programming languages. That's not a silver bullet. But they definitely can help things. So I think one of the things is that the focus, if the code is AI generated, then the focus has to go elsewhere. And I think the focus will go to the interfaces and to the types.

So I expect types will become a lot strong. and more precise than what we had, because types is essentially the handle that we can make a contract between the human and the AI that the human can understand, and that's concise enough to be reviewed, and that essentially the AI can keep to. We have to level our game quite a lot,

because right now, I mean, let's face it, type systems are mostly recommendations. they're mostly things that mostly hold but not always there are no guarantees because you can always have a cast or well you use some dirty memory or I mean there are a lot of techniques to sort of undermine the type systems

and we have to close all these holes from the beginning because once there is a hole somebody can exploit it so I think strong types strong high level types will help And then I think the other part is generally the programmer has to think much more about what are the requirements and what are the, essentially, the high-level specifications and be able to leave the code to be generated by somebody else in confidence. And I think we're not quite there yet, but we have some ideas how we could get there. So one technique that I believe we can use, and it has been around for a long time, but maybe its time has come now, there's capabilities.

Capabilities essentially was used in operating systems to give very fine-grained permissions to entities, users, programs, and things like that. And I believe that can be used also for agents and agentic AI to say, well, once we have agents, we have to give agents very precise and fine-grant capabilities what they can do and that lets us essentially be confident about what they will not be able to do. Like they will not be able to leak my API keys or my email or do other things, right? So I think that's an important part. And the existing languages are not there yet. I think Scala is halfway there.

At least it's there where in essentially stuff we're working on, which we have in the lab and we have released as an experimental feature. So I'm quite excited about that. The first thing that you have to do is definitely be memory safe. So a language that essentially is not safe in memory, that lets you essentially access undefined memory is immediately out because you can't guarantee anything. So in that sense,

It's good that there is a drive to use, let's say, Rust as a memory-safe language, that was even promoted by the American government, I believe. So that's definitely a very useful drive. But I think you need a lot more because you need much, Rust talks essentially mostly or only about memory. You need to talk about a lot more things than memory. You need about essentially read permissions, write permissions, access to secrets, all these things that go beyond that.

And you could say, okay, Martin, you're totally unrealistic because all our software is written in C and C++, and we will not be able to rewrite that. But that, I believe, AIs can help there, right? So AIs are great in rewriting software. So if we know what to rewrite too, I think we might be able to get there. You mentioned some of those experimental features in Scala that might have some sort of safety guarantees or signal capabilities.

Can you explain what that might look like or maybe give an example? So a simple example would be, let's say somebody gives me a file and I have access to the file, let's say a log file or something like that. I have access for a file for a limited time and then I need to close it. So typically I have an operation that essentially somebody passes a file to me, to an operation that my program provides, and the program decently with the file, and then the environment will close it. But how do we make sure that I don't hold on to the file

after I get it back to the environment or after I pretend it I'm finished with it? Because, hey, I have a file. I could have stored it in a variable. I could have stored it on the side. I could have gone back to it and done it. something with it. So capabilities help me prevent that because essentially I can say, okay, so this file is a capability, and then I can further say, well, this capability can be used

only in a limited scope, and the type system will make sure that the capability doesn't escape. And the way we do that is that if a type refers to capabilities, so if I have a thing that I say, I give you back a lambda or a stream, and it holds on to the file. So the stream holds onto the file in secret. In our language, that won't be a secret anymore because the type has to declare that the thing I return does hold on to the file. The file is a capability,

and I can't essentially hide coverabilities I have access to in my type. I have to declare them. And that gives me essentially this control that then I can also enforce to say, well, at this point, you're not allowed to have any capability because the type that I enforce you to have is a type that doesn't hold capabilities. And that's that way I enforce with the type system something,

which previously hasn't really been enforceable. For memory safety, it's essentially the same thing with arenas that I have an area where I allocate memory and then I want to get rid of it. I have to make sure I don't have pointers pointing into it. And that's exactly the same situation. And let's say for accessing secrets again. So it's a very common pattern that I say in certain situations, I want to make sure that you don't have,

that you only have a set of defined capabilities that I give you and nothing else. You mentioned memory safety is an absolute table stakes. What are the programming languages that you think of that are not memory safe? I know there's C, but what are the other ones? The big ones is C, C++. I don't know about, I think Zic on N. or other low-level systems languages are not memory-safe. So that was sort of in Rust, a big achievement

that you say you can be a low-level systems languages and be memory-safe. Nobody sort of thought that it was possible before Rust came. So that's why I would think, I don't want to say anything wrong, but I would think that essentially most other low-level systems languages would not be memory-safe. But you really need more than memory-safe,

you really need capability safe that you say when I essentially hang on to tell you, I can't sort of forget capabilities to say I hang on to something and I just conveniently forget that I have access to that. And I can't forge capabilities to say, well, if I need a capability, I just make one up. So these two things need to be prevented. And that goes beyond memory safety. But memory safety, without memory safety, essentially you have nothing because it can fake everything. A lot of programming language design and how we write code in the past is writing the source code so that it's nice for humans to read.

But if humans are no longer interacting with the code, what kind of things come to mind that we might not care as much about but are good for machines to read, for instance? The first thing is maybe sometimes you want to read it, but you probably wouldn't have written it. So easy to write is definitely not a big criterion anymore. Easy to read to some degree, yes. But that means you don't need any these sort of syntactic hacks like to write plus plus and C or things like that. That's easy to write, right? But I don't, I mean, I'm sure we will still have that,

but it doesn't really matter anymore. I mean, whether I write an assignment in long form or with X plus plus, whatever. So I think these things won't matter much less. The things that matter much more are, that continue to matter and are essentially high-level ways to constrain and specify what my program should do. So constrain what it should not do.

That's one of the things and also specify what it should do. And some people say it's a golden age for formal verification because we can be very precise in our specifications and our AI can actually not just furnish the program, but also the proof that the program actually meets the specification. And I think that's true. That's really very exciting in a lot of areas. But in the large, the problem is you often don't really have the formal specification

or it's just as hard to write a formal specification than to write a program or sometimes even harder. So that means that we will still live in a world where we specify, things by natural languages, by prompt to the agent, and the agent then will do the code. But I imagine that also that will be a lot more formal in a way. So in a sense right now the prompts, I mean it's fantastic what they can do with the prompts, but then we throw away the prompt or it's hidden in the chat history with the agent. So that's really a shame.

So I really should have the prompts as first-class values in my program. in my program that I can say, well, essentially that's what the program is about. And if I change the prompt, then the AI will know essentially what the incremental change was and changed the program incrementally, these sort of things. That's another thing that I think we'll see in future programming languages for agentic programming. Maybe like some kind of meta information about the program, almost like a Git blame, but like a prompt, I guess, blame of what generated that. that part of the code.

You should be able to keep that around and come back to it. Also because you might want to change, right? You might want to say, well, now it's exactly the same, but I want to change this little detail, but I don't want the LLM non-deterministically to generate a new program because that way, well, it might get a lot of other things wrong that I reviewed already.

So there really should then be an incremental, small change to the code. And that means I need to keep the prompt as a part of my program. Ten years from now, do you think there will be more software engineers than today or less? I think there will be less. And it will be a higher profession that is essentially has higher standards. So it will be harder to become one. We will be able to know quite a lot of logics and maths to be competent at essentially, keeping AI on the good track and things like that.

It's sort of, you can say, it's sort of like a control engineer for a factory where you don't understand many things initially. It means that there must be more, you must be higher skilled than a factory worker of 50 years ago or something like that. And I think the same will happen for software where you will need fewer but more qualified people.

One thing that a lot of people recommend is to become better at programming, you should learn multiple languages. And I wanted to know, aside from Scala, what are the top programming languages you would recommend people learn to expand their mind? So definitely a systems language, I think, to know how hardware works

and how software links with hardware I would learn a systems language. And I'm sort of torn between C and Rust there, because C is going for it that it's very simple and very close to the thing. In Rust you have to learn a lot of obstructions, but on the other end, it is memory safe. So I would say probably initially C to figure out what these things are. And then if you decide to become a systems programmer as a career,

then you should switch to rest, I guess. So that would be one thing. The other thing would be something more with a verification improving background because that will be a lot more, will become a lot more important. So I would actually do a course in Lean or Rock one of these languages to say we should be able to use AI or to develop first an intuition what it means for a program to be correct.

Because I guess most people have only a very, very fuzzy intuition for these things and learning one of these languages would sharpen the mind there. So I think those, and then, of course, Scala too, there's a language that essentially sits right in the middle where fairly provable, strong types, high expressivity, these sort of things. When you think of a top technical book

that you might recommend people, does anything come to mind? I got a lot out of structure and interpretation of computer programs. That was a book from the 90s, It was the intro text at MIT at the time, or 80s even, I think. And in fact, the courses I taught on Coursera and at DPFL are based quite a lot. To some degree, they're based on that material.

So, of course, not the same language and strong types instead of dynamically type, but still. When you look back on your career, why did you choose to work in academia instead of industry? When I came to the end of my studies, I was. was asked to do a research project and the project I picked or the prof then asked from me to modulate that a little bit. In the end I found it super interesting to say I work on something that I don't know whether it has a solution or not. So it might be that the question is yes, it might be the question is no, we have to do research. And that's sort of how it started. And then I believe the main advantage of the advantage of

of being in academia is really the long term and being independent. So in the long term, I mean, in the industry, I'm sure there are many periods, including now where I could be paid 10 times what I'm being paid at university, if I joined Google or any of the other companies in Silicon Valley. But then times also change, and sometimes essentially what you do is not wrong or relevant, and then it's very easy to get fired and to, then you say, no big deal, I can do something else.

But at a university, you have essentially long-term tenure to do exactly what you want. So no manager. You can define your own research agenda. Of course, you have to get some money. That is hard. You have to get grants and things like that. You have to convince students that what you do is the right thing. But that's also very rewarding, working with students.

So I think in the end, I'm very happy that I took the career I took. What about looking back on Scala? You know, do you have so much experience there? What are some things that went well or things that didn't go well and maybe some learnings you could share? Scala was initially this experiment that we could combine object-oriented and functional programming. And technically that experiment was a big success.

In terms of the ecosystem, it had a lot of challenges. I don't know, better you know, there was a short, incomplete history of programming languages by James Irie, which is quite hilarious. And there's a scholar entry there that this says I discovered Reeves' sputter sandwiches and I had an idea to

essentially have a language where you put in both object and functional, and then it ends with this pieces of both communities and they promptly declared jihad. And that's at the beginning, it was very funny, but in retrospect, that's to a large degree what

happened. I mean, there was, there were of fights and cultural fights and things like that. So, and we might have, it was a challenge and I don't know, in retrospect, I think it might have been more prudent to be more careful introducing functional features because that sort of was, we went in essentially quite complete. So essentially you can port most Haskell programs to Scala, maybe you find them a bit less attractive looking, but you can do it.

And that brought in essentially different cultures very, and it caused a big clash of cultures. So for instance, in Goh was a lot maligned because they didn't even have generics, right? And it's true, it was a ridiculous language. But by not having it. it initially you sort of form a culture that when you add it, nothing much will go wrong and people won't over-abstract or things like that.

And by essentially going full hog into it in Scala from the start, we were not protected against that. And people did reach abstraction peaks and over-abstracted and things like that. And they still do it to this very day. So essentially having fancy abstractions is great, but you have to use them responsibly. and that then it sort of clashes with the natural urge to just try out all these fancy things and do something that in the end maybe neither you nor nobody else understands very well.

And it could have just been a simple map or things like that, but yeah, why do I use that when it can be complicated? Why would that upset someone? Because of the library ecosystem, I think, that the... So the libraries are important because they sort of set the agenda how you express the programs. In particular, the libraries that come from the Haskell site are essentially monadic frameworks and they require you to express your whole program as a monad, which is a concept that works well in functional programming. I have my reservations.

I wouldn't actually do that in my Scala programs. But by having prominent libraries out there, it's quite normative that people feel like they're being a Scala programmer, they're required to program this way. And then, of course, there are opinion leaders and conferences and all these things that tell you how you should be writing your programs. But I would say I think the most of the Scala community is actually very, very level-headed. and I think most of the advice is great. But then, yeah, it's still a challenge because it's just too easy to, mostly it's not really the opinion leaders in the community, but let's say it's your boss, you have a small team in a company,

your boss came from Haskell and says, hey, this is great, we do exactly like Haskell, the whole thing. And then three years later, the boss's boss says, nobody can understand this code and the project is cancelled. So these things happened in the industry. I'm not saying that all projects are like that, not at all. I mean, there are lots of really great success stories of Scala, but that's essentially a challenge.

In terms of techniques, I think in the end, I wish we had been a bit less dependent on the JVM. in the sense that we took a lot from Java that intuitively makes sense and was very important for interrupt but in the end wasn't could have been done better so for instance

in Java being an object-oriented language you have universal methods like two string and equals and hash code and they're defined for everything and languages like Rust or Haskell there are no more discriminating. They have a thing called type classes where essentially you at compile time you tell exactly where you have equality and hash code and these things. And it's a bit more tedious to set these things up but it in the

end it's also safer. So I wish we had that and we didn't we couldn't because you sort of adapted Java's notion of what an object is and it already came with all these things which is sort of very convenient but in the end cost friction. If I went back to you at that time when you were starting it, I said, what do you think is going to happen 20 years from now? What would you have said? I would probably have said that it was a footnote in memory. Because, I mean, let's face it, you do a thing.

And initially we had maybe five users or something like that, outside our group, something like that, right? So you don't really expect that it would change a lot. And so, so. So no, I think it was quite by surprise that this actually happened. And I think the reason why it happened was that at the time Scala was a good bridge between dynamic languages that are slow and sometimes they crash and solid languages, statically typed languages like Java, which were at the time quite cumbersome to write code and there was a lot of ceremony and things like that.

And Scala had to the infer types, so you had types, but you didn't see them much. So it felt like a dynamic language, but it had also the solidity of essentially a good platform. And I think that's what made it. And we've been copied a lot by a lot of other languages that put in these features than five or ten years later or things like that. But at the time it was sort of Scala,

that was the first one that had it. And that's sort of why it happened. But I wouldn't have foreseen that by no means. Looking back on your career, when you just graduated college and kind of started your career, knowing what you know today, what advice would you give your younger self? I think to take risks be adventurous paid out,

so essentially don't follow the mainstream. team. If you take a fancy to do something wild and crazy, technically take the time to do it and do it. But I mean, yeah, so that's what I would. Of course, I mean, you still need to sort of stay on track somewhat, but I don't want you to exaggerate that either. But yeah, so basically be a bit non-confirmist. Awesome. Well, thank you so much for your time, Professor. I really appreciate it. Thank you, Ryan. Hey, thank you for watching this podcast.

If you liked it and you want to see the show grow, please support with a comment or a like. Also, if you have any recommendations for people you want me to bring on, please drop a comment. Guests like Barbara Liskov, Mike Stonebreaker, Mark Brooker, these were all people that I brought on because someone left a comment. On another note, aside from the podcast, I'm working on building the ergonomic keyboard that I wish existed. Here's a glance at the prototype. It's a split keyboard. So there's two sides. This is in the case.

But yeah, we launched on Kickstarter and we hit our goal within eight hours of launching. I really appreciate it if you were one of the people who grabbed one of the early units. We're now working on the long journey of building the tooling now. And so if you still want to pick one up, I've left the late pledges open on Kickstarter.

So you can grab one there. I'll put a link in the description. Thank you again for watching the podcast and I'll see you in the next episode.