Twitter had 25 people, its operations staff included, when its board and its venture investors told it to get off Ruby and onto Java. The engineers picked Scala instead, a language almost nobody was using, and satisfied the investors on a technicality: Scala compiles to the same bytecode Java does. Most language designers asked about AI defend their syntax. Martin Odersky, who created Scala, thinks the syntax is about to stop mattering and that the type system is the only thing left standing between a person and code no person will read.
"We have to level our game quite a lot because right now, I mean, let's face it, type systems are mostly recommendations."
Odersky wrote a compiler for Java before he designed a language of his own, took his doctorate under Niklaus Wirth, and teaches at EPFL, where the experiment that became Scala started with about five users outside his research group.
I listened to the full interview so you can skip it. 57 minutes of audio, 22 minutes of reading.
Here are the 15 takeaways that matter.
👤 Guest: Martin Odersky, the creator of Scala, who teaches at EPFL, took his PhD under Niklaus Wirth and wrote a Java compiler before designing a language of his own
🎙️ Host: Ryan Peterman, who writes The Peterman Post newsletter and was a staff software engineer at Instagram
📰 Published: 31 August 2026
🔴 YouTube | 🟢 Spotify | 🔗 Episode page | ⏱️ 57 min | ✅ Time saved: 35 min
Key Takeaways
Type systems today are recommendations, and that is the thing AI breaks
The type is the only contract a person can still review once a model writes the code
Casts and raw memory access are the holes, and a hole is what gets exploited
Rust is being used for work a garbage collector would handle
He would keep it for embedded systems and hand the higher layers back to a collected runtime
There will be fewer software engineers in 10 yrs, and a higher bar to be one
His comparison is a factory control engineer, not a factory worker
Fine-grained permissions, borrowed from operating systems, are how you fence in an agent
The guarantee he wants is negative: the agent cannot reach your API keys or your mail
Python's types are syntax, not enforcement, and that is the whole remaining gap
He says the culture around the language does not value them either
A 25-person Twitter chose an obscure language and told its investors it had complied
The engineers wanted something better than Java and the JVM gave them cover
The prompt should be stored in the program, not thrown away with the chat history
Otherwise a small change forces the model to regenerate code that was already reviewed
Formal verification does not scale, because writing the specification is as hard as writing the program
He would have introduced Scala's functional features more slowly
Shipping the whole functional feature set at once imported a second engineering culture with it
Academia costs him a factor of 10 in pay and buys a research agenda nobody can cancel
Learn C before Rust, then learn a proof language you will never ship
1. Values, Not Mutable State
The interview opened on the definition, and Odersky gave it without the jargon.
Functional programming is a program built out of values and functions that turn values into other values, with the state changes pushed as late as possible. "So functional programming is programming with values, so you don't have state that changes, like mutable variables that change or arrays that change."
Real functional languages are impure, he said, because at some point a program has to write to a file or to standard output. The discipline is about how much of the program sits in front of that point
The payoff is predictability and fewer bugs, because a write to a global variable is an effect that nothing in the function's signature declares and nobody can hold in their head
The argument he finds most convincing is the mathematical one. A theory of polynomials or lists has no concept of mutation in it at all: you transform a polynomial into a new polynomial rather than changing the old one and calling it the same thing
On the convenience objection he gave a ratio rather than a principle. "I would say functional programming is great for 95% of your program, and if you need some side effect, some imperative feature, for the last 5%, that's also okay."
Pure functional programming, which wraps every side effect in a monad, is where he stops. "And that can get very inconvenient very quickly."
The learning curve is real but short, and the reward he named is not needing a step-through debugger: "Typically I don't need a debugger when I write functional code. That's really not necessary."
Asked for quantitative evidence, he declined to claim any. Studies exist that show fewer bugs in a statically typed functional language than in C++, and he would not lean on them
"It's not quite clear how significant they are."
"I mean, I can point you to a study, and if you're a dynamic typing enthusiast, then you will point to another that essentially claims the opposite."
"So it's very, very hard to do empirical software engineering on that scale."
Where he does think the effect is real is in large systems rather than small ones, and in the proof assistants: Lean and Rocq are functional languages, and nobody attempts that work in C++
2. Where Scala Actually Fits
The claim for Scala is narrow and specific: it is the only functional language that is also a capable object-oriented one, and the two are fused rather than parked side by side
Object orientation is what brings components, modules and encapsulation, which he said most functional languages have no strong story for. Standard ML and OCaml are the exceptions, with real module systems
Asked what he can do in Scala that he cannot do in Haskell, he reached for a phrase of Simon Peyton Jones's, "the power of the dot"
"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."
The contrast: "Whereas in functional programming, it's typically you have a sea of functions that can be applied to arguments, and you have to figure out what they are."
"It's sort of ingrained in the whole fabric of the thing that everything is essentially objects, what you do."
3. Rust Is Overused Right Now
Memory safety is now the entry requirement for a systems language, which rules most of the field out. "In this day and age, systems programming languages need to be memory safe, guaranteed memory safe."
That leaves Rust and Go, at different levels. Go is for application servers, middleware and cloud infrastructure; Rust is what you use for embedded work
His view is that Rust is being pushed into work that does not need it — higher up the stack, where a garbage collector is perfectly adequate and hand-managing memory is an intellectual exercise
"I don't really think there's a big sense in it to write memory management for a garbage collector."
"But why should you? I mean, it can be much simpler."
The cost of a collected language is pauses and memory footprint, and he did not oversell it. "I mean, they're brilliant and the pauses are really very, very small." What a collector does need is a large chunk of memory to run fast, which is why he grants Rust the smaller devices
Turning the collector off is research rather than product. His group can now track escaping references in the type system, so a program could use its own allocator without leaking a pointer into reclaimed memory, but "That said, we haven't really shipped that in production yet."
On Go he was blunt about the design and generous about the result. It was deliberately built small, to what he called the standards of the 1990s, and "So now they have gotten generics, which is a big step."
The upside of a small language is that everyone writes it the same way, which makes an unfamiliar code base readable
4. Inlining, and Its One Rule
Zig's compile-time construct is the thing he singled out: the compiler does smart inlining, and he called it cleaner and more powerful than Rust's macros. Scala has something close to it
The difference between the two is a guarantee. Scala forbids new type errors after inlining, and Zig, on his reading, does not
"So the thing is, you inline, and then the question is the inline program guaranteed correct, so type-correct, or might you have type errors?"
The example he named for how badly this can go is C++ templates, where expanding one can produce type errors that are very hard to debug
Asked to explain inlining for a listener, he described the compiler taking a function body and substituting it at the call site before code generation, then optimizing what it can see
The point is that it is mandatory rather than discretionary: "An optimizer has essentially discretion whether they want to inline things or not, and so you can never rely on that."
The host restated it as removing the overhead of a function call, and Odersky corrected the emphasis: "Yeah, you reveal the implementation, and that means the compiler can do something with that."
5. Python's Types Are Syntax
Of the dynamically typed languages he picked Python, on ubiquity and readability. "Python is ubiquitous, and it has a nice syntax."
The other one he named was Scheme, which he likes for being grounded in computer science theory and the lambda calculus. "But of course Python is 100 times more popular."
Languages are converging, and the features they are converging on came out of functional programming — pattern matching, strong type systems, generics, polymorphism, closures
"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."
Pattern matching arrived in a recent version of Python, decades after Scala shipped with it
What has not closed is enforcement. Scala's type system is always on and rules out whole classes of bad state; Python's is a notation with checkers bolted alongside it
"Whereas I think the Python type system, well, it's just syntax."
"And I believe it's also the ecosystem and culture that doesn't value types as much in Python."
Syntactically he thinks the two have converged, and that Scala 3 reads a lot like Python
The advantage he gave Python outright is as connective tissue: "Python is a fantastic glue language because I can essentially have very, very efficient linkages to high-performance C libraries", with pandas and NumPy as the examples
6. What Scala Was Built From
Scala is a blend of Java, OCaml, Standard ML and Haskell: the ideas mostly from Java, the modules and component model from OCaml, the standard library from Haskell. The function names in that library still read as a mixture of the last two
He did not start out a functional programmer and says so plainly. "So I'm by trade an imperative programmer. PhD is from Niklaus Wirth." Pascal and Modula were his first generation of languages, and he liked them
There was a predecessor language, Pizza, built with Phil Wadler, one of the original Haskell designers. The goal was an accessible functional language on a platform people already used, which at the time meant the JVM
To prepare for it he wrote a Java compiler, and changed his mind about the language while doing it. "I was quite dismissive at first, but afterward I found it actually quite useful." He noted that the Java he was working against was pre-1.0, and that the language is both more useful and much bigger now
7. Sun's One Rule Was the Name
The host asked how anyone could build on top of a language a company owned without paying for it.
The language standard itself was open, and the experimentation around it was wide. "The language standard was open source."
Sun's one condition was the name: anything that used Java and had Java in it had to be called Java, and could not be shipped under a different one
Microsoft clashed with Sun over exactly that, walked away and designed C#, which Odersky described as Java with more thrown into it
He was clear that nobody building on the platform in that period was worried about the license. "So that was in the time frame from 1998 to 2004, 2005, something like that. And at the time, there was no issue."
He called Sun quite an open company at the time, and said the trouble arrived later, after Oracle acquired it
8. Bytecode Buys the Libraries
"So the JVM is essentially defined by its bytecode." The bytecode is an intermediate format a program is translated into; it is run first by an interpreter and then by a just-in-time compiler
Getting a new language onto the JVM is the easy half. "And so if you know how to output bytecode, and that's not very hard, then you can run on the JVM."
The work is interoperation: mapping a Java concept into a Scala one so the compiler understands it, and documenting it for Scala programmers who do not know Java
Compiling to bytecode rather than straight to machine code buys three things he named: the existing Java libraries, the JVM's garbage collectors, which he rates highly, and loading code at runtime
Runtime loading is what makes a read-eval-print loop work — compile a one-line snippet to bytecode, load it into the running process, execute it. He said that is much harder against a binary, which has no concept for it
Scala does compile straight to native code as well, through LLVM, and also runs on JavaScript, Node.js and WebAssembly. "So it's really a multi-platform language."
9. A Compiler in 3 Months
Compilers are hard because each demand on them pulls against the others. "Compilers are very intricate because I think there are a lot of requirements on a compiler."
The language is already a complex artifact before the compiler starts
Type inference is expected to work out what the programmer did not write, which he said is much harder than it looks from the outside
The generated code has to be efficient, and "Plus, there's a demand that it should be very, very fast."
The one thing that makes them tractable is that they are deterministic. "So essentially, you run a compiler on a source, and you always get the same output, so it means they're easier to debug." He set that against a cloud service or a distributed application, where every run differs and the failure is hard to even locate
Espresso, the Java compiler he wrote before Scala, took "At the time, it took me about three months, I think. Not full time, maybe half time."
He used one library, to assemble bytecode into the right format. "The rest I wrote by hand."
"But that was a very simple compiler." Compilers start simple, he said, and at the 10-year or 20-year mark the accumulated requirements are what make them complex
10. Why Twitter Picked Scala
The host asked how an obscure language got picked by a company everyone was watching.
Twitter was originally written in Ruby and was not reliable. Odersky attributed the trouble to garbage collection and memory management
The instruction came from the board and the investors, and the company receiving it was tiny. "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."
Java was the solid choice of the day, and that is what they were told to adopt
The engineers wanted something better, and the JVM gave them the cover to have it. Some of them knew and liked OCaml, which did not run on the JVM; Scala was close enough to OCaml and emitted JVM bytecode, so they could tell the investors they had complied and, as Odersky put it, "it's not a lie, we do JVM bytecode"
The adoption that followed was a status effect rather than a technical one. "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."
The followers came mostly off dynamic languages: Ruby, PHP, JavaScript
On how unlikely the whole thing was, he agreed with the premise. "It was very obscure at the time, that's true."
11. Types as the AI Contract
This was the longest stretch of the interview, and the one the host had come for.
He describes the present moment as an existential crisis for the discipline. "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."
The same capability runs the other way. "And at the same time, AI has also gotten extremely good at exploiting vulnerabilities in code", to the point where he cited code that can no longer be used because it is too dangerous
"So we are at a moment where it's essentially very dangerous that we lose control as humans of what actually happens here."
If a model writes the code, the review has to move to the interfaces and the types. "So I expect types will become a lot stronger and more precise than what we had."
"Because types are 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."
Today's type systems are not strong enough to carry that, and he said so about his own field. "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." A cast, or a read of raw memory, is a way around the guarantee, and every one of those has to be closed before it is used
Memory safety is the floor rather than the answer. He credited the push toward Rust as a memory-safe language, which he said the American government had promoted, but said memory is only one of the things a program has to be constrained about — read permissions, write permissions, access to secrets
On the objection that the world's C++ cannot be rewritten, his answer was that the same technology fixes it. "So AIs are great in rewriting software."
Capabilities, and a log file
A capability is a fine-grained permission, and the idea is old. "Capabilities essentially were used in operating systems to give very fine-grained permissions to entities, users, programs, and things like that."
The worked example he gave is a file. A program is handed one, does something with it, and hands it back for the environment to close. Nothing in an ordinary type system stops the program keeping a reference and coming back to it later
The fix is to make the file a capability, scope it, and have the type system prove it does not escape
A returned value has to declare what it is still holding. "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."
What that buys for an agent is a negative guarantee. "They will not be able to leak my API keys or my email or do other things."
The same mechanism covers memory arenas and access to secrets. The two things that have to be impossible are forgetting a capability you are holding and forging one you were never given
Scala is about halfway there, he said, and the work is released as an experimental feature rather than shipped
Writing for machines to read
If a person is not writing the code, ease of writing stops being a design criterion. "So easy to write is definitely not a big criterion anymore." The syntactic shortcuts that save keystrokes stop earning their place
Ease of reading survives, but only partly. What matters more is the ability to constrain what a program must not do and specify what it must
On formal verification he gave the optimistic case and then took most of it back
"And I mean some people say 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."
"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 the specification stays in natural language, and the prompt becomes part of the program. "So I really should have the prompts as first-class values in my program"
Today the prompt is discarded or left in a chat history, which he called a shame
The host offered the analogy of a blame annotation that records which prompt produced which code. Odersky's reason for wanting it is incremental change: a small edit should regenerate a small edit, rather than have the model produce a new program nondeterministically and undo review that has already happened
12. Fewer, Better Engineers
Asked whether there will be more or fewer software engineers in ten years, he answered without hedging. "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 need to know quite a lot of logic and math to be competent at essentially keeping AI on the right track and things like that."
His comparison is the control engineer in a factory, who has to be more skilled than a factory worker of fifty years ago because the job is now supervising a process rather than performing it. "And I think the same will happen for software, where you will need fewer but more qualified people."
13. Learn C First, Then Rust
The first recommendation is a systems language, for the hardware rather than the job. "So definitely a systems language. I think to know how hardware works and how software links with hardware, I would learn a systems language."
He was torn between C and Rust. C is simple and close to the metal; Rust asks a learner to absorb a lot of abstractions but is memory safe
His sequence is C first, to see what the machine is actually doing, and a switch to Rust if systems programming becomes the career
The second recommendation is a proof language nobody would ship, and the reason is intuition rather than employment. A course in Lean or Rocq, because most people have only a fuzzy sense of what it means for a program to be correct
"And learning one of these languages would sharpen the mind."
Scala he put third, as the language that sits in the middle: provable, strongly typed, expressive
14. Academia Pays 10x Less
He put a number on what the career cost. "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"
The thing he bought with it is a research agenda nobody can cancel. "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."
The cost is fundraising, grant applications and persuading students that the work is worth their time, which he said is hard and also the most rewarding part
The risk he was pricing was relevance rather than pay. "But then times also change, and sometimes essentially what you do is no longer relevant, and then it's very easy to get fired."
The choice was made at the end of his studies, when he picked a research project with no known answer. "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."
15. Scala's Clash of Cultures
The technical experiment worked and the ecosystem was the hard part. "And technically that experiment was a big success. In terms of the ecosystem, it had a lot of challenges."
He cited James Iry's satirical history of programming languages, whose entry on Scala jokes that he put object-oriented and functional programming together and both communities turned on him. "And at the beginning, it was very funny. But in retrospect, that's to a large degree what happened."
In hindsight he would have introduced the functional features more slowly. Scala shipped nearly complete, so most Haskell programs port straight over, and that imported a second engineering culture wholesale
His counterexample is Go, which was mocked for shipping without generics. Because the culture formed inside the constraint, adding generics later broke very little
The libraries set the norm, and the ones that came from the Haskell side ask for a whole program to be expressed as a monad — an approach he said he has reservations about and would not use in his own code
"I think that the libraries are important because they sort of set the agenda, how you express your programs."
"So essentially having fancy abstractions is great, but you have to use them responsibly."
"And people did reach abstraction peaks and over-abstract it and things like that, and they still do it to this very day."
The version of this that happens in a company is not about conference speakers, he said. It is a team lead who arrives from Haskell and writes everything that way, and a project cancelled two years later by that person's own manager because nobody can read the code
He was careful to say most of the community is level-headed and most of the published advice is good, and that there are plenty of successful projects
The design regret he named is inherited from the JVM. Java defines universal methods such as toString, equals and hashCode on everything, and Scala took that notion of an object because interoperation required it
Rust and Haskell use type classes instead, declaring at compile time exactly where equality and hashing exist. More tedious to set up, and safer
On why any of it worked, he credits timing: Scala sat between dynamic languages that were slow and crashed and statically typed languages that were cumbersome and full of ceremony, and inferred types let it feel like the former while behaving like the latter
"So no, I think it was quite by surprise that this actually happened."
"And we've been copied a lot by a lot of other languages that put in these features then five or ten years later or things like that."
Bonus Insights
The book he recommends is Structure and Interpretation of Computer Programs, an MIT introductory text he dates to the 1980s or 1990s. His Coursera courses and his teaching at EPFL are based on that material to some degree, in a different language and with static types rather than dynamic ones
His advice to his younger self is to take more technical risk, not less. "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 yeah, so basically be a bit nonconformist."
The scale it started at is worth holding next to the Twitter story: about five users outside his own group, and no expectation that it would go further
Odersky's bottom line is that AI does not retire the type system, it promotes it: once nobody is reading the code line by line, the type is the only contract left that a person can check and a model can be held to.
Products, Companies & Tools Mentioned
Scala (His own language, pitched as the only functional language that is also a capable object-oriented one; now also compiles to native code, JavaScript and WebAssembly)
Rust (Memory safe and, he says, overused above the systems layer where a garbage collector would do)
Go (Deliberately small, built to 1990s standards, and better for it once generics arrived)
Zig (Its compile-time inlining is cleaner than Rust's macros, but does not guarantee the inlined program still type-checks)
Python (The best of the dynamically typed languages on his account, and 100 times more popular than the alternative he rates)
Haskell and OCaml (The two functional languages Scala took most from — the standard library from one, the module system from the other)
Java and the JVM (The platform Scala was built on, and the source of the design decision he most regrets)
Twitter (Ruby-based and unreliable at 25 people, it adopted Scala and made the language respectable)
Ruby (What Twitter ran on before, and the kind of dynamic language most early Scala adopters came from)
C# (Built by Microsoft after it clashed with Sun over Java's naming rule — Java with more thrown in, on his description)
Oracle (Acquired Sun, after which he says the licensing trouble started)
Lean and Rocq (Proof languages he recommends learning to develop an intuition for program correctness)
LLVM (What Scala Native compiles through to reach machine code)
pandas and NumPy (His examples of the high-performance C libraries that make Python a glue language)
EPFL and Coursera (Where he teaches, and where the course based on his recommended book runs)
Books & Resources Mentioned
Structure and Interpretation of Computer Programs (The book he got the most out of, and the basis for his own courses)
A Brief, Incomplete, and Mostly Wrong History of Programming Languages – James Iry (The satire whose Scala entry, he says, turned out to describe what actually happened to the community)
The capability research the host links from the episode notes (The work on strengthening static guarantees so a language can fence in what a model is allowed to do)
If this was worth your time, send it to someone closer to the industry than you are.
Get the latest market chatter as it happens: