Creator of Scala: Comparing Languages And How AI Will Impact Them | Martin Odersky

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-done Podcast 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=n49ky Thank 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) Outro Where 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/odersky Where 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/@ryanlpeterman Referenced 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

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  We are at a moment where it's essentially very dangerous that we lose control as humans.

• 0:06Ryan Peterman?

  This is Martin Odersky, the creator of Scala, and I asked him all about programming languages and how they're going to change in the future.

• 0:13Speaker 00

  I believe right now Rust is actually overused. So Zig, 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.

• 0:33Ryan Peterman?

  10 years from now, do you think there will be more software engineers than today or less? Here's the full episode.

• 0:44Ryan Peterman?

  What is functional programming and why should an imperative programmer care about the functional way of programming?

• 0:52Speaker 00

  So functional programming is programming with values. So you don't have state that changes, like mutable 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.

• 1:35Speaker 00

  And the benefit you get from that is essentially much better predictability and fewer bugs because the 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, they can, essentially they're an undocumented effect of your function, so it's not reflected anywhere typically, but maybe you have a comment if things are good. And, 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.

• 2:19Speaker 00

  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 that 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 coefficient at point three, 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.

• 2:58Ryan Peterman?

  What would you say to someone that doesn't do functional programming? Because it's not convenient.

• 3:04Speaker 00

  I guess two things. One is it's a learning curve. So initially, you, 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, I can, 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, through my program with a debugger or things like that to, to figure out what it does.

• 3:47Speaker 00

  Typically, I don't need a debugger when I write functional code. That's really not, not, not necessary. The, 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, and wrap them up in monads or whatnot. And that can get very inconvenient very quickly. So the, 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, and you, you use that.

• 4:32Speaker 00

  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.

• 4:45Ryan Peterman?

  Is there any quantitative measure of the, I guess, the correctness benefits that functional programming gives you over imperative?

• 4:56Speaker 00

  I think there are some studies.

• 5:01Speaker 00

  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 bugs than 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 come, are, become more important in large programs than in small ones. For small ones, you can do anything, really. You can write it, you can write a loop, you can write a recursive function. It doesn't really matter. And it's, 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

• 5:45Speaker 00

  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, you will, 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 the feeling that mostly functional statically typed languages is sort of a sweet spot for, 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 Rock or Lean or any of these things, these are all functional languages.

• 6:29Speaker 00

  So people wouldn't, wouldn't even attempt to do something like C, C++ here.

• 6:35Ryan Peterman?

  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?

• 6:47Speaker 00

  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, in a nice synthesis. So that was what, 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. Object oriented 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.

• 7:31Speaker 00

  I mean, there are languages like standard ML or OCaml that do have very capable module systems, but other functional languages don't. And, 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.

• 7:50Ryan Peterman?

  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?

• 8:00Speaker 00

  It's sort of ingrained, it's in the whole fabric of the things that everything is essentially objects, what, what you do.

• 8:09Speaker 00

  So, so one thing that you get is what I think Simon Peyton 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 you can use them. So it focuses your mind, whereas in functional programming, it's typically, you have a sea of functions that can be, be applied to arguments and you have to figure out what they are.

• 8:34Ryan Peterman?

  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.

• 8:46Speaker 00

  In this day and age, a systems programming language 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. Go is really not, not a sort of a nuts and bolts systems programming language. This 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, which you would, would use Rust for. So I think in their domain, both of them are, are probably the ones that, that are the leading ones that I would take most seriously.

• 9:27Ryan Peterman?

  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?

• 9:40Speaker 00

  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 passes. I mean, garbage collector, collectors have become quite, quite capable. I mean, they're brilliant and the passes are really very, very small. But it's, it's, it's a fact that you do need a big chunk of memory to run fast. And I guess Rust could, could run in much, much smaller memory. So I believe that's, 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 rush Rust for things higher, higher up in the stack where you, a

• 10:22Speaker 00

  garbage collector is fine, but essentially you, 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, really think there's a, 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, it, it can be much simpler. So that was for Rust. For Go, Go is sort of a language a bit that that lags behind.

• 11:07Speaker 00

  I mean, it was intentionally designed to be to be very, very small and essentially to be the standards of the languages 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 of 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's programs and essentially jump in a new code base and things like that. So I think that would be my main advantage of Go that I see there.

