29 slides extracted.
Slide 1 — 0:32 (watch)
 | My name is Daniel Szoke, and I am the Rust SDK maintainer at Sentry. I want to explain why I believe Rust is the ideal language for vibe coding. Conventional wisdom suggests that Rust is not typically one of the first languages considered for agentic coding, or vibe coding, as some call it. When I asked ChatGPT about the best language for agentic coding, it indicated that there is no single top language, but that Python is likely the leading choice, followed by a strong contender. It mentioned JavaScript and TypeScript as well. |
Slide 2 — 1:22 (watch)
 | In my experience, this observation is largely accurate, although I would reverse the order. TypeScript has emerged as the top choice for agentic coding recently. |
Slide 3 — 1:44 (watch)
 | An article from GitHub, released late last year, indicates that AI has propelled TypeScript to the top language on GitHub based on contributor counts. They confirm that TypeScript is the number one language and strongly suspect this is due to its use in AI-assisted development. |
Slide 4 — 2:02 (watch)
 | Python, TypeScript, and JavaScript are considered ideal for vibe coding based on conventional wisdom for several reasons. First, they are common and familiar languages, often the first ones learned by beginners in programming. They are easy for humans to understand and also appear to be straightforward for LLMs. |
Slide 5 — 2:42 (watch)
 | There are many frameworks, libraries, and examples available, which is beneficial when building something new from scratch. This abundance of resources aids both humans and agents. These languages allow for quick scaffolding and execution. JavaScript and Python are dynamic and interpreted languages, while TypeScript involves some light compilation to JavaScript, making it easy to run code and see results quickly, facilitating iteration. For agents, strong typing support helps prevent type misuse, although TypeScript and typed Python can introduce some complexity. Overall, these languages are simple, enabling LLMs to generate runnable code effectively on the first attempt. |
Slide 6 — 3:58 (watch)
 | The simplicity and few constraints of languages like JavaScript, Python, and TypeScript make them appealing for LLMs to write. However, I believe that many people overlook whether optimizing for this ease of use is truly beneficial. While these classic vibe coding languages are easy for models to generate, this may not be a positive attribute. In fact, I argue that the ease with which models can write these languages is often overstated and can even be detrimental. The dynamic and flexible nature of these languages facilitates writing by LLMs, but this same flexibility increases the likelihood of making mistakes, both obvious and subtle. |
Slide 7 — 4:36 (watch)
 | Adding typing is a helpful constraint, but it has limitations. While it provides some type safety, this safety is not very strong in TypeScript or Python. |
Slide 8 — 5:22 (watch)
 | LLMs are inherently fallible due to their design as non-deterministic systems. While we hope they will improve and make fewer mistakes in the future, it is unlikely that errors will ever be completely eliminated. Just as we need to guard against human error, we must also guard against errors from LLMs. A common approach to mitigate this risk, particularly in traditional vibe coding languages, is to add tests. While this is beneficial, relying solely on tests and code review agents presents several challenges. |
Slide 9 — 6:26 (watch)
 | Firstly, if you don't prompt the agent skillfully, it will often write tests after the implementation, resulting in tests that focus on implementation details rather than properly testing behavior. Even with test-driven development, tests can only demonstrate incorrectness when they fail, as it is impractical to test every possible input combination. In many cases, you cannot prove that every input produces the correct output. Additionally, if LLMs generate the tests, they may make mistakes in writing them, and the same issue applies to code review agents. |
Slide 10 — 7:20 (watch)
 | On a philosophical level, while we all know AI stands for artificial intelligence, I recently read a book called "Nexus" by Yuval Noah Harari, a historian with a unique perspective on the topic. He discusses the evolution of human information from the Stone Age to the printing press, the internet, and now LLMs. Harari argues that LLMs are unique because they represent the first instance of a non-human entity capable of producing human language. A key point he makes is his discomfort with the term "artificial" in AI, as it downplays the significant differences between LLMs and human thought processes. He prefers to refer to it as "alien intelligence," emphasizing that the internal workings of these systems differ fundamentally from human cognition. |
Slide 11 — 8:14 (watch)
 | LLMs predict tokens in streams, which is a powerful mechanism, but it differs from human thinking. This difference can lead to unexpected failure modes. If you've coded with AI, you may have encountered situations where the generated code appeared well-structured, with sensible variable names and good comments. However, upon closer inspection, you might find subtle bugs or reliance on heuristics when a more reliable check could have been performed. It's essential to exercise caution with LLM and agent-based development. |
