Sergey Levine (top humanoid robotics researcher, @svlevine) on the best quality data for the models:
Me: I want to hear your take on what's the best data to get, what's the worst, and what are the pros and cons?
Sergey: "My own take on this is that a lot of different data the model to internalize if it can ground them in a thorough physical understanding of the world.
So where I'm going with this is that if we have a robotic foundation model that is trained on lots of real embodied data that provides that grounding, it might actually be much better able to absorb other sources of knowledge.
This is a little bit upside down relative to how some people think about it, because it's very tempting, looking at the success of internet data for LLMs, to say maybe we should do the opposite: start with YouTube videos and then put robot data on top of that. But I think it's actually the other way around, and I even have a little bit of evidence for this.
My colleague Suraj Nair, together with Simar from Georgia Tech, had a project where they took our robot foundation model and added human video data. But they didn't start with human video data. They started with a model trained on robot data and then added video data on top of it. And they looked at the representations inside the model: how does the model represent human experience versus robot experience?
They found that if you use a small model with a small amount of robot data, predictably, the human experience and the robot experience are fully separated. But if you train on lots of robot data from lots of different robots, then the features are grouped much more by what task is being done rather than by whether it's a human or a robot.
When we looked at the feature plots, it was just mind-boggling, because when you crank up the amount of robot data to 100%, they just line up perfectly. It's all task identity and minimal sensitivity to embodiment.
To me, that's kind of mind-blowing, because the base model wasn't trained on any human data at all. But once you start adding human data, it represents it exactly the same way.
To me, that is one of the strongest indicators that if you have that good foundation of robot experience, you can put everything else on top of it, and it's actually better at absorbing that."
Me: I want to hear your take on what's the best data to get, what's the worst, and what are the pros and cons?
Sergey: "My own take on this is that a lot of different data the model to internalize if it can ground them in a thorough physical understanding of the world.
So where I'm going with this is that if we have a robotic foundation model that is trained on lots of real embodied data that provides that grounding, it might actually be much better able to absorb other sources of knowledge.
This is a little bit upside down relative to how some people think about it, because it's very tempting, looking at the success of internet data for LLMs, to say maybe we should do the opposite: start with YouTube videos and then put robot data on top of that. But I think it's actually the other way around, and I even have a little bit of evidence for this.
My colleague Suraj Nair, together with Simar from Georgia Tech, had a project where they took our robot foundation model and added human video data. But they didn't start with human video data. They started with a model trained on robot data and then added video data on top of it. And they looked at the representations inside the model: how does the model represent human experience versus robot experience?
They found that if you use a small model with a small amount of robot data, predictably, the human experience and the robot experience are fully separated. But if you train on lots of robot data from lots of different robots, then the features are grouped much more by what task is being done rather than by whether it's a human or a robot.
When we looked at the feature plots, it was just mind-boggling, because when you crank up the amount of robot data to 100%, they just line up perfectly. It's all task identity and minimal sensitivity to embodiment.
To me, that's kind of mind-blowing, because the base model wasn't trained on any human data at all. But once you start adding human data, it represents it exactly the same way.
To me, that is one of the strongest indicators that if you have that good foundation of robot experience, you can put everything else on top of it, and it's actually better at absorbing that."
Sergey Levine (@svlevine) is one of the world's top robotics researchers and co-founder of Physical Intelligence.
We talked about where humanoid robotics is today, thoughts on the Chinese robotics ecosystem, and his predictions for future timelines.
In this episode:
• cs and surprising capabilities so far
• Chinese robotics compared to US ecosystem
• If OpenAI and Anthropic got into robotics
• His top robotics research paper recommendation
• Predictions for when humanoid robotics will land
Where to watch:
• YouTube - youtu.be/9OSbaPjv0Rc
• Spotify - open.spotify.com/episode/19amTr…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/sergey-levin…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:37 Where are we today
04:20 Most surprising capabilities so far
07:03 The most inspiring real world robotics
08:36 If OpenAI or Anthropic got into robotics
10:22 Chinese robotics
13:15 Will one lab breakout from the rest
16:59 Thoughts on a concrete roadmap
21:03 Generalization and demonstrating it
26:04 Types of data and which is best for robotics
34:34 Why humanoid robotics differs from Waymo
37:10 If humanoid robotics failed here is why
39:55 Are there hot take modeling architectures in robotics
42:05 Thoughts on AI safety in robotics
46:44 Top robotics research paper recommendation
49:35 Why is Boston Dynamics less top of mind
53:47 Advice for his younger self
56:42 Outro
0
0
3
This interview is with Paul Mockapetris, the creator of the internet's Domain Name System (DNS). I talked to him about the story behind building it and certain design choices he made.
In this episode:
• Computing and the internet before DNS existed
• Why URLs use reversed Migrating the internet to DNS
• Advice for his younger self
Where to watch:
• YouTube - youtube.com/watch?v=LT4iVe…
• Spotify - open.spotify.com/episode/61TliC…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/e071-paul-mo…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:40 What computing was like before DNS
09:02 Why URLs are inverted
16:33 How DNS works
20:27 How he migrated the internet to DNS
25:17 Why do companies host DNS servers
33:17 What is an RFC
35:07 How he got into computing
46:39 Advice for his younger self
52:56 Outro
In this episode:
• Computing and the internet before DNS existed
• Why URLs use reversed Migrating the internet to DNS
• Advice for his younger self
Where to watch:
• YouTube - youtube.com/watch?v=LT4iVe…
• Spotify - open.spotify.com/episode/61TliC…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/e071-paul-mo…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:40 What computing was like before DNS
09:02 Why URLs are inverted
16:33 How DNS works
20:27 How he migrated the internet to DNS
25:17 Why do companies host DNS servers
33:17 What is an RFC
35:07 How he got into computing
46:39 Advice for his younger self
52:56 Outro
1
3
17
Anders Hejlsberg (creator of TypeScript and C#, @ahejlsberg) on two reasons they used Go, not Rust:
Me: If you think about Rust, what didn't it have that, if it had it, you would have picked it?
Anders: I think there are two things. It doesn't have garbage collection. It's done through the borrow checker. But the borrow checker doesn't allow circular data structures, and our compiler is chock-full of circular data structures.
We have trees with parent pointers. We have types that are recursive. We have symbols that refer. It's everywhere.
And like I said, if we had chosen to rewrite, we could have probably solved all of that. But it wouldn't have been just porting the code. It would also have been solving a whole bunch of new problems that we had bought ourselves by going that route. We tried, and it just wasn't feasible.
So we were just trying to optimize for doing as little work as possible to get us to the payout. And honestly, Rust is no better when it comes to the quality of the generated code or the concurrency gains that we could have gotten out of it.
Go is just great. We got all the bennies for less work by going that route.
Me: If you think about Rust, what didn't it have that, if it had it, you would have picked it?
Anders: I think there are two things. It doesn't have garbage collection. It's done through the borrow checker. But the borrow checker doesn't allow circular data structures, and our compiler is chock-full of circular data structures.
We have trees with parent pointers. We have types that are recursive. We have symbols that refer. It's everywhere.
And like I said, if we had chosen to rewrite, we could have probably solved all of that. But it wouldn't have been just porting the code. It would also have been solving a whole bunch of new problems that we had bought ourselves by going that route. We tried, and it just wasn't feasible.
So we were just trying to optimize for doing as little work as possible to get us to the payout. And honestly, Rust is no better when it comes to the quality of the generated code or the concurrency gains that we could have gotten out of it.
Go is just great. We got all the bennies for less work by going that route.
Anders Hejlsberg ( @ahejlsberg ) is the creator of TypeScript and C#, and I asked him about how the TypeScript compiler got 10x faster through a rewrite in Go and his thoughts on how AI has impacted software engineering.
In this episode:
• How rewriting the compiler makes it picked Go instead of Rust
• Why they didn't use LLMs for the migration
• Predictions on AI's impact on software engineering
Where to watch:
• YouTube - youtube.com/watch?v=cywK3X…
• Spotify - open.spotify.com/episode/1thvWd…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-t…
Thank you to the sponsors of this episode 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 workos.com
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
Chapters:
00:00 Intro
00:48 Why write a compiler in JavaScript
07:29 Why rewrite the compiler in Go
14:49 LLMs for large migrations
20:12 Why Javascript is so popular
26:32 Why ever use Javascript on the backend
32:59 What it takes to build a programming language
37:06 Will there be fewer languages in 10 years
42:57 Hands on engineering vs delegation
49:14 Why fast tooling matters more now
51:16 AI software engineering predictions
58:52 The most technically challenging work
01:02:04 Top book recommendation
01:03:50 Advice for his younger self
01:05:00 Outro
25
54
532
Martin Odersky (creator of Scala, @odersky) on why types will become the contract between humans and AI-written code:
I think right now we're sort of in an existential crisis. We have AI generating the code, but humans being asked impossible tasks, like to review all these h 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 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. Definitely not only programming languages, that's no silver bullet, but they definitely can help.
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. I expect types will become a lot stronger and more precise than what we had, because types are the handle that we can make a contract between the human and the AI, that the human can understand, that's concise enough to be reviewed, and that 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. There are no guarantees, because you can always have a cast, or use some dirty memory. There are a lot of techniques to undermine the type systems.
I think right now we're sort of in an existential crisis. We have AI generating the code, but humans being asked impossible tasks, like to review all these h 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 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. Definitely not only programming languages, that's no silver bullet, but they definitely can help.
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. I expect types will become a lot stronger and more precise than what we had, because types are the handle that we can make a contract between the human and the AI, that the human can understand, that's concise enough to be reviewed, and that 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. There are no guarantees, because you can always have a cast, or use some dirty memory. There are a lot of techniques to undermine the type systems.
Martin Odersky (@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.
In this episode:
• Comparing Rust, Zig, Python, and Scala designs
• Why its hard to ictions about how AI will impact software
• Why functional programming matters
Where to watch:
• YouTube - youtu.be/LdN4sPWM-WY
• Spotify - open.spotify.com/episode/0EHxXl…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-s…
Thank you to the sponsors of this episode 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 workos.com
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
Chapters:
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
3
2
15
Such a great idea to have agents take a first stab
Not only for time savings but latency of resolution for straightforward issues
Also cool to see how so few people could build so much, wild times we live in
Not only for time savings but latency of resolution for straightforward issues
Also cool to see how so few people could build so much, wild times we live in
New on our Engineering blog: Creating in-house source control.
In May, we merged around 2,500 code changes per day. In September, we merged more than 30,000 per day. As a result, we became bottlenecked by developer infrastructure built for human (rather than agent) scale.
Here, we share how we built a new version control system—and fully migrated our monorepo from git—in five months: anthropic.com/engineering/re…
1
0
6
The singularity has already begun for math:
Scott Aaronson is one of the world's leading quantum computing researchers and spent two years at OpenAI working on AI safety.
We talked about why he thinks the singularity has already begun for math, who gets credit when AI writes intelligence will still matter once machines do the thinking.
In this episode:
• Why the singularity has already begun for math
• Who gets credit when AI writes the proof
• What a proof that P = NP would be worth
• Why he turned down getting rich to keep blogging
• Whether intelligence will still matter
Where to watch:
• YouTube - youtube.com/watch?v=ORlscp…
• Spotify - open.spotify.com/episode/0qnYcS…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/e070-scott-a…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:34 Why he updated so hard on AI
01:14 The people still denying AI progress
03:53 The singularity has already begun for math
08:30 Will human-driven math research survive
13:12 Who gets credit for AI-written papers
15:55 OpenAI's $15M Navier-Stokes proof
19:20 What if AI proved P = NP
23:07 Why AI is so good at finding counterexamples
26:13 The goalposts keep moving
28:52 Why AI disclosure matters in research
32:59 The fake Monet experiment
35:23 Why he blogs instead of getting rich
39:45 Are AI labs racing too fast
42:01 Will intelligence still matter
47:12 Book recommendations
52:27 Advice for students today
57:23 Reacting live to a new AI result
59:58 Outro
Scott Aaronson is one of the world's leading quantum computing researchers and spent two years at OpenAI working on AI safety.
We talked about why he thinks the singularity has already begun for math, who gets credit when AI writes intelligence will still matter once machines do the thinking.
In this episode:
• Why the singularity has already begun for math
• Who gets credit when AI writes the proof
• What a proof that P = NP would be worth
• Why he turned down getting rich to keep blogging
• Whether intelligence will still matter
Where to watch:
• YouTube - youtube.com/watch?v=ORlscp…
• Spotify - open.spotify.com/episode/0qnYcS…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/e070-scott-a…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:34 Why he updated so hard on AI
01:14 The people still denying AI progress
03:53 The singularity has already begun for math
08:30 Will human-driven math research survive
13:12 Who gets credit for AI-written papers
15:55 OpenAI's $15M Navier-Stokes proof
19:20 What if AI proved P = NP
23:07 Why AI is so good at finding counterexamples
26:13 The goalposts keep moving
28:52 Why AI disclosure matters in research
32:59 The fake Monet experiment
35:23 Why he blogs instead of getting rich
39:45 Are AI labs racing too fast
42:01 Will intelligence still matter
47:12 Book recommendations
52:27 Advice for students today
57:23 Reacting live to a new AI result
59:58 Outro
26
141
733
Ethan Evans (ex-Amazon VP, @EthanEvansVP) on getting caught empire building by Jeff Bezos:
Me: Because you had so much success as a VP, did you do empire building?
Ethan: "The human mind is great at rationalizing. I think in hindsight, I for sure did some empire building. But ly don't tell yourself you're empire building.
What you tell yourself is, with all these people, I could do so much more, right? You frame it as, man, I have all these great ideas. We've got a big backlog. If only I had 375 more people, imagine what we could do.
And it's not your budget. So why not ask for it? So I got totally burned on this.
When we were growing Amazon Appstore, we had launched the store and we had our annual meeting with Bezos. We took him this huge ask for all these people.
I think we had nobody in marketing. We had no dedicated marketers because we had started this lean team. It was something absurd like we need 25 marketing people. And, this is not exactly right, but it's like we need 5 PR people. We had this idea: we're operating in 5 countries, we need 1 PR person per country.
Well, Jeff tore into us. He asked a couple questions like, what are these people going to do? What are they actually going to do? And our answers fell apart.
He asked one question, we gave a crappy answer, and you could tell he's like, hmm. A second later he asked another question, and we gave another crappy answer. And he's like, 'Okay, I don't believe any of your numbers from here on. I've asked you two questions. They were both nonsense.
Go back and bring me a sheet where the maximum size of any bucket of anything you're asking for is two or three people, and it says exactly what they're going to do. And I will go through that line by line and tell you what you can have.'
And that's what he did. He just literally, with a red pen, with all of his direct leaders watching: no, 3, none, 2, okay... and just took us over the coals.
He wasn't wrong. He was actually right. I was relatively newer. One of my managers was newer. We had gotten big eyes because we'd launched the project and thought, well, let's see what we can do with this. It's a good project. Let's see what they want to do. And what we found out was not very much. They wanted us to be lean."
Me: Because you had so much success as a VP, did you do empire building?
Ethan: "The human mind is great at rationalizing. I think in hindsight, I for sure did some empire building. But ly don't tell yourself you're empire building.
What you tell yourself is, with all these people, I could do so much more, right? You frame it as, man, I have all these great ideas. We've got a big backlog. If only I had 375 more people, imagine what we could do.
And it's not your budget. So why not ask for it? So I got totally burned on this.
When we were growing Amazon Appstore, we had launched the store and we had our annual meeting with Bezos. We took him this huge ask for all these people.
I think we had nobody in marketing. We had no dedicated marketers because we had started this lean team. It was something absurd like we need 25 marketing people. And, this is not exactly right, but it's like we need 5 PR people. We had this idea: we're operating in 5 countries, we need 1 PR person per country.
Well, Jeff tore into us. He asked a couple questions like, what are these people going to do? What are they actually going to do? And our answers fell apart.
He asked one question, we gave a crappy answer, and you could tell he's like, hmm. A second later he asked another question, and we gave another crappy answer. And he's like, 'Okay, I don't believe any of your numbers from here on. I've asked you two questions. They were both nonsense.
Go back and bring me a sheet where the maximum size of any bucket of anything you're asking for is two or three people, and it says exactly what they're going to do. And I will go through that line by line and tell you what you can have.'
And that's what he did. He just literally, with a red pen, with all of his direct leaders watching: no, 3, none, 2, okay... and just took us over the coals.
He wasn't wrong. He was actually right. I was relatively newer. One of my managers was newer. We had gotten big eyes because we'd launched the project and thought, well, let's see what we can do with this. It's a good project. Let's see what they want to do. And what we found out was not very much. They wanted us to be lean."
I don't think you'll find another conversation like this on the internet
I asked Ethan Evans (ex-Amazon VP) questions about common situations in corporate politics but they get increasingly darker
In this episode:
• How he got burned by Bezos for empire building
• How to be tions
• How to reject work that isn't impactful
• Unusual firing stories with HR (e.g. human poop)
• How to handle bad managers and political peers
• Top book recommendation for power dynamics
And much more, this episode was my longest conversation so far
Where to watch:
• YouTube - youtube.com/watch?v=KhjhRR…
• Spotify - open.spotify.com/episode/12o4mz…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/e068-ethan-e…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:42 How to receive credit for your work
19:18 Ways for quiet people to get visibility
21:32 How to be trusted for top projects
29:52 How to defend from others taking your project
36:13 How to reject bad projects
44:10 How to be first for promo
55:35 How to handle managers that dislike career growth talk
01:06:30 What if your manager is in the way
01:15:43 Did he ever have overly political reports
01:28:06 How to fire a bad manager
01:35:16 What gives you leverage
01:43:41 How to defend against peers undermining you
01:50:24 What if everyone is good at politics
01:55:11 How Jeff Bezos burned him for empire building
02:03:27 How to retain your headcount
02:07:31 Career recommendations for the current landscape
02:15:11 How to avoid negative layoff optics
02:18:39 How to develop executive presence
02:29:25 How to network in a natural way
02:33:30 How to network with powerful people
02:41:01 How to learn hidden incentives
02:44:43 What happens behind the scenes with HR
02:50:13 Did he burn people to get ahead
02:53:24 What he says to people who hate politics
02:59:03 Top book recommendations on power dynamics
03:00:45 How he would speedrun career growth today
03:06:56 Outro
0
0
29
Neetcode (@neetcode1) is the most well-known coding interview prep creator with over 1M+ subs on YouTube. I interviewed him about the latest on coding interviews, his career at Amazon vs Google, and what it was like quitting big tech to do his own thing.
In this episode:
• wo months
• Memorizing solutions versus deriving them
• How he started Neetcode
• What he disliked most about Google
Where to watch:
• YouTube - youtu.be/K15dND_Kfvg
• Spotify - open.spotify.com/episode/62cNcU…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - open.substack.com/pub/ryanlpeter…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:33 Quitting Amazon after 2 months
06:00 Testing Neetcode on Leetcode
12:57 Memorizing vs deriving solutions and intelligence
16:13 The story behind Neetcode
22:24 Getting a job at Google
27:47 How it was quitting big tech
29:38 What he hated most about Google
30:52 Top technical book recommendation
32:34 Advice for his younger self
33:46 Outro
In this episode:
• wo months
• Memorizing solutions versus deriving them
• How he started Neetcode
• What he disliked most about Google
Where to watch:
• YouTube - youtu.be/K15dND_Kfvg
• Spotify - open.spotify.com/episode/62cNcU…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - open.substack.com/pub/ryanlpeter…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:33 Quitting Amazon after 2 months
06:00 Testing Neetcode on Leetcode
12:57 Memorizing vs deriving solutions and intelligence
16:13 The story behind Neetcode
22:24 Getting a job at Google
27:47 How it was quitting big tech
29:38 What he hated most about Google
30:52 Top technical book recommendation
32:34 Advice for his younger self
33:46 Outro
4
5
25
My red note (小红书) intro video
Feedback welcome from native speakers
Feedback welcome from native speakers
Native chinese speakers, how is this dub?
Doing a little experimenting here: xhslink.cn/m/6sxYS9ryPbi
17
0
52
I don't think you'll find another conversation like this on the internet
I asked Ethan Evans (ex-Amazon VP) questions about common situations in corporate politics but they get increasingly darker
In this episode:
• How he got burned by Bezos for empire building
• How to be tions
• How to reject work that isn't impactful
• Unusual firing stories with HR (e.g. human poop)
• How to handle bad managers and political peers
• Top book recommendation for power dynamics
And much more, this episode was my longest conversation so far
Where to watch:
• YouTube - youtube.com/watch?v=KhjhRR…
• Spotify - open.spotify.com/episode/12o4mz…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/e068-ethan-e…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:42 How to receive credit for your work
19:18 Ways for quiet people to get visibility
21:32 How to be trusted for top projects
29:52 How to defend from others taking your project
36:13 How to reject bad projects
44:10 How to be first for promo
55:35 How to handle managers that dislike career growth talk
01:06:30 What if your manager is in the way
01:15:43 Did he ever have overly political reports
01:28:06 How to fire a bad manager
01:35:16 What gives you leverage
01:43:41 How to defend against peers undermining you
01:50:24 What if everyone is good at politics
01:55:11 How Jeff Bezos burned him for empire building
02:03:27 How to retain your headcount
02:07:31 Career recommendations for the current landscape
02:15:11 How to avoid negative layoff optics
02:18:39 How to develop executive presence
02:29:25 How to network in a natural way
02:33:30 How to network with powerful people
02:41:01 How to learn hidden incentives
02:44:43 What happens behind the scenes with HR
02:50:13 Did he burn people to get ahead
02:53:24 What he says to people who hate politics
02:59:03 Top book recommendations on power dynamics
03:00:45 How he would speedrun career growth today
03:06:56 Outro
I asked Ethan Evans (ex-Amazon VP) questions about common situations in corporate politics but they get increasingly darker
In this episode:
• How he got burned by Bezos for empire building
• How to be tions
• How to reject work that isn't impactful
• Unusual firing stories with HR (e.g. human poop)
• How to handle bad managers and political peers
• Top book recommendation for power dynamics
And much more, this episode was my longest conversation so far
Where to watch:
• YouTube - youtube.com/watch?v=KhjhRR…
• Spotify - open.spotify.com/episode/12o4mz…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/e068-ethan-e…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:42 How to receive credit for your work
19:18 Ways for quiet people to get visibility
21:32 How to be trusted for top projects
29:52 How to defend from others taking your project
36:13 How to reject bad projects
44:10 How to be first for promo
55:35 How to handle managers that dislike career growth talk
01:06:30 What if your manager is in the way
01:15:43 Did he ever have overly political reports
01:28:06 How to fire a bad manager
01:35:16 What gives you leverage
01:43:41 How to defend against peers undermining you
01:50:24 What if everyone is good at politics
01:55:11 How Jeff Bezos burned him for empire building
02:03:27 How to retain your headcount
02:07:31 Career recommendations for the current landscape
02:15:11 How to avoid negative layoff optics
02:18:39 How to develop executive presence
02:29:25 How to network in a natural way
02:33:30 How to network with powerful people
02:41:01 How to learn hidden incentives
02:44:43 What happens behind the scenes with HR
02:50:13 Did he burn people to get ahead
02:53:24 What he says to people who hate politics
02:59:03 Top book recommendations on power dynamics
03:00:45 How he would speedrun career growth today
03:06:56 Outro
5
21
309
Questions on corporate politics but they get increasingly darker: new interview with Ethan Evans (Ex-Amazon VP) dropping tomorrow
0
1
16
3rd interview with Ethan Evans (@EthanEvansVP) dropping Monday 9/28
12
5
203
His biggest career regret is only going to become more common for software engineers now.
“I wasn’t as inquisitive as I could have been about what the actual underlying particularly technical cause was.”
“You need to understand how things work.”
“You’re inquisitive about why I think that this is just a much more sustainable foundation.”
@hievanking
“I wasn’t as inquisitive as I could have been about what the actual underlying particularly technical cause was.”
“You need to understand how things work.”
“You’re inquisitive about why I think that this is just a much more sustainable foundation.”
@hievanking
0
1
63
@stigopython That’s what I was thinking, I will keep testing though
I did do a side by side and so far the dub performed much better but still need to collect more data points
I did do a side by side and so far the dub performed much better but still need to collect more data points
0
0
0
@LeeTzui I’ll keep experimenting but it seems like the dub performed much better (left one in pic) from my early testing
0
0
1
Native chinese speakers, how is this dub?
Doing a little experimenting here: xhslink.cn/m/6sxYS9ryPbi
Doing a little experimenting here: xhslink.cn/m/6sxYS9ryPbi
7
1
26
The m5 studio upgrade has arrived!!
Had Codex chop up the footage into an ASMR unboxing video in one shot
Had Codex chop up the footage into an ASMR unboxing video in one shot
Bought the 256GB mac mini m5 for $499 when I quit my job at Meta to be frugal. It was honestly a great machine with just a few limitations
Feeling lucky that I can upgrade my tools now that the podcast has some sponsors 🙏
1
1
19
Philip Su grew quickly to a Distinguished Engineer at Facebook and OpenAI. We talked about the psychology behind peaking in a tech career and the pressure at the highest levels.
In this episode:
• Not wanting IC9 and requesting demotion
• How motivation changed across his and motivation after FIRE
• Why sustaining IC9 was difficult
Where to watch:
• YouTube - youtube.com/watch?v=RMo04p…
• Spotify - open.spotify.com/episode/3UfHNC…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/openai-and-m…
Thank you to the sponsors of this episode 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 workos.com
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
Chapters:
00:00 Intro
00:37 Growth past IC9
05:39 Motivation changes over his career
11:36 Asking to not be promoted
17:33 What made it hard to sustain IC9 performance
22:22 What motivated him outside of promos
26:21 Is career advice useless
29:34 Motivation after you've hit FIRE
36:08 Meaning and fulfillment
38:17 Top book recommendation
40:14 What he would change
43:24 Outro
In this episode:
• Not wanting IC9 and requesting demotion
• How motivation changed across his and motivation after FIRE
• Why sustaining IC9 was difficult
Where to watch:
• YouTube - youtube.com/watch?v=RMo04p…
• Spotify - open.spotify.com/episode/3UfHNC…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/openai-and-m…
Thank you to the sponsors of this episode 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 workos.com
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
Chapters:
00:00 Intro
00:37 Growth past IC9
05:39 Motivation changes over his career
11:36 Asking to not be promoted
17:33 What made it hard to sustain IC9 performance
22:22 What motivated him outside of promos
26:21 Is career advice useless
29:34 Motivation after you've hit FIRE
36:08 Meaning and fulfillment
38:17 Top book recommendation
40:14 What he would change
43:24 Outro
5
14
267
My goal was to record a conversation completely free of "AI doomer" takes as a timeline cleanser.
For this episode, I interviewed Casey Muratori (@cmuratori) who is a video game developer and programming creator also known for his talks about the history of computing.
In this findings in computer history
• Where bad code comes from
• The only unbreakable law in software engineering
• His career in the video game industry
• Why you should read technical papers
Where to watch:
• YouTube - youtu.be/jHLbL1Eg4gM
• Spotify - open.spotify.com/episode/4ywz6r…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/casey-murato…
Thank you to the sponsors of this episode for supporting my work:
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
• 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 workos.com
Chapters:
00:00 Intro
01:08 Digging into computer science history
04:08 What shocked him
16:23 Dijkstra was depressed
26:17 The personal side of goto considered harmful
35:09 The anatomy of a 35 year mistake
50:12 Clean code horrible performance
58:33 How to write high performance code
01:01:18 Where bad code comes from
01:06:37 Why design docs before code is a bad idea
01:09:20 The only unbreakable law in software engineering
01:15:57 How he got into programming
01:21:16 Why he didnt work in big tech
01:30:44 Should you work at a startup early on
01:34:52 What video game engineering is like
01:39:57 Why preventing recursion is reasonable
01:43:24 Is vibe coding bad for the industry
01:50:17 Technical reading recommendation
01:54:27 Advice for his younger self
01:56:54 Outro
For this episode, I interviewed Casey Muratori (@cmuratori) who is a video game developer and programming creator also known for his talks about the history of computing.
In this findings in computer history
• Where bad code comes from
• The only unbreakable law in software engineering
• His career in the video game industry
• Why you should read technical papers
Where to watch:
• YouTube - youtu.be/jHLbL1Eg4gM
• Spotify - open.spotify.com/episode/4ywz6r…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/casey-murato…
Thank you to the sponsors of this episode for supporting my work:
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
• 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 workos.com
Chapters:
00:00 Intro
01:08 Digging into computer science history
04:08 What shocked him
16:23 Dijkstra was depressed
26:17 The personal side of goto considered harmful
35:09 The anatomy of a 35 year mistake
50:12 Clean code horrible performance
58:33 How to write high performance code
01:01:18 Where bad code comes from
01:06:37 Why design docs before code is a bad idea
01:09:20 The only unbreakable law in software engineering
01:15:57 How he got into programming
01:21:16 Why he didnt work in big tech
01:30:44 Should you work at a startup early on
01:34:52 What video game engineering is like
01:39:57 Why preventing recursion is reasonable
01:43:24 Is vibe coding bad for the industry
01:50:17 Technical reading recommendation
01:54:27 Advice for his younger self
01:56:54 Outro
10
24
352
Weekend AI project: Bathroom dashboard
• Weather, UV index today
• Health data from Google Health
• Social media metrics for work
• Calendar events for the day
This was a one shot for GPT6 once I enabled "wireless debugging" on the tablet
• Weather, UV index today
• Health data from Google Health
• Social media metrics for work
• Calendar events for the day
This was a one shot for GPT6 once I enabled "wireless debugging" on the tablet
3
0
18
@trq212 Yep, I did ask Fable to improve the refresh rate performance. All vibe coded so I wasn't in the details but here's the summary of the commit that made the biggest difference:
0
0
8
@kodomari @uirenzhen 個人的には、手が滑るほど強い傾斜ではないと感じています。ただ、好みに合わせて傾斜（チルト）なしで使うことも可能です。その場合はテンティング用のケースを使わなければ大丈夫です。イメージが伝わるように写真を添付しますね。
0
0
2
Used Fable 5.1 to turn my Kindle into a Linux terminal so I could work without blue light at night
251
361
6,373
Should people still learn to code if coding is largely solved?
Thariq Shihipar (Engineer on Anthropic’s Claude Code team): "I think being technical is really important. Knowing how do computers work?
How do languages work? What are the hard things like? All of these things are nt to learn.
Like we talked about earlier. Oh, the only way you can tell you've solved the Riemann Hypothesis or the Jacobian Conjecture is like, if you're a great mathematician. Right?
And in the same way, the only way you can tell if you're, like, built great software is like, if you're a great software engineer. When Boris says coding is solved, it just means we don't get stuck in the same ways that we used to before.
Like, very few people in the entire world could write software, and they were very rare. And even if you got them all together, there were so many other reasons why it wouldn't work. Right?
And now that coding is solved, you can use coding to do all these other things that we've not done before."
For the full conversation, you can search Thariq Shihipar on my YouTube, Spotify or Apple Podcasts (link in bio)
Thariq Shihipar (Engineer on Anthropic’s Claude Code team): "I think being technical is really important. Knowing how do computers work?
How do languages work? What are the hard things like? All of these things are nt to learn.
Like we talked about earlier. Oh, the only way you can tell you've solved the Riemann Hypothesis or the Jacobian Conjecture is like, if you're a great mathematician. Right?
And in the same way, the only way you can tell if you're, like, built great software is like, if you're a great software engineer. When Boris says coding is solved, it just means we don't get stuck in the same ways that we used to before.
Like, very few people in the entire world could write software, and they were very rare. And even if you got them all together, there were so many other reasons why it wouldn't work. Right?
And now that coding is solved, you can use coding to do all these other things that we've not done before."
For the full conversation, you can search Thariq Shihipar on my YouTube, Spotify or Apple Podcasts (link in bio)
Thariq Shihipar (@trq212) is an engineer on Anthropic’s Claude Code team I asked him how Anthropic makes the most out of the models for engineering and how the industry will change soon.
In this episode:
• Internal best practices in leveraging the models
• What percent of ly autonomous
• How Anthropic maintains higher volumes of code
• What has worked in preventing AI-written breakages
Where to watch:
• YouTube - youtu.be/2Kch3tWMnw8
• Spotify - open.spotify.com/episode/5dT5nB…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/how-anthropi…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:29 Onboarding at Anthropic
02:53 Internal capabilities vs external perception
06:16 Model vs Harness
08:55 What percent of Anthropics changes are fully autonomous
14:51 Computer use
17:42 How to make the most out of your compute
20:45 Loop engineering
22:47 Where the industry will go soon
26:02 Which model do Anthropic engineers use
27:38 Is learning a particular model worth it
30:56 Prompting tips for todays models
35:04 How to get the models to do tasteful work
39:00 How much of writing is done by AI at Anthropic
45:36 Code ownership and maintenance at Anthropic
52:04 How Anthropic prevents breakages
55:24 Visibility and sharing your work
58:42 Luck surface area example
01:00:57 Should people still learn to code
01:07:42 Advice for his younger self
01:09:58 Outro
6
6
77
Thariq Shihipar (@trq212) is an engineer on Anthropic’s Claude Code team I asked him how Anthropic makes the most out of the models for engineering and how the industry will change soon.
In this episode:
• Internal best practices in leveraging the models
• What percent of ly autonomous
• How Anthropic maintains higher volumes of code
• What has worked in preventing AI-written breakages
Where to watch:
• YouTube - youtu.be/2Kch3tWMnw8
• Spotify - open.spotify.com/episode/5dT5nB…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/how-anthropi…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:29 Onboarding at Anthropic
02:53 Internal capabilities vs external perception
06:16 Model vs Harness
08:55 What percent of Anthropics changes are fully autonomous
14:51 Computer use
17:42 How to make the most out of your compute
20:45 Loop engineering
22:47 Where the industry will go soon
26:02 Which model do Anthropic engineers use
27:38 Is learning a particular model worth it
30:56 Prompting tips for todays models
35:04 How to get the models to do tasteful work
39:00 How much of writing is done by AI at Anthropic
45:36 Code ownership and maintenance at Anthropic
52:04 How Anthropic prevents breakages
55:24 Visibility and sharing your work
58:42 Luck surface area example
01:00:57 Should people still learn to code
01:07:42 Advice for his younger self
01:09:58 Outro
In this episode:
• Internal best practices in leveraging the models
• What percent of ly autonomous
• How Anthropic maintains higher volumes of code
• What has worked in preventing AI-written breakages
Where to watch:
• YouTube - youtu.be/2Kch3tWMnw8
• Spotify - open.spotify.com/episode/5dT5nB…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/how-anthropi…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:29 Onboarding at Anthropic
02:53 Internal capabilities vs external perception
06:16 Model vs Harness
08:55 What percent of Anthropics changes are fully autonomous
14:51 Computer use
17:42 How to make the most out of your compute
20:45 Loop engineering
22:47 Where the industry will go soon
26:02 Which model do Anthropic engineers use
27:38 Is learning a particular model worth it
30:56 Prompting tips for todays models
35:04 How to get the models to do tasteful work
39:00 How much of writing is done by AI at Anthropic
45:36 Code ownership and maintenance at Anthropic
52:04 How Anthropic prevents breakages
55:24 Visibility and sharing your work
58:42 Luck surface area example
01:00:57 Should people still learn to code
01:07:42 Advice for his younger self
01:09:58 Outro
33
32
473
What happened to Boston Dynamics
Sergey Levine (Top Robotics Researcher): “A lot of what the classic Boston Dynamics results show is very sophisticated hardware, very carefully designed hardware, with a traditional control approach, with very smart controls, engineers setting comparatively less emphasis on the kind of decision making aspect.
And I think that at a particular point in time, that actually made a lot of sense, because if you can't build the physical body, like, it doesn't matter what kind of decision making system is running on it.
But at this point, we're at a stage in the development of these things that the big challenge is how to have the decision making loop that actually works and that reacts intelligently to everything in the environment.
The question is, do you need to take the rest of the environment into account, or are you just dealing with the robot?”
Sergey Levine (Top Robotics Researcher): “A lot of what the classic Boston Dynamics results show is very sophisticated hardware, very carefully designed hardware, with a traditional control approach, with very smart controls, engineers setting comparatively less emphasis on the kind of decision making aspect.
And I think that at a particular point in time, that actually made a lot of sense, because if you can't build the physical body, like, it doesn't matter what kind of decision making system is running on it.
But at this point, we're at a stage in the development of these things that the big challenge is how to have the decision making loop that actually works and that reacts intelligently to everything in the environment.
The question is, do you need to take the rest of the environment into account, or are you just dealing with the robot?”
2
9
97
How the ergo keyboard sounds, I put DJI mics in between to capture
As silent as a laptop keyboard
As silent as a laptop keyboard
5
2
47
Kickstarter milestone: First functional trial production unit arrived! Still lots of testing and polishing before mass production run
Excited for this step towards making the product come to life. Full written update coming soon on read.compose.llc
Excited for this step towards making the product come to life. Full written update coming soon on read.compose.llc
12
2
68
Bought the 256GB mac mini m5 for $499 when I quit my job at Meta to be frugal. It was honestly a great machine with just a few limitations
Feeling lucky that I can upgrade my tools now that the podcast has some sponsors 🙏
Feeling lucky that I can upgrade my tools now that the podcast has some sponsors 🙏
6
0
83
Martin Odersky was highly requested so I had to try, always appreciate hearing who you'd like to have on the show!
Martin Odersky (@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.
In this episode:
• Comparing Rust, Zig, Python, and Scala designs
• Why its hard to ictions about how AI will impact software
• Why functional programming matters
Where to watch:
• YouTube - youtu.be/LdN4sPWM-WY
• Spotify - open.spotify.com/episode/0EHxXl…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-s…
Thank you to the sponsors of this episode 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 workos.com
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
Chapters:
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
4
0
14
Why Rust is overused right now
Martin Odersky (Creator of Scala): "Right now, rust is actually overused because a lot of people push Rust for things higher up in the stack
Where a garbage collector is fine, but essentially you still want to code without. And that is, for me, a g it intellectually just because you can
I don't really think there's a big sense in it.
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? It can be much simpler."
Martin Odersky (Creator of Scala): "Right now, rust is actually overused because a lot of people push Rust for things higher up in the stack
Where a garbage collector is fine, but essentially you still want to code without. And that is, for me, a g it intellectually just because you can
I don't really think there's a big sense in it.
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? It can be much simpler."
Martin Odersky (@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.
In this episode:
• Comparing Rust, Zig, Python, and Scala designs
• Why its hard to ictions about how AI will impact software
• Why functional programming matters
Where to watch:
• YouTube - youtu.be/LdN4sPWM-WY
• Spotify - open.spotify.com/episode/0EHxXl…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-s…
Thank you to the sponsors of this episode 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 workos.com
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
Chapters:
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
65
29
318
Martin Odersky (@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.
In this episode:
• Comparing Rust, Zig, Python, and Scala designs
• Why its hard to ictions about how AI will impact software
• Why functional programming matters
Where to watch:
• YouTube - youtu.be/LdN4sPWM-WY
• Spotify - open.spotify.com/episode/0EHxXl…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-s…
Thank you to the sponsors of this episode 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 workos.com
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
Chapters:
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
In this episode:
• Comparing Rust, Zig, Python, and Scala designs
• Why its hard to ictions about how AI will impact software
• Why functional programming matters
Where to watch:
• YouTube - youtu.be/LdN4sPWM-WY
• Spotify - open.spotify.com/episode/0EHxXl…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-s…
Thank you to the sponsors of this episode 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 workos.com
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
Chapters:
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
11
60
347
Sergey Levine's (@svlevine) top AI robotics paper recommendation for someone who wants to get into the field:
"The original ACT paper or the ALOHA paper.
The idea was that hey, if you set up the right kind of low cost robot setup without really any particularly fancy tricks, t teleoperation data of extremely dexterous tasks that people had previously thought would require like very sophisticated hardware and all sorts of like really expensive stuff and then set up like a fairly straightforward transformer based model and it could actually do a lot of those tasks.
He showed like things like replacing batteries in a remote control. He even got a little like a mannequin foot and he showed that he could put a shoe on it like for like an assistive task.
But like what people found I think so interesting about that paper is just how far you could get with like relatively simple building blocks.
And I think that it's worth for somebody who wants to get into the field to go through that paper and really understand what's going on there."
"The original ACT paper or the ALOHA paper.
The idea was that hey, if you set up the right kind of low cost robot setup without really any particularly fancy tricks, t teleoperation data of extremely dexterous tasks that people had previously thought would require like very sophisticated hardware and all sorts of like really expensive stuff and then set up like a fairly straightforward transformer based model and it could actually do a lot of those tasks.
He showed like things like replacing batteries in a remote control. He even got a little like a mannequin foot and he showed that he could put a shoe on it like for like an assistive task.
But like what people found I think so interesting about that paper is just how far you could get with like relatively simple building blocks.
And I think that it's worth for somebody who wants to get into the field to go through that paper and really understand what's going on there."
1
2
18
How Typescript was originally created
Anders Hejlsberg (Creator of TypeScript, C#): "The way TypeScript came about was actually indirectly, through C, because the Outlook. com team approached the C group and asked whether we would pretty please productize something called Script s this thing that took C and transpiled it into JavaScript so you could run it in a browser. And I'm like, what? Why would you want to do that?
Why don't you just write the Java? Well, because that way we can get great tooling. I'm like, wow, is JavaScript really that busted?
And. And you're saying, like, the. The way you want to fix that problem is by abandoning JavaScript, treating it as an instruction language.
Right? And then having a code generator targeted. I'm like, couldn't we, like, fix JavaScript?
Wouldn't that be better? Do you know what I mean?"
For the full conversation, you can search the Anders Hejlsberg's name on my YouTube, Spotify or Apple Podcasts (link in bio)
Anders Hejlsberg (Creator of TypeScript, C#): "The way TypeScript came about was actually indirectly, through C, because the Outlook. com team approached the C group and asked whether we would pretty please productize something called Script s this thing that took C and transpiled it into JavaScript so you could run it in a browser. And I'm like, what? Why would you want to do that?
Why don't you just write the Java? Well, because that way we can get great tooling. I'm like, wow, is JavaScript really that busted?
And. And you're saying, like, the. The way you want to fix that problem is by abandoning JavaScript, treating it as an instruction language.
Right? And then having a code generator targeted. I'm like, couldn't we, like, fix JavaScript?
Wouldn't that be better? Do you know what I mean?"
For the full conversation, you can search the Anders Hejlsberg's name on my YouTube, Spotify or Apple Podcasts (link in bio)
0
1
29
Will AI replace junior software engineers?
Anders Hejlsberg (Creator of TypeScript, C#): "Well, if it does, then how do we ever get senior software engineers? I don't think so.
Not unless you also believe that you will be able to do your business three years later than that ware engineer.
But to me, I think maybe one thing that to some extent has happened is that for certain classes of programmers, the pyramid has narrowed at the bottom.
There are fewer people coming in, and we are wanting them to advance higher up faster so that they can get to this more supervisory role.
I think the craft of being a software engineer is definitely changing from you're typing in lines of code to you're having agents type in lines of code, and you are reviewing the work of the agents. But it is but a tool, and there are still programmers involved in the process.
That I firmly believe."
For the full conversation, you can search Anders' name on my YouTube, Spotify or Apple Podcasts (link in bio)
Anders Hejlsberg (Creator of TypeScript, C#): "Well, if it does, then how do we ever get senior software engineers? I don't think so.
Not unless you also believe that you will be able to do your business three years later than that ware engineer.
But to me, I think maybe one thing that to some extent has happened is that for certain classes of programmers, the pyramid has narrowed at the bottom.
There are fewer people coming in, and we are wanting them to advance higher up faster so that they can get to this more supervisory role.
I think the craft of being a software engineer is definitely changing from you're typing in lines of code to you're having agents type in lines of code, and you are reviewing the work of the agents. But it is but a tool, and there are still programmers involved in the process.
That I firmly believe."
For the full conversation, you can search Anders' name on my YouTube, Spotify or Apple Podcasts (link in bio)
4
17
116
Sergey Levine (@svlevine) is one of the world's top robotics researchers and co-founder of Physical Intelligence.
We talked about where humanoid robotics is today, thoughts on the Chinese robotics ecosystem, and his predictions for future timelines.
In this episode:
• cs and surprising capabilities so far
• Chinese robotics compared to US ecosystem
• If OpenAI and Anthropic got into robotics
• His top robotics research paper recommendation
• Predictions for when humanoid robotics will land
Where to watch:
• YouTube - youtu.be/9OSbaPjv0Rc
• Spotify - open.spotify.com/episode/19amTr…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/sergey-levin…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:37 Where are we today
04:20 Most surprising capabilities so far
07:03 The most inspiring real world robotics
08:36 If OpenAI or Anthropic got into robotics
10:22 Chinese robotics
13:15 Will one lab breakout from the rest
16:59 Thoughts on a concrete roadmap
21:03 Generalization and demonstrating it
26:04 Types of data and which is best for robotics
34:34 Why humanoid robotics differs from Waymo
37:10 If humanoid robotics failed here is why
39:55 Are there hot take modeling architectures in robotics
42:05 Thoughts on AI safety in robotics
46:44 Top robotics research paper recommendation
49:35 Why is Boston Dynamics less top of mind
53:47 Advice for his younger self
56:42 Outro
We talked about where humanoid robotics is today, thoughts on the Chinese robotics ecosystem, and his predictions for future timelines.
In this episode:
• cs and surprising capabilities so far
• Chinese robotics compared to US ecosystem
• If OpenAI and Anthropic got into robotics
• His top robotics research paper recommendation
• Predictions for when humanoid robotics will land
Where to watch:
• YouTube - youtu.be/9OSbaPjv0Rc
• Spotify - open.spotify.com/episode/19amTr…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/sergey-levin…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:37 Where are we today
04:20 Most surprising capabilities so far
07:03 The most inspiring real world robotics
08:36 If OpenAI or Anthropic got into robotics
10:22 Chinese robotics
13:15 Will one lab breakout from the rest
16:59 Thoughts on a concrete roadmap
21:03 Generalization and demonstrating it
26:04 Types of data and which is best for robotics
34:34 Why humanoid robotics differs from Waymo
37:10 If humanoid robotics failed here is why
39:55 Are there hot take modeling architectures in robotics
42:05 Thoughts on AI safety in robotics
46:44 Top robotics research paper recommendation
49:35 Why is Boston Dynamics less top of mind
53:47 Advice for his younger self
56:42 Outro
5
32
287
Will AI write +90% of all code this year?
Anders Hejlsberg (Creator of Typescript, C#): "For certain classes of apps that might be like all of I coded apps are writing 100% of the code. And there's an awful lot of that being written.
Are they going to write 90% of the high ernet? I don't know about that. I know that AI could not write our compiler, the Typescript compiler.
It just can't. We've tried it can't do it. And I'm not asking it to either.
I'm not saying it's not impressive. It's wildly impressive what it can do, But I just think there's a long way still to it's doing all of it. And I don't know that we ever get there.
I hope we don't. Because then what's the point of humans anymore?"
For the full conversation, you can search Ander's name on my YouTube, Spotify or Apple Podcasts (link in bio)
Anders Hejlsberg (Creator of Typescript, C#): "For certain classes of apps that might be like all of I coded apps are writing 100% of the code. And there's an awful lot of that being written.
Are they going to write 90% of the high ernet? I don't know about that. I know that AI could not write our compiler, the Typescript compiler.
It just can't. We've tried it can't do it. And I'm not asking it to either.
I'm not saying it's not impressive. It's wildly impressive what it can do, But I just think there's a long way still to it's doing all of it. And I don't know that we ever get there.
I hope we don't. Because then what's the point of humans anymore?"
For the full conversation, you can search Ander's name on my YouTube, Spotify or Apple Podcasts (link in bio)
6
10
97
Why Microsoft didn't have LLMs do their recent Typescript native rewrite in Go
Anders Hejlsberg (Creator of Typescript): "If we just let AI loose on, what is it, half a million lines of code that we have in the old compiler? Well, I don't know that that would absolve us from arefully examining every line that came out of it to make sure that there were no hallucinations.
Right. Unless you have 100% perfect test coverage, you probably still gotta go check all of that.
Now I think a better approach, quite honestly, would be enlist AI to write a program that helps you translate from TypeScript to go, because at that point you can park the stochastic ness in that program and then you can get deterministic behavior whenever you run the program, which means you get the same transformation every time you run it.
Right. That's always the thing about AI that people forget it's not deterministic. Right.
So you can't really trust that it's going to do the same thing twice.
For the full conversation, you can search Anders Hejlsberg's name on my YouTube, Spotify or Apple Podcasts (link in bio)
Anders Hejlsberg (Creator of Typescript): "If we just let AI loose on, what is it, half a million lines of code that we have in the old compiler? Well, I don't know that that would absolve us from arefully examining every line that came out of it to make sure that there were no hallucinations.
Right. Unless you have 100% perfect test coverage, you probably still gotta go check all of that.
Now I think a better approach, quite honestly, would be enlist AI to write a program that helps you translate from TypeScript to go, because at that point you can park the stochastic ness in that program and then you can get deterministic behavior whenever you run the program, which means you get the same transformation every time you run it.
Right. That's always the thing about AI that people forget it's not deterministic. Right.
So you can't really trust that it's going to do the same thing twice.
For the full conversation, you can search Anders Hejlsberg's name on my YouTube, Spotify or Apple Podcasts (link in bio)
38
94
601
Anders Hejlsberg ( @ahejlsberg ) is the creator of TypeScript and C#, and I asked him about how the TypeScript compiler got 10x faster through a rewrite in Go and his thoughts on how AI has impacted software engineering.
In this episode:
• How rewriting the compiler makes it picked Go instead of Rust
• Why they didn't use LLMs for the migration
• Predictions on AI's impact on software engineering
Where to watch:
• YouTube - youtube.com/watch?v=cywK3X…
• Spotify - open.spotify.com/episode/1thvWd…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-t…
Thank you to the sponsors of this episode 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 workos.com
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
Chapters:
00:00 Intro
00:48 Why write a compiler in JavaScript
07:29 Why rewrite the compiler in Go
14:49 LLMs for large migrations
20:12 Why Javascript is so popular
26:32 Why ever use Javascript on the backend
32:59 What it takes to build a programming language
37:06 Will there be fewer languages in 10 years
42:57 Hands on engineering vs delegation
49:14 Why fast tooling matters more now
51:16 AI software engineering predictions
58:52 The most technically challenging work
01:02:04 Top book recommendation
01:03:50 Advice for his younger self
01:05:00 Outro
In this episode:
• How rewriting the compiler makes it picked Go instead of Rust
• Why they didn't use LLMs for the migration
• Predictions on AI's impact on software engineering
Where to watch:
• YouTube - youtube.com/watch?v=cywK3X…
• Spotify - open.spotify.com/episode/1thvWd…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-t…
Thank you to the sponsors of this episode 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 workos.com
• Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev
Chapters:
00:00 Intro
00:48 Why write a compiler in JavaScript
07:29 Why rewrite the compiler in Go
14:49 LLMs for large migrations
20:12 Why Javascript is so popular
26:32 Why ever use Javascript on the backend
32:59 What it takes to build a programming language
37:06 Will there be fewer languages in 10 years
42:57 Hands on engineering vs delegation
49:14 Why fast tooling matters more now
51:16 AI software engineering predictions
58:52 The most technically challenging work
01:02:04 Top book recommendation
01:03:50 Advice for his younger self
01:05:00 Outro
7
56
434
Dijkstra to John Backus: "it is my pleasure to inform you that - although "quite sure" - you were very wrong
2
2
37
Leonardo de Moura (@Leonard41111588) is the creator of Lean and the Z3 theorem prover. I talked with him about how Lean works and why LLMs plus Lean will fundamentally change how we write software and do math.
In this episode:
• How formal verification and proof assistants impact handwritten math & software
• Lean’s role in recent math breakthroughs
• When software is worth formalizing
Where to watch:
• YouTube - youtu.be/KzdYKeAqWhY
• Spotify - open.spotify.com/episode/34dbrI…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-l…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:28 How formal verification works
05:21 A new way of writing software
13:15 Proof assistants vs programming languages
21:06 How Lean has assisted in mathematical breakthroughs
32:03 When is it worth formalizing software
33:29 How Lean will impact handwritten math
38:55 The Z3 theorem prover project he started
45:44 The most technically challenging work of his career
51:10 Lean vs its competitors
01:00:37 The future of Lean
01:04:10 Technical book recommendations
01:06:15 Advice for his younger self
01:07:10 Outro
In this episode:
• How formal verification and proof assistants impact handwritten math & software
• Lean’s role in recent math breakthroughs
• When software is worth formalizing
Where to watch:
• YouTube - youtu.be/KzdYKeAqWhY
• Spotify - open.spotify.com/episode/34dbrI…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-l…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 Intro
00:28 How formal verification works
05:21 A new way of writing software
13:15 Proof assistants vs programming languages
21:06 How Lean has assisted in mathematical breakthroughs
32:03 When is it worth formalizing software
33:29 How Lean will impact handwritten math
38:55 The Z3 theorem prover project he started
45:44 The most technically challenging work of his career
51:10 Lean vs its competitors
01:00:37 The future of Lean
01:04:10 Technical book recommendations
01:06:15 Advice for his younger self
01:07:10 Outro
3
41
193
Roberto Ierusalimschy is the creator of the Lua programming language.
I interviewed him about Lua's unique strengths, programming language design and predictions for how AI will impact programming languages.
In this episode:
• Lua design choices that set it apart
• JIT rd
• Cross-language calls and how they work
• Predictions for AI's impact on programming languages
Where to watch:
• YouTube - youtu.be/jCZnFKk6M9A
• Spotify - open.spotify.com/episode/3SWEjG…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-l…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 - Intro
00:43 - What sets Lua apart
08:35 - Comparing Lua with Python
13:04 - Top book recommendation on language design
14:20 - How JIT works and why it is hard
23:21 - Compiling Python and interpreting C
30:31 - How cross language calls work
36:58 - Lua unique design decisions
51:17 - Predictions for AIs impact on languages
01:00:10 - Top 3 languages to learn to become a better engineer
01:03:21 - Advice for his younger self
01:04:19 - Outro
I interviewed him about Lua's unique strengths, programming language design and predictions for how AI will impact programming languages.
In this episode:
• Lua design choices that set it apart
• JIT rd
• Cross-language calls and how they work
• Predictions for AI's impact on programming languages
Where to watch:
• YouTube - youtu.be/jCZnFKk6M9A
• Spotify - open.spotify.com/episode/3SWEjG…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-l…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 - Intro
00:43 - What sets Lua apart
08:35 - Comparing Lua with Python
13:04 - Top book recommendation on language design
14:20 - How JIT works and why it is hard
23:21 - Compiling Python and interpreting C
30:31 - How cross language calls work
36:58 - Lua unique design decisions
51:17 - Predictions for AIs impact on languages
01:00:10 - Top 3 languages to learn to become a better engineer
01:03:21 - Advice for his younger self
01:04:19 - Outro
1
9
42
Judea Pearl (@yudapearl) is a Turing Award winner famous for his contributions to artificial intelligence and causal reasoning.
We talked about the greatest scientist of all time, his major breakthroughs and his predictions for AI today. Full conversation also on my YouTube, asts.
Timestamps:
00:00 Intro
00:54 How he got into AI
11:17 Greatest scientist of all time
20:15 What people thought of AI in the 80s
26:23 Entering academia and researching AI
34:52 The invention of Bayesian networks
46:28 Pioneering work in causality
55:38 The causal hierarchy
59:34 LLMs and predictions
01:20:12 A restless mind pays
01:24:36 Advice for his younger self
01:26:37 Outro
We talked about the greatest scientist of all time, his major breakthroughs and his predictions for AI today. Full conversation also on my YouTube, asts.
Timestamps:
00:00 Intro
00:54 How he got into AI
11:17 Greatest scientist of all time
20:15 What people thought of AI in the 80s
26:23 Entering academia and researching AI
34:52 The invention of Bayesian networks
46:28 Pioneering work in causality
55:38 The causal hierarchy
59:34 LLMs and predictions
01:20:12 A restless mind pays
01:24:36 Advice for his younger self
01:26:37 Outro
2
13
123
PR1 robot from Stanford (2007), didn't realize the hardware was that capable back then
This is teleoperated so there is a human in the loop but still thought it was interesting given the year it came out
This is teleoperated so there is a human in the loop but still thought it was interesting given the year it came out
2
0
15
@abra55513382 @hievanking I interviewed him here if you're curious about how he did it: youtube.com/watch?v=yZ4J98…
0
0
3
Xavier Leroy (creator of OCaml) is an expert in compilers, formal verification of software and functional programming.
This interview should be an approachable resource if you're curious about formal verification of software since I was learning that on the fly during it.
In compared with Rust and JavaScript
• What is formal verification and how does it work
• How languages call each other across boundaries
• How to address "almost-correct" LLM code
• How type inference works in programming languages
Where to watch:
• YouTube - youtu.be/9Cswiqrq6So
• Spotify - open.spotify.com/episode/7cdatl…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-o…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 - Intro
00:43 - What sets OCaml apart
04:39 - OCaml vs Rust
07:57 - Why is manual memory management more performant
11:21 - Javascript vs OCaml
14:00 - Famous Rob Pike quote
16:05 - Type inference and how it works
22:12 - What is formal verification and how does it work
40:07 - What made multicore support difficult for OCaml
50:17 - How programming languages interface and call each other
57:41 - The danger of almost-correct LLM code
01:05:39 - How LLMs will change programming languages
01:10:26 - Industry vs academia
01:15:05 - Most interesting unsolved problems
01:18:30 - Top book recommendations for engineers
01:21:17 - Advice for his younger self
01:23:31 - Outro
This interview should be an approachable resource if you're curious about formal verification of software since I was learning that on the fly during it.
In compared with Rust and JavaScript
• What is formal verification and how does it work
• How languages call each other across boundaries
• How to address "almost-correct" LLM code
• How type inference works in programming languages
Where to watch:
• YouTube - youtu.be/9Cswiqrq6So
• Spotify - open.spotify.com/episode/7cdatl…
• Apple Podcasts - podcasts.apple.com/us/podcast/the…
• Transcript - developing.dev/p/creator-of-o…
Thank you to the sponsor of this episode 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 workos.com
Chapters:
00:00 - Intro
00:43 - What sets OCaml apart
04:39 - OCaml vs Rust
07:57 - Why is manual memory management more performant
11:21 - Javascript vs OCaml
14:00 - Famous Rob Pike quote
16:05 - Type inference and how it works
22:12 - What is formal verification and how does it work
40:07 - What made multicore support difficult for OCaml
50:17 - How programming languages interface and call each other
57:41 - The danger of almost-correct LLM code
01:05:39 - How LLMs will change programming languages
01:10:26 - Industry vs academia
01:15:05 - Most interesting unsolved problems
01:18:30 - Top book recommendations for engineers
01:21:17 - Advice for his younger self
01:23:31 - Outro
5
75
423