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

23:50Martin Odersky:OpenAI, Anthropic, Cursor, and Vercel 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.

24:27Martin Odersky: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 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.

25:05Martin Odersky: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. So the Scala native compiles directly using LLVM to native code. the advantages of compiling to bytecode 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 a bytecode and they can immediately load that bytecode and execute that.

26:12And 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. Bineries don't really have a concept for that.

26:33Martin Odersky:You mentioned that you wrote a compiler for Java 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 types that make sense because you as a programmer think the compiler should know that, and it should. But actually for the compiler to do that is quite hard.

27:21And then, 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.

28:07Martin Odersky:So when you wrote that compiler, I think Expresso 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. So that's the other thing with compilers. They 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. Were there libraries that you could rely on to kind of piece together components of it, or did you have to write everything from scratch?

28:46I 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.

29:07Martin Odersky:That's crazy because, well, I mean, these days a lot of people, even more so now, are 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? 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.

29:47So 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 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 Okamo. And we can tell our investors that we do Java because that's not a lie.

30:31We do JVM, JVM bytecode. 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. So Twitter came from Ruby, others came from PHP or JavaScript, things like that.

31:00Martin Odersky: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. 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.

32:18So 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 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, let's face it, type systems are mostly recommendations. They're mostly things that mostly hold, but not always.

33:07There are no guarantees because you can always have a cast or use some dirty memory. 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 it's time has come now this 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-grained capabilities what they can do, and that lets us essentially be confident about what they will not be able to do.

34:36Like, 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 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.

35:26That 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, It's 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.

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

36:17Martin Odersky: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? 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.

36:59But 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 that 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 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.

37:45So 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. The file is a capability, and I can't essentially hide capabilities 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 way I enforce with the type system something which previously hasn't really been enforceable.

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

38:56Martin Odersky: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 or NIM 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.

39:40But 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 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 without memory safety, essentially you have nothing because you can fake everything.

40:12Martin Odersky: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 sort of syntactic hacks like to write plus plus in C or things like that.

40:55That'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, 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 furnish the program but also the proof that the program actually meets the specification.

41:48And 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.

42:33So that's really a shame. So I really should have the prompts as first-class values 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 change the program incrementally, these sort of things. That's another thing that I think we'll see in future programming languages for agentic programming.

42:57Martin Odersky:Maybe like some kind of meta information about the program, almost like a get blame, but like a prompt, I guess, blame of what generated 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 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.

43:40Martin Odersky: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 essentially has higher standards, so it will be harder to become one. You 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 like a control engineer for a factory where you don't understand many things initially. It means that 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.

44:34Martin Odersky: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 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.

45:13So 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 with a verification-improving background because that 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 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 And then, of course, Scala, too, is a language that essentially sits right in the middle where fairly provable, strong types, high expressivity, these sort of things.

46:18Martin Odersky:When you think of a top technical book that you might recommend to 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 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 asked to do a research project.

47:01and the project I picked or the prof then asked for 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 being in academia is really the long term and being independent. So in the long term, I mean in 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.

47:49But then times also change, and sometimes essentially what you do is not only relevant, and then it's very easy to get fired, and 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.

48:28Martin Odersky:What about looking back on Scala? 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 whether 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 says I discovered Reeves butter sandwiches and I had an idea to essentially have a language where you put in both object and functional.

49:12and then it ends with dismisses of both communities and they promptly declare 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 were a lot 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.

50:04and that brought in essentially different cultures and it caused a big clash of cultures. For instance, Go 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 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 with 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.

50:48So 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 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?

51:13Martin Odersky:Why would that upset someone? Because of the library ecosystem, I think.

51:22So the libraries are important because they sort of set the agenda how you express your programs. In particular, 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 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.

52:08where 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 two years later, the boss's boss says, no, nobody can understand this code and the project is canceled. So these things happened in the industry. I'm not saying that all projects are like that, not at all.

52:54I 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 but in the end and was very important for Interop but in the end 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, they're more discriminating. They have a thing called type classes where essentially at compile time you tell exactly where you have equality and hash code and these things.

53:49And it's a bit more tedious to set these things up, but in the end, it's also safer. So I wish we had that. And 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:10Martin Odersky: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, well, 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? And you don't really expect that it would change a lot. And 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.

55:10And 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 5 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

55:42Martin Odersky: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, 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-confirmist. Awesome. Well, thank you so much for your time, Professor.

56:31Martin Odersky:I really appreciate it. Thank you, Ryan.

56:42Martin Odersky: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:17Martin Odersky: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.