Slide 12 — 8:58 (watch)
 | This brings me to Murphy's Law, which states that anything that can go wrong will eventually go wrong. When using a language without deterministic guardrails, even with human review, agentic review, and a solid testing process, the absence of a reliable deterministic safeguard will lead to failures over time. Languages like JavaScript, Python, and TypeScript often lack these guardrails, resulting in more frequent failures. In contrast, Rust is a language that incorporates many constraints to help prevent such issues. |
Slide 13 — 9:52 (watch)
 | For those unfamiliar with Rust, it is a compiled language designed with safety and performance in mind. It aims to match the speed of C and C++, while ensuring memory safety and type safety. Rust's compiler is strict; if your code compiles, you can be reasonably confident that many types of bugs are absent. |
Slide 14 — 10:32 (watch)
 | The compiler enforces invariants such as type safety, memory safety, and concurrency. Although Rust may seem advanced to those unfamiliar with it, the language is designed to be beginner-friendly. The compiler provides detailed error messages that explain what went wrong and how to resolve the issue, offering valuable context. This feature is particularly beneficial when AI agents compile Rust code, encounter errors, and need to correct them. |
Slide 15 — 11:02 (watch)
 | Rust provides numerous safety guarantees. The first notable aspect is strict type safety; you cannot bypass it using any type or unchecked casts. Another significant feature is null safety, especially for those coming from other languages. |
Slide 16 — 11:34 (watch)
 | There is no universal null value in Rust. To represent a type that can be empty, you must define it explicitly as an option type. The compiler enforces that you always check for the presence of a value before accessing the inner value. Additionally, Rust offers fearless concurrency, which means the compiler checks that any shared data between threads is handled in a thread-safe manner. This is just a small list of the many features that the Rust compiler enforces. |
Slide 17 — 12:04 (watch)
 | I want to provide a quick example of fearless concurrency, as I believe it's very powerful. Here’s a simple code example. |
Slide 18 — 12:40 (watch)
 | We have a counter that starts at zero, and we will create 100 threads. Each thread will increment the counter by one. Once all threads finish, we expect the counter to equal 100. However, the types used here are designed for sharing mutable data only within a single thread and are not synchronized for multi-threaded safe access. In a language like TypeScript, this code might compile and run, but you would only notice the issue when the counter occasionally returns a value other than 100. |
Slide 19 — 13:14 (watch)
 | If this is a small part of a larger application, it can be very difficult to debug where the data race is occurring. However, in Rust, this code simply does not compile. |
Slide 20 — 13:44 (watch)
 | You will receive a compile error stating that the future cannot be sent between threads safely. This means that the async block is not marked as `Send`, which indicates that it is not safe to transfer between threads. While the initial error message may not be very informative, scrolling down will provide more details. This information will be particularly useful for your AI agent, as it specifies that the captured counter value is not `Send` and has the type `Rc<RefCell<i32>>`, which is not thread-safe. |
Slide 21 — 14:16 (watch)
 | If your AI agent compiles your project and encounters this compiler error, it can immediately change the type to a thread-safe type, of which there are many in Rust. |
Slide 22 — 14:32 (watch)
 | All these constraints come with a tradeoff. Rust is harder for LLMs to get right on the first try due to the numerous rules they must follow. However, I believe this is beneficial. |
Slide 23 — 14:48 (watch)
 | It's important to note that LLMs are not the only entities that write code. We integrate LLMs into AI agents that operate in a loop, allowing them to perform tasks autonomously. AI agents are particularly adept at compiling their code, identifying any failures, and correcting them. |
Slide 24 — 15:04 (watch)
 | Every compile error is a potential bug that you can avoid in your production code. Some people complain that Rust's compile times are slow. |
Slide 25 — 15:18 (watch)
 | However, I guarantee that it's faster than having an AI agent review your code, which may not catch all the errors that the Rust compiler is guaranteed to identify. |
Slide 26 — 15:30 (watch)
 | I still believe you should use it, as it provides an additional element of safety. |
Slide 27 — 15:38 (watch)
 | This is a sponsored talk, and I represent Sentry, so this is our marketing slide. |
Slide 28 — 15:50 (watch)
 | You should try us out if you haven't already. This QR code provides three months of free access to our business plan. We offer agent monitoring features, and we have a booth downstairs. |
Slide 29 — 16:02 (watch)
 | Please come by and feel free to ask questions about Sentry. If you would like to discuss the talk, I'm also happy to chat. Thank you. |