diff --git a/animation/projects/package-lock.json b/animation/projects/package-lock.json
index 7a61f91..7b0bb53 100644
--- a/animation/projects/package-lock.json
+++ b/animation/projects/package-lock.json
@@ -1,11 +1,11 @@
 {
-  "name": "parallelism",
+  "name": "projects",
   "version": "0.0.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
-      "name": "parallelism",
+      "name": "projects",
       "version": "0.0.0",
       "dependencies": {
         "@lezer/cpp": "^1.1.2",
diff --git a/animation/projects/src/std_function/project.meta b/animation/projects/src/std_function/project.meta
new file mode 100644
index 0000000..7579bae
--- /dev/null
+++ b/animation/projects/src/std_function/project.meta
@@ -0,0 +1,31 @@
+{
+  "version": 0,
+  "shared": {
+    "background": "rgb(10,20,30)",
+    "range": [
+      0,
+      null
+    ],
+    "size": {
+      "x": 1920,
+      "y": 1080
+    },
+    "audioOffset": 0
+  },
+  "preview": {
+    "fps": 30,
+    "resolutionScale": 1
+  },
+  "rendering": {
+    "fps": 30,
+    "resolutionScale": 2,
+    "colorSpace": "srgb",
+    "exporter": {
+      "name": "@motion-canvas/ffmpeg",
+      "options": {
+        "fastStart": true,
+        "includeAudio": true
+      }
+    }
+  }
+}
\ No newline at end of file
diff --git a/animation/projects/src/std_function/project.ts b/animation/projects/src/std_function/project.ts
new file mode 100644
index 0000000..487161e
--- /dev/null
+++ b/animation/projects/src/std_function/project.ts
@@ -0,0 +1,9 @@
+import { makeProject } from '@motion-canvas/core';
+
+import '../../global.css';
+
+import std_function from './scenes/std_function?scene';
+
+export default makeProject({
+    scenes: [std_function],
+});
diff --git a/animation/projects/src/std_function/scenes/std_function.meta b/animation/projects/src/std_function/scenes/std_function.meta
new file mode 100644
index 0000000..25c7da9
--- /dev/null
+++ b/animation/projects/src/std_function/scenes/std_function.meta
@@ -0,0 +1,5 @@
+{
+  "version": 0,
+  "timeEvents": [],
+  "seed": 3221513550
+}
\ No newline at end of file
diff --git a/animation/projects/src/std_function/scenes/std_function.tsx b/animation/projects/src/std_function/scenes/std_function.tsx
new file mode 100644
index 0000000..6d24fc9
--- /dev/null
+++ b/animation/projects/src/std_function/scenes/std_function.tsx
@@ -0,0 +1,180 @@
+import { makeScene2D, Code, LezerHighlighter, lines, Node, Rect, Txt, Line } from '@motion-canvas/2d';
+import { all, createRef, waitFor } from '@motion-canvas/core';
+import { MyStyle } from '../../styles';
+import { parser as parser_cpp } from '@lezer/cpp';
+import { DEFAULT } from '@motion-canvas/core/lib/signals';
+import { centerOn } from '../../utils';
+
+import templateCode from '@lectures/std_function.md?snippet=std_function/template_button.cpp';
+import stdFunctionCode from '@lectures/std_function.md?snippet=std_function/std_function_button.cpp';
+import multiButtonCode from '@lectures/std_function.md?snippet=std_function/multi_button.cpp';
+import typeErasureCode from '@lectures/std_function.md?snippet=std_function/type_erasure.cpp';
+
+const CppHighlighter = new LezerHighlighter(parser_cpp, MyStyle);
+
+export default makeScene2D(function* (view) {
+    const codeRef = createRef<Code>();
+
+    view.add(
+        <Code
+            ref={codeRef}
+            fontSize={26}
+            fontFamily={'Fira Mono'}
+            highlighter={CppHighlighter}
+            code={templateCode}
+        />
+    );
+
+    // Initial delay
+    yield* waitFor(1);
+
+    // 1. Template Button
+    yield* centerOn(codeRef(), lines(3, 4), 1, 40); // template <typename Callback>
+    yield* waitFor(3);
+
+    yield* centerOn(codeRef(), [lines(16, 16), lines(6, 7)], 1, 40); // Callback on_click_;
+    yield* waitFor(3);
+
+    yield* centerOn(codeRef(), [lines(16, 16), lines(6, 7), lines(9, 12)], 1, 40); // Callback on_click_;
+    yield* waitFor(3);
+
+    yield* centerOn(codeRef(), [lines(24, 25)], 1, 40); // std::vector<Button> buttons;
+    yield* waitFor(3);
+
+    yield* centerOn(codeRef(), [lines(24, 24), lines(22, 22)], 1, 40); // std::vector<Button> buttons;
+    yield* waitFor(3);
+
+    yield* centerOn(codeRef(), [lines(25, 25), lines(19, 19)], 1, 40); // std::vector<Button> buttons;
+    yield* waitFor(3);
+
+    yield* centerOn(codeRef(), [lines(27, 28)], 1, 40); // std::vector<Button> buttons;
+    yield* waitFor(3);
+
+    // 3. std::function Button
+    yield* codeRef().code(templateCode, 0);
+    yield* centerOn(codeRef(), DEFAULT, 0, 24);
+    yield* waitFor(1);
+    yield* codeRef().code(stdFunctionCode, 1);
+    yield* waitFor(1);
+
+    yield* centerOn(codeRef(), lines(7, 7), 1, 40); // explicit Button(std::string name, std::function<void()> callback)
+    yield* waitFor(1);
+
+    yield* centerOn(codeRef(), [lines(7, 8), lines(17, 17)], 1, 40); // explicit Button(std::string name, std::function<void()> callback)
+    yield* waitFor(3);
+
+    yield* centerOn(codeRef(), lines(22, 48), 1, 40); // std::function<void()> on_click_;
+    yield* waitFor(3);
+
+    yield* centerOn(codeRef(), lines(28, 30), 1, 40); // std::vector<Button> buttons{play_button, quit_button};
+    yield* waitFor(3);
+
+    // 4. MultiButton
+    yield* codeRef().code(stdFunctionCode, 0);
+    yield* centerOn(codeRef(), DEFAULT, 0, 22);
+    yield* waitFor(1);
+    yield* codeRef().code(multiButtonCode, 1);
+    yield* waitFor(1);
+
+    yield* centerOn(codeRef(), [lines(7, 8)], 1, 30);
+    yield* waitFor(0.5);
+    yield* centerOn(codeRef(), [lines(7, 8), lines(19, 19)], 1, 30);
+    yield* waitFor(3);
+
+    yield* centerOn(codeRef(), [lines(25, 28), lines(30, 30)], 1, 30);
+    yield* waitFor(1);
+
+    yield* centerOn(codeRef(), [lines(12, 14)], 1, 30);
+    yield* waitFor(3);
+
+
+    yield* centerOn(codeRef(), DEFAULT, 1, 22);
+    yield* waitFor(3);
+
+    yield* centerOn(codeRef(), [lines(13, 13)], 1, 35);
+    yield* waitFor(3);
+
+    // 5. Type Erasure
+    yield* centerOn(codeRef(), DEFAULT, 0, 20);
+    yield* codeRef().code(typeErasureCode, 0);
+    yield* waitFor(1);
+
+    yield* centerOn(codeRef(), lines(3, 3), 1, 32);
+    yield* waitFor(1);
+    yield* centerOn(codeRef(), [lines(13, 18), lines(28, 28)], 1, 32);
+    yield* waitFor(1);
+
+    yield* centerOn(codeRef(), lines(19, 27), 1, 36);
+    yield* waitFor(1);
+    yield* centerOn(codeRef(), [lines(19, 27), lines(5, 8)], 1, 35);
+    yield* waitFor(3);
+
+    yield* centerOn(codeRef(), lines(30, 42), 1, 36);
+    yield* waitFor(3);
+    yield* centerOn(codeRef(), lines(10, 10), 1, 36);
+    yield* waitFor(1);
+    yield* centerOn(codeRef(), [lines(16, 16)], 1, 35);
+    yield* waitFor(1);
+    yield* centerOn(codeRef(), [lines(23, 23)], 1, 35);
+    yield* waitFor(3);
+
+    const myFuncRect = createRef<Rect>();
+    const baseRect = createRef<Rect>();
+    const implRect = createRef<Rect>();
+    const tRect = createRef<Rect>();
+
+    const line1 = createRef<Line>();
+    const line2 = createRef<Line>();
+    const line3 = createRef<Line>();
+
+    view.add(
+        <Node y={0} scale={1.4}>
+            <Rect ref={myFuncRect} width={240} height={60} x={-505} fill="#2d2d2d" radius={10} opacity={0}>
+                <Txt text="~MyFunction()" fill="#eeeeee" fontFamily="Fira Mono" fontSize={24} />
+            </Rect>
+            <Line ref={line1} points={[[-375, 0], [-295, 0]]} stroke="#569CD6" lineWidth={4} endArrow end={0} />
+            <Rect ref={baseRect} width={260} height={60} x={-155} fill="#2d2d2d" radius={10} opacity={0}>
+                <Txt text="~CallableBase()" fill="#eeeeee" fontFamily="Fira Mono" fontSize={24} />
+            </Rect>
+            <Line ref={line2} points={[[-15, 0], [65, 0]]} stroke="#569CD6" lineWidth={4} endArrow end={0} />
+            <Rect ref={implRect} width={300} height={60} x={225} fill="#2d2d2d" radius={10} opacity={0}>
+                <Txt text="~CallableImpl<T>()" fill="#eeeeee" fontFamily="Fira Mono" fontSize={24} />
+            </Rect>
+            <Line ref={line3} points={[[385, 0], [465, 0]]} stroke="#569CD6" lineWidth={4} endArrow end={0} />
+            <Rect ref={tRect} width={150} height={60} x={550} fill="#2d2d2d" radius={10} opacity={0}>
+                <Txt text="~T()" fill="#eeeeee" fontFamily="Fira Mono" fontSize={24} />
+            </Rect>
+        </Node>
+    );
+
+    // 6. Destructors flow
+    yield* codeRef().opacity(0, 1);
+
+    yield* myFuncRect().opacity(1, 0.5);
+    yield* waitFor(0.5);
+    yield* line1().end(1, 0.5);
+    yield* baseRect().opacity(1, 0.5);
+    yield* waitFor(0.5);
+    yield* line2().end(1, 0.5);
+    yield* implRect().opacity(1, 0.5);
+    yield* waitFor(0.5);
+    yield* line3().end(1, 0.5);
+    yield* tRect().opacity(1, 0.5);
+    yield* waitFor(3);
+
+    yield* all(
+        tRect().opacity(0, 0.5),
+        line3().opacity(0, 0.5),
+        implRect().opacity(0, 0.5),
+        line2().opacity(0, 0.5),
+        baseRect().opacity(0, 0.5),
+        line1().opacity(0, 0.5),
+        myFuncRect().opacity(0, 0.5),
+    );
+
+    yield* centerOn(codeRef(), DEFAULT, 0, 20);
+    yield* codeRef().opacity(1, 1);
+
+    yield* centerOn(codeRef(), DEFAULT, 1, 20);
+    yield* waitFor(3);
+});
diff --git a/animation/projects/vite.config.ts b/animation/projects/vite.config.ts
index df91990..1d5a658 100644
--- a/animation/projects/vite.config.ts
+++ b/animation/projects/vite.config.ts
@@ -15,6 +15,7 @@ export default defineConfig({
     motionCanvas({
       project: [
         './src/dummy/project.ts',
+        './src/std_function/project.ts',
       ]
     }),
     ffmpeg(),
diff --git a/lectures/std_function.md b/lectures/std_function.md
new file mode 100644
index 0000000..92f126c
--- /dev/null
+++ b/lectures/std_function.md
@@ -0,0 +1,359 @@
+`std::function`
+--
+
+<p align="center">
+  <a href="https://youtu.be/_qteFBrAKSM"><img src="https://img.youtube.com/vi/_qteFBrAKSM/maxresdefault.jpg" alt="Video Thumbnail" align="right" width=50% style="margin: 0.5rem"></a>
+</p>
+
+- [`std::function`](#stdfunction)
+- [Overview](#overview)
+- [The problem: storing callables](#the-problem-storing-callables)
+- [Enter `std::function`](#enter-stdfunction)
+- [Performance considerations](#performance-considerations)
+- [Type Erasure (How it works under the hood)](#type-erasure-how-it-works-under-the-hood)
+- [Summary](#summary)
+
+<!-- Hey everyone. It has been a while since the last video, but I have a good reason for such a delay! Anyway, I finally found the time to record another video so let's dive in! -->
+
+Remember in one of our [previous lectures](lambdas.md) we looked at lambdas? We saw how they give us an easy and clean way to create function objects on the fly, saving us from writing boilerplate structs just to pass a callable - for example, a simple comparator or an operation to a standard algorithm.
+
+But what happens if we want to store these callables somewhere and call them at a later time? And what if we want these callables to be *anything* that behaves like a function, not just lambdas? 
+
+This setup is exactly where [`std::function`](https://en.cppreference.com/cpp/utility/functional/function) comes to the rescue!
+
+<!-- Intro -->
+
+## The problem: storing callables
+As always, let's start with an illustrative example. Imagine we are building a UI framework, and we want to create a `Button` class. A button doesn't have to know *what* should happen when it is clicked, it just needs to know that it *has* been clicked. The user of our `Button` object should be able to hook up any logic they want by passing in a *callback* - a callable that is called when an action takes place, in our case, when the button gets clicked.
+
+One thing we could do is to use **templates**. If we template the entire `Button` class on the type of the callable, we can store the provided callback as a member variable, say, `on_click_` and call it when the click occurs:
+
+<!-- 
+`CPP_COPY_SNIPPET` std_function/template_button.cpp
+`CPP_RUN_CMD` CWD:std_function c++ -std=c++17 template_button.cpp
+-->
+```cpp
+#include <iostream>
+#include <string>
+
+template <typename Callback>
+class Button {
+ public:
+  Button(std::string name, Callback callback)
+      : name_{std::move(name)}, on_click_{std::move(callback)} {}
+
+  void Click() const {
+    std::cout << "[" << name_ << "] was clicked.\n";
+    on_click_();
+  }
+
+ private:
+  std::string name_{};
+  Callback on_click_{};
+};
+
+void QuitGame() { std::cout << "Quitting game...\n"; }
+
+int main() {
+  const auto lambda_play = [] { std::cout << "Playing game!\n"; };
+
+  const Button play_button{"Play", lambda_play};
+  const Button quit_button{"Quit", QuitGame};
+
+  play_button.Click();
+  quit_button.Click();
+}
+```
+
+With this approach, we can create, say a "play" button and a "quit" button that each calls their own callback. It's not a bad approach! 
+
+Look how our templated `Button` handles the different types of callables seamlessly. We don't even need to provide the template type as it is inferred using [Class Template Argument Deduction](https://en.cppreference.com/w/cpp/language/class_template_argument_deduction)! Here we pass a lambda into the "play" button callback and a free standing function into the "quit" button callback.
+
+If we just want to create these buttons and use them in isolation, like in our example, this approach works wonderfully! On top of everything else, it's blazing fast because the compiler knows the exact type of the callback at compile time and can optimize it perfectly. 
+
+However, as soon as we try to build a more complex and dynamic system, things get more complicated.
+
+**Problem 1: Heterogeneous Collections**
+For example, a UI framework usually needs a way to draw all buttons on the screen or handle their input in a loop. So we would like to put them all in a `std::vector`. But `std::vector` requires all its elements to be of the *exact same type*. Because `play_button` is templated on a lambda (a unique class generated by the compiler) and `quit_button` is templated on a function pointer, they are [two entirely different types](https://cppinsights.io/s/edda9741). We cannot store them in the same vector!
+
+<!--
+`CPP_SKIP_SNIPPET`
+-->
+```cpp
+template<>
+class Button<__lambda_23_22> {
+  // Specialization code generated by the compiler
+};
+
+template<>
+class Button<void(*)()> {
+  // Specialization code generated by the compiler
+};
+
+// ❌ Won't compile. What is the type of the vector?
+// play_button and quit_button are DIFFERENT class types!
+std::vector<Button<???>> buttons{play_button, quit_button};
+```
+
+**Problem 2: Multiple Mixed Callbacks**
+In addition to that, what if we wanted a single button to trigger *multiple* actions when clicked? We could change `Callback on_click_` to `std::vector<Callback> on_click_callbacks_`. But again, because `std::vector` demands a single type for all of its elements, we could only store multiple copies of the *exact same* lambda or the *exact same* function pointer. We couldn't mix a lambda and a function object inside the same button's list of callbacks.
+
+But what about [`std::variant`](variant.md), I hear some of you ask? Well, technically it would allow us to store various types of callables in a single vector, but some of those types would be horrible temporary anonymous classes generated by the compiler (like in the case of a lambda)! So we wouldn't be able to provide them to our variant upfront! Which brings us to the same problem: what type would a vector store?
+
+## Enter `std::function`
+To solve all of these problems we can use `std::function`, introduced in C++11 and available in the `<functional>` header. It is a wrapper that can store, copy, move, and invoke *any* callable target — be it a function, a lambda expression, a [bind](https://en.cppreference.com/cpp/utility/functional/bind) expression, or a function object — as long as its signature matches the one specified in the `std::function` template argument.
+
+The syntax for `std::function` is straightforward, it is a template class templated on the return type as well as all the argument types in parentheses:
+<!--
+`CPP_SKIP_SNIPPET`
+-->
+```cpp
+std::function<ReturnType(ArgumentType1, ArgumentType2, ...)>
+```
+
+All of these can be references, pointers, `const` etc. just like any normal function arguments.
+
+Let's rewrite our `Button` class using `std::function` then. We will remove the template from the class and instead use `std::function<void()>` for our callback (meaning "takes no arguments, returns void"). Let's start by keeping exactly one callback per button, matching our original example:
+
+<!-- 
+`CPP_COPY_SNIPPET` std_function/std_function_button.cpp
+`CPP_RUN_CMD` CWD:std_function c++ -std=c++17 std_function_button.cpp
+-->
+```cpp
+#include <functional>
+#include <iostream>
+#include <string>
+#include <vector>
+
+class Button {
+ public:
+  Button(std::string name, std::function<void()> callback)
+      : name_{std::move(name)}, on_click_{std::move(callback)} {}
+
+  void Click() const {
+    std::cout << "[" << name_ << "] was clicked.\n";
+    if (on_click_) { on_click_(); }
+  }
+
+ private:
+  std::string name_{};
+  std::function<void()> on_click_{};
+};
+
+void QuitGame() { std::cout << "Quitting game...\n"; }
+
+int main() {
+  const auto lambda_play = [] { std::cout << "Playing game!\n"; };
+
+  const Button play_button{"Play", lambda_play};
+  const Button quit_button{"Quit", QuitGame};
+
+  // ✅ This works now! Both buttons are the EXACT SAME type.
+  const std::vector<Button> buttons{play_button, quit_button};
+
+  for (const auto& button : buttons) { button.Click(); }
+}
+```
+
+There are not that many changes really! The `Button` class is not templated anymore but takes a `std::function<void()>` callback as a parameter and stores this callback internally. 
+
+The main function also remains very similar, except now we can put our buttons in a vector. 
+
+When we run this, it works beautifully, calling both of our buttons' callbacks:
+
+```
+[Play] was clicked.
+Playing game!
+[Quit] was clicked.
+Quitting game...
+```
+
+And what about our second problem? Now that our callbacks are wrapped in a uniform type, we can easily change our `Button` class to store a `std::vector` of different `std::function` objects, allowing us to attach multiple diverse actions to a single button. We can pass this vector of callbacks in the constructor and store it as a class member:
+
+<!-- 
+`CPP_COPY_SNIPPET` std_function/multi_button.cpp
+`CPP_RUN_CMD` CWD:std_function c++ -std=c++17 multi_button.cpp
+-->
+```cpp
+#include <functional>
+#include <iostream>
+#include <string>
+#include <vector>
+
+class Button {
+ public:
+  Button(std::string name, std::vector<std::function<void()>> callbacks) 
+      : name_{std::move(name)}, on_click_callbacks_{std::move(callbacks)} {}
+
+  void Click() const {
+    std::cout << "[" << name_ << "] was clicked.\n";
+    for (const auto& callback : on_click_callbacks_) {
+      if (callback) { callback(); }
+    }
+  }
+
+ private:
+  std::string name_{};
+  std::vector<std::function<void()>> on_click_callbacks_{};
+};
+
+void QuitGame() { std::cout << "Quitting game...\n"; }
+
+int main() {
+  const Button play_button{"Play", {
+    [] { std::cout << "Playing game!\n"; },
+    [] { std::cout << "Logging: Play was clicked.\n"; },
+  }};
+
+  const Button quit_button{"Quit", {QuitGame}};
+
+  const std::vector<Button> buttons{play_button, quit_button};
+
+  for (const auto& button : buttons) { button.Click(); }
+}
+```
+
+We can now pass a vector of callbacks to a button in the `main` function, and call all of them in a `for` loop when a button is clicked. The rest of the example stays largely the same.
+
+When we run the code, all of our callbacks are being called as expected:
+
+```
+[Play] was clicked.
+Playing game!
+Logging: Play was clicked.
+[Quit] was clicked.
+Quitting game...
+```
+
+Notice that `std::function` can also be empty! Just like pointers can be `nullptr`, a `std::function` can hold nothing. If we try to call an empty `std::function`, it throws a `std::bad_function_call` [exception](error_handling.md). That's why we check `if (callback)` before calling it, similar to how we can check if a pointer is valid before dereferencing it.
+
+## Performance considerations
+Now, before we go rewriting all our code to use `std::function`, we need to have a brief chat about performance. While `std::function` is incredibly flexible, that flexibility comes at a cost.
+
+Let's look at the pros and cons of each of the two approaches we just explored.
+
+**Template Approach:**
+
+- **Pro**: The compiler knows the exact type of the callable at compile time making it easier for the compiler to optimize the code. This approach is fast and never allocates memory on the heap.
+- **Con**: It relies on static, compile-time polymorphism. For every different callable type we pass, the compiler generates a completely new class type or function. Also, all implementation lives in headers unless we [pre-compile for a selected set of callable types](templates_and_headers.md).
+- **Con**: Objects have different types so we can't store them in a single standard container.
+
+**`std::function` Approach:**
+
+- **Pro**: The `std::function` can wrap *any* callable matching the provided signature **at runtime**. 
+- **Pro**: All matching callables are wrapped in the exact same type (e.g., `std::function<void()>()`), so we can easily store them in standard containers, pass them around, and swap out their callbacks on the fly.
+- **Con**: **Heap Allocation**. Implementations of `std::function` usually have a small internal buffer (Small Object Optimization) to store small callables, which is quite fast to use. But if our callable's state (like a lambda with a large capture list) is too large for the internal buffer, `std::function` will call `new` to allocate memory on the heap. This can be a major performance bottleneck if used on a hot path.
+- **Con**: **Virtual Call Overhead**. Invoking a `std::function` generally involves an indirect function call (like calling a [virtual function](inheritance.md#runtime-and-memory-overhead-of-using-virtual)), which can make it harder for the compiler to perform all of its optimizations. 
+
+Because of this, if we are writing performance-critical code on hot paths (like a `std::sort` algorithm that runs a callable we pass into it millions of times a second), we typically stick to templates. 
+
+<!-- 
+`CPP_SKIP_SNIPPET`
+-->
+```cpp
+// std::sort taking a templated callable as a parameter
+template<class RandomIt, class Compare>
+void sort(RandomIt first, RandomIt last, Compare comp);
+```
+
+On the contrary, `std::function` is for situations like UI callbacks and event handlers, where we want to store and maybe even replace different callable types at runtime and the tiny performance overhead of a virtual call doesn't matter. 
+
+However, what I just said is just a rule of a thumb. When performance really matters - we should always measure the alternatives and pick the option that suits us best! 
+
+## Type erasure (how it works under the hood)
+Finally, I want to briefly talk about how `std::function` actually works under the hood. How can it store an arbitrary callable (say a lambda or a functor) without knowing its exact type at compile time? How does it all get cleaned up neatly without [leaking memory](memory_and_smart_pointers.md)?
+
+This is achieved using a design pattern called **type erasure**.
+
+> 💡 Note that you don't have to know this to use `std::function`! It is also very unlikely that you'll ever need to implement your own type-erased wrapper. Still, it is a pretty cool pattern worth knowing about. It's used in several places in the standard library, including `std:shared_ptr`, `std::any`, and, as we'll see, in `std::function` itself.
+
+To see how it all works, let's build a simplified version of `std::function` that only handles `void()` callables. We'll call it `MyFunction` because I have no imagination.
+
+The core idea is to use a templated class that inherits from a non-templated base class that uses [virtual functions](inheritance.md) to call the stored callable:
+
+<!-- 
+`CPP_SETUP_START`
+struct Noncopyable {
+  Noncopyable() = default;
+  Noncopyable(const Noncopyable&) = delete;
+  Noncopyable(Noncopyable&&) = delete;
+  Noncopyable& operator=(const Noncopyable&) = delete;
+  Noncopyable& operator=(Noncopyable&&) = delete;
+  ~Noncopyable() = default;
+};
+
+$PLACEHOLDER
+`CPP_SETUP_END`
+`CPP_COPY_SNIPPET` std_function/type_erasure.cpp
+`CPP_RUN_CMD` CWD:std_function c++ -std=c++17 type_erasure.cpp
+-->
+```cpp
+#include <iostream>
+#include <memory>
+
+class MyFunction {
+ public:
+  // Other constructors missing for brevity
+  template <typename T>
+  MyFunction(T&& callable)
+      : callable_{std::make_unique<CallableImpl<T>>(std::forward<T>(callable))} {}
+
+  void operator()() const { if (callable_) { callable_->Invoke(); } }
+
+ private:
+  // See Inheritance lecture for Noncopyable definition.
+  struct CallableBase : public Noncopyable {
+    virtual ~CallableBase() = default;
+    virtual void Invoke() const = 0;
+  };
+
+  template <typename T>
+  struct CallableImpl : public CallableBase {
+    explicit CallableImpl(T callable) : stored_callable{std::move(callable)} {}
+
+    void Invoke() const override { stored_callable(); }
+
+    T stored_callable;
+  };
+
+  std::unique_ptr<CallableBase> callable_{};
+};
+
+void FreeFunction() { std::cout << "Free function!\n"; }
+
+int main() {
+  const MyFunction func1{FreeFunction};
+  const MyFunction func2{[] { std::cout << "Lambda!\n"; }};
+
+  func1();
+  func2();
+}
+```
+
+Let's unpack what is happening here. The `MyFunction` class itself is *not* templated. The `callable_` pointer just points to some `CallableBase` that has a pure virtual `Invoke()` method. By the way, here we inherit from `Noncopyable` base class to make sure our `CallableBase` only has pointer / reference semantics, not value semantics, see the [inheritance lecture](inheritance.md#things-to-know-about-classes-with-virtual-methods) for more details.
+
+The exact type `T` is remembered *only* inside the templated `CallableImpl<T>` class, which is instantiated when the templated `MyFunction` constructor is called. The `CallableImpl` class overrides the virtual `Invoke()` method and actually calls the stored callable object.
+
+So now if we create a couple of `MyFunction` objects - one with a free function, one with a lambda - the call to `operator()` on either `MyFunction` object will call the `Invoke()` method on the `CallableBase` pointer, which through the vtable finds the actual `Invoke` method on the appropriate `CallableImpl` object, which then calls the stored callable object. 
+
+Same logic applies when `MyFunction` object is destroyed, its destructor will call the destructor of the `CallableBase`, which, having a virtual destructor, will call the destructor of `CallableImpl<T>` which will in turn call the destructor of the actual callable object it holds. This is how the underlying callable object can be called and safely cleaned up without any memory leaks and without `MyFunction` needing to know anything about the concrete type `T`. This is what type erasure is all about!
+
+And of course, if we run the code we get the printout that we expect!
+
+```
+Free function!
+Lambda!
+```
+
+Real `std::function` class is, of course, much more complex. It handles different return types and arguments, uses Small Object Optimization to avoid `std::unique_ptr` heap allocations when possible, and provides copy semantics. I won't go into these details here. But the underlying principle is exactly what we've just implemented!
+
+> ⚠️ Finally, it won't hurt to stress this again: you'll probably never need to implement your own type-erased wrapper. But it's good to know how it works under the hood. Who knows, maybe it'll come up in a job interview (like it did for me some years ago, looking at you, Misha)!
+
+## Summary
+To sum up, `std::function` is a powerful tool when we need a generic, uniform way to store and pass around things that can be called. It is extremely versatile, allowing to use any callable object with the same interface.
+
+However, with great power comes great responsibility (and potential heap allocations) as well as a potential runtime overhead due to the use of a vtable. 
+
+So, as a rule of thumb, we should probably use `std::function` for callbacks, event handlers, and storing tasks, but stick to templates when we need maximum performance on hot paths, unless we measured otherwise.
+
+<!-- And that's it for now! Thanks a lot for watching and I'll catch you in the next video, bye! -->
diff --git a/readme.md b/readme.md
index 33a3e47..7c376ad 100644
--- a/readme.md
+++ b/readme.md
@@ -785,6 +785,23 @@ Headers with classes
 ----------------------------------------------------------
 </details>
 
+<details>
+<summary>Storing callables with <code>std::function</code></summary>
+
+----------------------------------------------------------
+[![Video thumbnail](https://img.youtube.com/vi/_qteFBrAKSM/maxresdefault.jpg)](https://youtu.be/_qteFBrAKSM)
+
+- [`std::function`](lectures/std_function.md#stdfunction)
+- [Overview](lectures/std_function.md#overview)
+- [The problem: storing callables](lectures/std_function.md#the-problem-storing-callables)
+- [Enter `std::function`](lectures/std_function.md#enter-stdfunction)
+- [Performance considerations](lectures/std_function.md#performance-considerations)
+- [Type erasure (how it works under the hood)](lectures/std_function.md#type-erasure-how-it-works-under-the-hood)
+- [Summary](lectures/std_function.md#summary)
+
+----------------------------------------------------------
+</details>
+
 ## PS
 
 ### Most of the code snippets are validated automatically