• 11:51Ryan Peterman?

  Is it possible to turn off the garbage collector in Scala?

• 11:55Speaker 00

  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 you can leak references into memory that you reclaim and then all hell breaks loose, essentially your pointers, you point to memory that's undefined and so. 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.

• 12:39Speaker 00

  So right now, I would say, you use the garbage collector in Scala, yeah.

• 12:42Ryan Peterman?

  I see a lot on the internet, people comparing Rust and Zig or kind of a fierce debate on which one is better. When you think about Rust versus Zig, what are the merits of the two compared comparing to each other?

• 12:58Speaker 00

  So what I can see is Zig has a really nifty compile time construct, essentially inlining, where the compiler does smart inlining and and that is quite clean and quite powerful. And Rust has macros, but I think they're more clunky than there is than the Zig version. In Scala, we have something quite close to Zig. We also have essentially a thing that's based on on inlining and optimizations by the compiler. But we have a restriction which I believe Zig doesn't have, and that is that there cannot be additional type errors after inlining.

• 13:41Speaker 00

  So the thing is inline, and then the question is, is the inline program guaranteed correct? So type correct? Or might you have type errors? Typical example where you might have type errors is C++ templates. In fact, that's quite scary in C++ that you can expand a template and then you get very, very complex type errors and very, very hard to debug things. So Zig is, I believe, is much better because the the inlining mechanism is much saner.

• 14:10Ryan Peterman?

  When you say inlining, can you explain the concept?

• 14:13Speaker 00

  Inlining just means that in in Scala, we can write inline in front of a 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 it will 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.

• 14:53Speaker 00

  So and with that, you can already do quite a bit of essentially optimizations which are guaranteed because the the inliner must inline. 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 typer, must inline, so you can rely on it. And const explore by in Zig and C++ is essentially very similar.

• 15:26Ryan Peterman?

  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, inline?

• 15:37Speaker 00

  Yeah, you reveal the implementation and that means you you can you can, the compiler can do something with that.

• 15:45Ryan Peterman?

  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?

• 15:53Speaker 00

  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 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.

• 16:23Ryan Peterman?

  If you compare Scala to Python, for instance, I guess, what are the trade offs that the two languages took?

• 16:30Speaker 00

  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. And Python is getting some of the features that Scala had since the beginning, like pattern matching is in one of the the recent Pythons. 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 this sort of all drift to a standard set of features, which mostly come from 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.

• 17:12Speaker 00

  And so the gap is closing in that in that sense. Python is, I think the main advantage of Scala over Python is that it is it has a strong type system that is always on and that gives you essentially guarantees that essentially certain bad states can't can't can't happen. So it's a really can rely on it. Whereas I think I believe the Python type system, well, it's just syntax, it has a number of type checkers, but in general, there's there's 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.

• 17:54Speaker 00

  Tactically, the two languages, I think with Scala 3, are actually also quite close. So Scala 3 looks a lot like Python. In that sense, you could say, well, can see it as a is a language that has strong types and runs on 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 to high performance C++ libraries, pandas or numpy or things like that.

• 18:31Ryan Peterman?

  You mentioned that a lot of the programming languages, they're kind of drifting or kind of being inspired by the other ones and, you know, adopting new features. In the design of Scala, is there a programming language that you admire most and influences Scala the most?

• 18:48Speaker 00

  Historically, Scala was essentially, you could say it was a blend of Java, OCaml and or standard ML, which is close, an ML-like language, and Haskell. So I I I'm by trade, well, I'm by trade an imperative programmer. My PhD is from Niklaus Wirth, so 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 I looked very closely at ML, OCaml, Haskell and these things. And then the Scala came about, sort of, there was a predecessor language called Pizza.

• 19:29Speaker 00

  And I was working on that with Phil 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 JVM at that at that point. And the, 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 I was quite dismissive at first, but afterwards I found it actually quite useful. I mean, this was very early Java, this was Java even pre 1.0. So so now Java is is of course even more useful, but also a lot bigger than what it

• 20:13Speaker 00

  was at the time. So when we came up with with Scala, which was sort of the second iteration after Pizza, Pizza was the language I did with Phil Wadler, the

