Why Rust is the Ideal Language for Vibe-Coding — Daniel Szoke, Sentry

My name is Daniel Szoke. I'm, uh, the Rust SDK maintainer at Sentry, and I want to tell you why I think Rust is the ideal language for Vibe-Coding. So, the conventional wisdom on what language to use for agentic coding, or Vibe-Coding, however you refer to it, um, it's—Rust is probably not one of the first things you think of.

You know, maybe you think, you know, probably ChatGPT has a good idea what's the best agentic coding language, given that it's also an agent of some sort. And it would tell you that there's no single number-one language, but that Python is probably the top language.

And as a strong number two, it said JavaScript and TypeScript when I asked it. And I think that this is, in at least my experience, pretty true, although I would flip the order because

TypeScript seems to have come out as, like, the top choice for agentic coding lately. And so there's even this article from GitHub that came out, I guess, late last year, and it says that AI—like, they think that AI has pushed TypeScript to the number-one language on GitHub, by contributor counts at least.

So they know it's TypeScript as the number-one language, and they strongly suspect that that's because of people using it for AI-assisted development. But why are these languages—Python, TypeScript, JavaScript—so ideal for Vibe-Coding, at least in this sort of conventional wisdom?

So, first of all, they're common and familiar languages.

So they're usually the languages you would learn if you were learning programming from scratch. So they're easy for humans, and they also seem to be easy for LLMs. There's also a lot of frameworks, libraries, and examples out there.

So that's helpful if you're building something new from scratch, of course, that you can build it on top of something. And, you know, it's helpful for humans; it's also helpful for agents. They're fast to scaffold and run. They're dynamic languages.

They're interpreted—at least JavaScript and Python are—TypeScript, maybe there's some light compilation down to JavaScript or something. But it's pretty easy just to run it and see what it does, and then you iterate on that. And particularly for agents, the typing support is helpful so that the agent doesn't misuse types.

But, yeah, there's the any type that kind of undermines that a little bit in TypeScript and typed Python. But, you know, overall, these languages, LLMs, the models themselves are pretty good at outputting runable code in the first try because these languages are simple and they impose few constraints.

So I think because of this fact that LLMs just seem to be good at writing them, people jump to these languages. But I think something that a lot of people, in my experience, don't question as much is whether this is even something we want to optimize for,right?

The classic Vibe-Coding languages are easy for the models to write, but is that even a good thing? My argument is that the importance of it being easy for the model to write the language is overstated. And in fact, I would even say that in some cases it's a bad thing that these languages are easy for the models to write.

The dynamic and flexible nature of the languages is what makes it easy for the agent, or for the LLM, I should say, to write JavaScript, Python, TypeScript.

But this same flexibility also makes it very easy to make mistakes, sometimes even obvious mistakes, sometimes less obvious mistakes. Adding typing is a helpful constraint, but that only gets you so far because it only gives you the type safety, and also it's not a very strong type safety in TypeScript or Python.

And this is, of course, a problem because LLMs are fallible. They will always be fallible because they are by design non-deterministic systems. So hopefully in the future they get better at making mistakes less often, but I don't think this is something that would ever disappear entirely.

And so just like the smartest humans make mistakes and we need to guard against human error, we're also going to need to guard against LLM error. One way that folks often would do that, especially also in the conventional Vibe-Coding languages, is adding tests.

This is a huge help, but there are a lot of problems with only relying on having tests and code review agents.

Firstly, you know, if you don't prompt the agent skillfully, it'll often write the tests after the implementation, and then you just end up testing implementation details without actually testing the behavior properly. Even with that test-driven development, though, tests usually can only prove incorrectness when they fail because it's impractical to test every single possible input combination.

You can't prove that every input produces the correct output in a lot of cases. And then, of course, if LLMs are the ones generating the tests, they may make mistakes when writing those tests, and the same thing applies to coding review agents.

And then kind of more on a philosophical level,right? We all know AI stands for artificial intelligence, but there's this book called Nexus I recently read, and I can highly recommend it to anyone who hasn't read it yet. It's from an author, Yuval Noah Harari.

He's a historian, and he has kind of a unique perspective on artificial intelligence. So he's discussing human information networks all the way from Stone Ages to printing press to internet to now with LLMs,right? And he thinks LLMs are really unique because it's the first time we have something that's non-human that's able to produce human language.

And a point he makes that really stuck with me is that he doesn't like that the A in AI is artificial because it understates how different LLMs and other AI technologies are from how humans think. And he actually likes to call it alien intelligence instead,

because the internal workings of how they think at a low level is different from how we think. LLMs predict tokens that come in streams, and it's a very powerful mechanism of thinking, but it's not how we think. And my point here is that the failure modes might be totally unexpected to us.

