Tim Sweeney
speaker
640 appearances
1 recordings
1 series
first heard Apr 2025
last heard Apr 2025
Tim Sweeney’s voice in public audio — every appearance, attributed to the second.
Trend
recordings per month · last 12 monthsNo recordings in the last 12 months.Older appearances are listed below; set an alert to hear about the next one.
Appearances
When you write a function in a programming language, you're saying, if you give me this thing, I will give you that thing. If you give me a parameter of type something, then I'll give you a result of some other type. And by writing that function, you're proving that given one of these things, you can produce another thing, and that's a proof of an implication.
With only like seven laws, you can construct a... all of mathematical logic in a type system. And one of the important things for programming languages that hasn't been given enough attention is some aspects of programming languages are just subjective. They're just machinations of the programming language designer. Guido van Rossum decided that Python should support indentation a certain way.
And, you know, as long as you're dealing with things like human notation and naming of things, there's always going to be that subjective layer. But there are other parts of programming languages that are not subjective but should be fundamental. And when you look at type systems, there is a way to do type systems that gives you mathematical proofs.
And every other way of type systems that doesn't give you mathematical proofs is just worse and should ultimately be rejected. Like, what have we actually done right in the past and what have we done wrong? And for everything we've done wrong, actually going back and fixing it. Otherwise, we just keep accumulating so much cruft that our systems eventually are crushed under their own complexity.
And, you know, there have been massive announcements of horrible vulnerabilities in software and services over the past year. It turns out, like, some nation-state backdoored a bunch of Teleco's surveillance systems for wiretaps. Like, huge problem there. But, you know, ultimately when you break it down, it's probably because of some buffer overrun and some C program.
These decisions about programming languages have long-term implications.
This is the one biggest technical problem that we're working to solve in this generation. And that is... taming concurrency so that any ordinary programmer can achieve it by just writing ordinary code. It's hard. Programming on a single-threaded computer is hard enough, but it is completely predictable.
If you have a language that's deterministic and you run the same code over and over, it's always going to do exactly the same thing, and there's no unpredictability about what might happen. You're reading and writing variables in some order, and you're always going to see it behave the same.
The problem is when you introduce multiple threads or multiple nodes in a data center all working together on a single problem, is that they each want to read and write different pieces of data and change the state of the world as they go. And still, almost all concurrency in real-world programs today is achieved manually.
Programmers are writing this code that might run in multiple threads very, very carefully so that they are negotiating among each thread to get access to data in a way that's going to give them predictable results. And it's incredibly hard. It's so hard that we've...
In five generations of Unreal Engine, every single generation decided we're not going to try to scale up all of our gameplay code to multiple threads manually. It's just much, much, much too likely to go wrong, not only for ourselves, but for every partner company who licenses Unreal Engine and tries to use it for building a game. It's just a massive foot gun.
There's a variety of solutions to concurrency that are all rather suboptimal. One attempted solution was like, just don't try to solve this problem at all. Let's break our program down into microservices. And almost all online websites of massive scale, like amazons.com, work with hundreds of microservices where different servers negotiate with each other by sending messages to each other.
And by programmers writing those things very carefully, they eventually get to being able to take your orders and not make a mess of them reliably. But this is totally not scalable to the metaverse where you have millions of programmers who are mostly not going to be computer scientists. They're mostly going to be hobbyists and enthusiasts and first-time programmers doing stuff for fun.
That's never going to work for them because they'll never be able to envision all the different dependencies between different computations that are running in parallel. But it turns out that there was an amazing foundational work done in the 1980s that was made very real by a paper on Haskell concurrency. Composable Memory Transactions is the name of the paper.
And it described the system for transactional updates to programs. And the idea of a transaction is... A transaction is a block of code that does a bunch of operations on memory. It might read, it might write, it might process an order, it might accept an order or reject an order. It might transfer money between one bank account and another.
It might make conditional decisions like, oh, you asked to transfer $100 from your account to this guy's account. We're going to see if you have $100. If you don't, we're going to reject it. If you have $100, we're going to take $100 out of your account and add it to this other guy's account.
Without transactions, if everybody's just randomly adding and subtracting each other's bank balances, then you might have somebody read a bank balance, subtract 100, and write it out. But in the meantime, somebody has written something else in the meantime. And so you might get inconsistent bank balances arising if you don't have a way of ensuring that these all run in a specific order.
So the idea of transactions is it's a way of dividing an entire program into updates individually. self-contained updates that do an arbitrary amount of computation but must run in a single-threaded manner. And in the case of a game engine, that's a gameplay object update. When you're playing Fortnite, you see a gameplay object. Every other player is a gameplay object.
Every enemy is a gameplay object. Every rocket and projectile and car and thing you see moving around and interacting, it's not just a fixed static part of the world. That's a separate game object. And each of those objects is updated at a rate of one update per frame at 60 frames per second.
And so then in the course of Fortnite Battle Royale gameplay, you have tens of thousands of object updates happening every frame with 100 players. In a simulation with billions of players, you'd have a whole lot more than that. So right now that's done single-threaded. Yeah, that's done single-threadedly in each game session. This is why Fortnite is 100 players limitation.
Showing 461–480 of 640 · page 24 of 32
← Previous
Next →