• 20:26Speaker 00

  Ideas came mostly from Java, OCaml 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 OCaml and Haskell, you could say. But you recognize a lot of things coming from both of these languages.

• 20:48Ryan Peterman?

  If I recall correctly, Java had some sort of licensing with it or was owned by a company. How were you able to build on top of Java? Or did you have to pay for licenses? Or how did that ecosystem work?

• 21:04Speaker 00

  The language standard was open source. There was a lot of experimentation with Java at the time. I think the only thing that Sun, that was the company at the time, they're very particular about is that you absolutely, 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#, which was sort of a Java on some steroids. They threw in a bit more than what Java had at the time.

• 21:47Speaker 00

  I think the nastiness came, 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 forged Scala on Android, Java on Android, and that's when the fight started. But that was much later.

• 22:15Ryan Peterman?

  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 uses the JVM? Like, how does Java source code eventually execute on a machine?

• 22:31Speaker 00

  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 can, 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 JVM.

• 23:13Speaker 00

  I have to make sense of all these Java libraries out there, so I have to somehow map a Java concept into a Scala 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 sort of 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 Wasm, and on Native. So it's really a multi-platform language.

• 23:49Ryan Peterman?

  OpenAI, Anthropic, Cursor, and Versale 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 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.

• 24:32Ryan Peterman?

  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 pull 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 dot 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 bytecode.

• 25:12Ryan Peterman?

  And then I call, I don't know, JVM, and I pass in this bytecode, and it just works.

• 25:18Speaker 00

  Yeah, yeah, exactly. Yeah.

• 25:21Ryan Peterman?

  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?

• 25:32Speaker 00

  We have that too. And so the Scala Native compiles directly using LVM to native code. The advantages of compiling to bytecode is essentially, again, the interrupt, 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 I can immediately load that bytecode and execute that.

• 26:13Speaker 00

  And that makes it very easy, for instance, to have a REPL, because that's how a REPL would work, a redeveloped 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. The binaries don't really have a concept for that.

• 26:33Ryan Peterman?

  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?

• 26:46Speaker 00

  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 types that make sense, because you as a programmer think, well, the compiler should know that. And it should, but actually, for the compiler to do that is quite hard. And then, of course, you also demand that it would generate very efficient code for your program, because, again, the compiler should know that, right?

• 27:30Speaker 00

  So there's a lot of demands on that. Plus, there's the 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?

• 28:07Ryan Peterman?

  So when you wrote that compiler, I think Espresso for Java, how long did it take to write that by hand?

• 28:15Speaker 00

  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, that typically start simple. And when you're at 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.

• 28:36Ryan Peterman?

  Were there libraries that you could rely on to kind of piece together components of it, or did you have to write, you know, everything from scratch?

• 28:45Speaker 00

  I wrote, there was a library to generate bytecode, 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 bytecode and put them into the right format and things like that. But that was essentially it. The rest I wrote by hand, yeah.

• 29:06Ryan Peterman?

  That's crazy, because, well, I mean, these days, a lot of people, even more so now that we're thinking less, using AI more to kind of, you know, 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?

• 29:29Speaker 00

  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 the 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

• 30:14Speaker 00

  as a programming language. And there were some people who knew OCaml and liked OCaml. But of course, OCaml didn't run on the JVM. And then they found Scala and said, well, Scala is actually quite a lot like OCaml. And we can tell our investors that we do Java, because it's not a lie, we do JVM, JVM bytecode, and that's essentially what it comes down to. So that's why they picked it. And they were quite the first. But once they picked it, sort of the floodgates 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.

• 30:53Speaker 00

  So Twitter came from Ruby, others came from PHP or JavaScript, things like that.

• 31:00Ryan Peterman?

  I mentioned a little bit that, you know, 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?

• 31:21Speaker 00

  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

• 31:55Speaker 00

  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 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 stronger and more precise than what we had.

• 32:37Speaker 00

  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 value, you use some dirty memory. I mean, there are a number of, a lot of techniques to sort of undermine the type systems. And we have to close all these holes from the beginning

• 33:20Speaker 00

  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,

• 34:02Speaker 00

  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, but once we have agents, we have to give agents very precise and fine-grained 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.