And I'm sure if you've done any coding with AI, you might have had a situation where you got code that looked really nice. It might have had sensible variable names, good comments, and whatever. But when you take a look, something might not beright.

Like, there might be a subtle bug, or maybe it's relying on some heuristic when you could check the actual thing and more reliably and more easily in some cases. So you really need to be careful with this, with LLM and agentic-based development,right?

And then that brings me to Murphy's Law, which basically states that anything that can go wrong will go wrong eventually at some point,right? So if you are using a language without deterministic guardrails, even if you apply human review, agentic review, test, a good testing process, if you don't have something that is an absolute deterministic guard against this, eventually you're going to have some failures.

And in these languages like JavaScript, Python, TypeScript, where you lack these guardrails a lot of the times, you're going to have failures more often,right?

And this brings me to Rust, which is a language with many constraints. And so for those of you who don't know anything about Rust or don't know that much about it, some basic background: it's a compiled language. It's designed with safety and performance in mind.

It wants to be as fast as C and C++, but it wants to be memory-safe, type-safe, and basically wants to be such, like, it wants to have such a strict compiler that if the code compiles, you can be reasonably confident that a lot of different types of bugs are not present in your code.

And that happens because the compiler is enforcing invariants like type safety, memory safety, concurrency, etc.

And the language tries to be very beginner-friendly. So Rust itself, I think people who haven't encountered it would kind of have the perception that it's very advanced, but they try to make the language easy to learn. The compiler errors give you a lot of information on what went wrong and how to fix the problem.

And so they provide a lot of context. And of course, this is really helpful when AI agents compile Rust code, hit an error, and then need to fix it.

So as I mentioned, there's a lot of safety guarantees in Rust,right? First one worth mentioning is that the type safety is strict. You can't bypass it with some any type or an unchecked cast. Null safety is another big one if you've come from other languages.

There's no universal null value. If you want to have an option that, or a type that can be empty, you need to define it explicitly as an option type, and the compiler will force you to always check that the value is there before you access the inner value.

And fearless concurrency, which is, I think, really powerful, and it basically means that the Rust compiler will check if you have any multi-threaded code, that any data shared between the threads is done, that that's all done in a thread-safe way.

And this is really just a small list. There's so many more things that the Rust compiler enforces. But I just want to give you all a quick example on fearless concurrency because I think it's really powerful. So here's a little code example.

Basically, we have a counter here, which is going to start with a value of 0, and we're going to create 100 threads here. And each time we're going to take the counter and add 1 to this inner value.

So once all these threads finish, you would expect this to have a value of 100. Now there's a problem here, which is that

these types here, they're designed for sharing mutable data, but only within a single thread. They're not synchronized for multi-threaded safe access. So in a language like TypeScript, something like this might compile, it might run, and then you would only notice the problem when every once in a while you would get a value other than 100 out of this,right?

And it might be, especially if this is a small part in a bigger application, it could be very difficult to debug where this data race is occurring. But in Rust, this just doesn't compile. You're going to get a compile error, and it will say, "Error: future cannot be sent between threads safely."

This future, so this little async block in here, is not send. And all send means is safe to be sent between threads, and it's not. So this error isn't that helpful, but if you scroll down in the error message, it'll explain further.

And this is what's going to be really helpful to your AI agent because it says, "Oh, the value here, this counter value that was captured, it's not send. It has type rcrefcell i32, and that's not send." And so if your AI agent, when it just compiles your project, it'll get this compiler error, and it can immediately go and change this to a thread-safe type, of which there's plenty in Rust.

So of course, all these constraints come with a trade-off. Rust is harder for LLMs to getright on the first try because there's so many rules they need to follow. But I think this is a good thing.

That's because it's not just LLMs that write code. We put the LLM in an AI agent. It's in a loop. It can do things autonomously. And AI agents are very well-suited to be able to compile their code, check any failures, and then go and fix them.

And every compile error is potentially a bug that you avoid in your production code. And

with the Rust compiler, like something I hear sometimes people complain that compile times are slow, but I guarantee you that it's faster than letting an AI agent review your code. And it might not even find all the errors that the Rust compiler is guaranteed to find.

I still think you should use it, of course, but it's good to have this additional element of safety, I guess. And of course, this is a sponsored talk, and I'm from Sentry, so this is the little marketing slide.

You should try us out if you don't already. This QR code would give you three months for free of our business plan. We have agent monitoring features. We have a booth downstairs. Come by. Feel free to ask questions about Sentry, or if you want to talk to me about the talk, you can also come by, and I'm happy to chat.

Thank you.