• 34:45Speaker 00

  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 that's, in that sense, it's good that there is a drive to use, let's say Rust as a memory-safe language, or even that was even promoted by the American government, I believe.

• 35:30Speaker 00

  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 are, that are, that go beyond that. And you could say, okay, that, 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.

• 36:12Speaker 00

  So if we know what to rewrite to, I think we might be able to get there.

• 36:17Ryan Peterman?

  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?

• 36:30Speaker 00

  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 does something 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 pretended 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.

• 37:13Speaker 00

  I could have gone back to it and done 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 on to 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.

• 37:56Speaker 00

  The file is a capability and I can't essentially hide capabilities I have access to in my type. I have to be, 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, the same situation.

• 38:40Speaker 00

  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, or that you only have a set of defined capabilities that I give you and nothing else.

• 38:57Ryan Peterman?

  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?

• 39:08Speaker 00

  The big ones is C, C++, I don't know about, I think zig or nim or other low-level system 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 saves that you say, when I essentially hang on, tell you, I can't sort of forget capabilities to say, I hang on to something

• 39:52Speaker 00

  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, that goes beyond memory safety. But memory safety, without memory safety, essentially you have nothing because you can fake everything.

• 40:12Ryan Peterman?

  A lot of programming language design and how we write code in the past is writing the source code so that it's, it's, 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?

• 40:35Speaker 00

  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 of these sort of syntactic hacks like to write plus plus in C or things like that. That's easy to write, right? So, 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++ or whatever. So I think these things won't matter much less. The things that matter much more are, that continue to matter

• 41:15Speaker 00

  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 I mean, 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 finish 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.

• 41:58Speaker 00

  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 have, 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 the, 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, should have the prompts as first-class values in my program that I can say, well, essentially that's what the program is about.

• 42:42Speaker 00

  And if I change the prompt, then the AI will know essentially what the incremental change was and change the program incrementally, these sort of things. But that's another thing that I think we'll see in future programming languages for agentic programming.

• 42:57Ryan Peterman?

  Maybe like some kind of meta, meta-information about the program, almost like a git blame, but like a, you know, prompt, I guess, blame of what generated that, that part of the code.

• 43:10Speaker 00

  You should be able to to to keep that around and and come back to it. Yeah, also because you want 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 L L M 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 keep I need to keep the prompt as a part of my program.

• 43:40Ryan Peterman?

  Ten years from now, do you think there will be more software engineers than today or less?

• 43:46Speaker 00

  I think there will be less. The and it will be a higher

• 43:55Speaker 00

  profession that is essentially has higher standards. So it will be harder to become one. You will now be able to know quite a lot of logics and maths to be competent at essentially keeping A I on the good track and things like that. It's sort of can say it's sort of like a 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 fifty years ago or something like that. And I think the same will will happen for software where you will need fewer but more qualified people.

• 44:34Ryan Peterman?

  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?

• 44:49Speaker 00

  So definitely a systems language, I think, to to know how how how hardware works and how software links with hardware. I would learn a systems language and

• 45:01Speaker 00

  I'm sort of torn between C and Rust there because C has going for it that it's very simple and very close to the thing. In Rust, you have to learn a lot of abstractions, but on the other hand, 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 Rust, I guess. So that would be one thing. The other thing would be something more

• 45:30Speaker 00

  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 where we we should be able to use A I or to to to but to have to develop first an intuition, what it means for a program to be correct. Because I guess for most people have only a very, very fuzzy, fuzzy intuition for these things. And and learning one of these languages would sharpen the mind there.

• 46:06Speaker 00

  So I think those and then, of course, Scala too. It's a language that essentially sits right in the middle where fairly, fairly provable, strong types, high expressivity, these sort of things.

• 46:18Ryan Peterman?

  And when you think of a top technical book that you might recommend people, does anything come to mind?

• 46:23Speaker 00

  I got a lot out of Structure and Interpretation of Computer Programs. That was a book from the nineties. It was the intro text at M I T. at the time or eighties even, I think. And in fact, the courses I taught on Cozera and and at E P F L are based quite a lot. To some degree, they're based they're based on that material. So of course, not the same language and strong types instead of dynamically type, but still.

• 46:52Ryan Peterman?

  When you look back on your career, why did you choose to work in academia instead of industry?

• 46:57Speaker 00

  When I came to the end of my studies, I was asked to do a research project. And the project I picked or the proft and asked from me to modulate that a little bit. In the end, I found it super interesting to say, I I work on something that I don't know whether it has a solution or not. So it 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 then I I believe the the main advantage 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

• 47:40Speaker 00

  now, where I could be paid ten 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 no longer 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 do define your own research agenda. Of course, you have to get some money. That that that is is hard. You have to get grants and things like that. You have to convince students that what you do is is the right thing. And but that's also very rewarding, working with students.

• 48:24Speaker 00

  So I think I in in the end, I'm I'm very happy that I took the career I took.

• 48:28Ryan Peterman?

  What about looking back on Scala? You know, 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?

• 48:39Speaker 00

  Scala was initially this experiment that we could combine object oriented and functional programming. And technically, that experiment was a big success.

• 48:51Speaker 00

  In terms of the ecosystem, it had a lot of challenges. I don't know whether you know, there was a there was a short incomplete history of programming languages by James Irie, which is quite hilarious. And there was this there's a Scala entry there that this says, I discovered Reeves butter 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're promptly declared jihad. And that's at the at the beginning, it was very funny, but in retrospect, that's to a large degree what happened. I mean, there was there were there were a lot of fights and cultural fights and things like that. So and

• 49:34Speaker 00

  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 that you you find them a bit less attractive looking, but you can do it. And that was that brought in essentially different cultures very and it caused a big clash of cultures.

• 50:14Speaker 00

  So for instance, in Go, Go was a lot maligned because they didn't even have generics, right? And it's it's true, it was a ridiculous language. But by not having 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 into it in Scala from the start, we were not protected against that. And people did reach abstraction peaks and over abstracted and and things like that. And that's they still do it to this very day. So essentially, having fancy abstractions is great, but you have to use them responsibly. And then it sort of clashes with the natural urge to just try out all these fancy things

• 50:59Speaker 00

  and do 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?

• 51:13Ryan Peterman?

  Why would that upset someone?

• 51:15Speaker 00

  Because of the library ecosystem, I think, that

• 51:20Speaker 00

  the so the libraries are are important because they sort of set the agenda, how you express your programs. And in particular, the the the libraries that come from the Haskell side, they are essentially monadic frameworks and they require you to express your whole program as a monad, which is a concept that works well in function programming. I have my reservations. I wouldn't actually do that in my in my Scala programs. But by having prominent libraries out there, it's quite normative that people feel like they 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

• 52:05Speaker 00

  tell you how how you should be writing your programs. But I would say, I I think the most of the Scala community is actually very, very level headed and and and and I I think most of the advice is great. But then

• 52:21Speaker 00

  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 two years later, the boss's boss says, no, nobody can understand this code, this code in the project is canceled. 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.

• 53:00Speaker 00

  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, but in the end, and was very important for interrupt, but in the end wasn't, wasn't, could have been done better. So for instance, in Java being an object oriented language, you have universal methods like to string and equals and hash code, and they're defined for everything. And languages like Rust or Haskell, they're no more discriminating, they have a thing called type classes, where essentially

• 53:43Speaker 00

  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 would wish we had that and we didn't. We couldn't because we 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 caused friction.

• 54:10Ryan Peterman?

  If I went back to you at that time when you were starting it, I said, what do you think's going to happen 20 years from now? What would you have said?

• 54:17Speaker 00

  I would probably have said that, well, it was a footnote in memory. Because, I mean, let's face it, you do, you do a thing and initially we had maybe five users or something like that outside our group, something like that, right? So, and you don't really expect that it would change a lot. And so, so no, I think it was quite, 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

• 55:00Speaker 00

  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 inferred 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, then five or 10 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.

• 55:43Ryan Peterman?

  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?

• 55:55Speaker 00

  I think to take risks, be adventurous, pay it out. So essentially, don't follow the mainstream. 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-conformist.

• 56:28Ryan Peterman?

  Awesome. Well, thank you so much for your time, professor. I really appreciate it.

• 56:32Speaker 00

  Thank you, Ryan.

• 56:33Ryan Peterman?

  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.

• 57:17Ryan Peterman?

  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.