Welcome to Rust in Production, a podcast about companies who use Rust to shape the future of infrastructure. I'm Matthias Endler from corrode, and in our final episode for this season, we have Orhun Parmaksız from JetBrains to talk about building developer tools for Rust. Orhun, thanks so much for taking the time. I think a lot of people know you, but maybe you want to say a few words about yourself. Hello everyone i am orhun parmarxes i'm from turkey ankara recently moved to berlin and this journey is thanks to open source and i've been, people say that i'm a prolific open source rust maintainer i just say that i'm a rat and that's what i've been working on. ratatui, Rust, open source, some nerd stuff on the side, music, and that's me, basically. And before we get into JetBrains, what is ratatui? So, ratatui is an open source project that changed my life, basically. It's a terminal user interface library for Rust, and it is based on the tui-rs library that existed very long time ago, very early in the Rust ecosystem. Then me and a couple of other interested people, we forked it and we created a community around it. And I've been leading this project for three, four years now and I am very excited about terminals. So this is my main open source work and we have been seeing a lot of progression in this space, A lot of new tools, new experiments with ratatui. And these days it's hard to explain, but it's a thermal user interface library that has been ported to many environments, now runs on your bootloader, embedded on your coffee machine. It's a minimal UI library, let's put it that way. And of course, it's written in Rust. You're here today in Dusseldorf because we have been friends for a while And, yesterday we talked about meeting each other for the first time. That was at FrOSCon a couple of years ago. And that was thanks to you also building a lot of packages, including Lychee or lychee, as I call it, the link checker that I helped build as well. And yeah, I think to me, you represent open source. This is truly what I believe open source is about. So thanks for all your work up front but we are here today to talk about your new gig tell us a little bit about that. So before i dive into that let me talk about the packaging and how i actually got into this space because i actually got into open source open source without even realizing it i was just having fun on the internet and i got, i became part of Arch Linux team I adopted many Rust packages I started creating Rust packages and I packaged lychee some other projects and this gave me, this opportunity to connect with more people and that's how we connected back in the day I'm very grateful of that by the way and I've been just building, projects, communities experiments along the way. And some companies, some people realized my efforts and JetBrains was one of them. I've been seeing them a lot at Rust conferences. I have met people from JetBrains and in the last two years, I think, they have been everywhere in the Rust ecosystem. And basically we have connected, we have collaborated on some things. I also live stream and create content. So we did some collaborations together. And, you know, they had one open position and it was a perfect fit for me. This is a Rust developer advocate position. And I basically, became a part of this nice little team that is trying to represent Rust inside of JetBrains and also represent JetBrains in the Rust ecosystem. So I am now basically a bridge between the developers and also JetBrains. So my job is to just basically do what I was doing, basically advocating for Rust, but at a larger scale. So this is what I've been doing and this is why I moved to Berlin to expand my network, bring more people to Rust, be visible in more events, and also, of course, to open source and spread the name of Red Hat Tree, personally. JetBrains builds integrated development environments. Does that mean you got bored of text user interfaces? That's a very good question, and this is a question that I got asked multiple times. So I see it this way. I've been a part of the terminal UI and the NeoVim, like all this like terminal ecosystem for a while. And I was using NeoVim. I still use it actually. And now that I'm a part of a different side of the editor experience, which is graphical, more involved. More like designed for complex workflows. And I see this as a positive because RustRover is actually a great IDE. It's built for Rust developers. It has many features that is designed for them. And I am not personally being... Like required to use RustRover but since I am a part of JetBrains and RustRover is one of the IDEs and it's for Rust people, I think it makes sense for me to use it nowadays so that I can bring the feedback into RustRover and also see this other side of the table where how, more like how enterprise companies how like other people were not using terminal, using rust and i can just be active in in both, both worlds so i see this as a big positive and i actually liked RustRover like i have. Used it i think when we first collaborated with jetbrains more than a year ago, and now i use it every day and, i like it i've configured in the same way that i use neovim there's a plugin called ideavim and you can just port all of your existing nail vim key bindings, so i am not leaving the terminal that's not the case the terminal is my home and this is how i, get things done i'm just using another tool to develop these days so there's no difference for me it's it's just an editor and it's actually built for, rust people and yeah i'm trying to make it make it better, and improve this thing that is for the rest people so i think this is a this is a positive so yeah i see that there's a bit of a conflict but it's actually a good thing. Chat brains is historically very much rooted in the java ecosystem they even wrote their own java dialect if you will called kotlin does that mean, the IDE will always stay in the JVM environment, or is there a chance that you will integrate more Rust code in the future? So there are some Rust parts in the IntelliJ platform. We call it the platform, the base IDE, and the other IDEs are based on this. So this is a really mature Java and Kotlin code base, and it seems like it's going to stay a JVM-based thing for the foreseeable future. We experiment with new tools. We try to integrate Rust more when it makes sense. But for now, I think it's going to be a JVM-based thing. And for small things, such as some services maybe or some file system operations, Rust really makes sense because you need speed there. But like I said, this is the way for a long time and everything is based on the platform and it's not going to change in the future. Now, I'm personally a Zed user and one thing I noticed was that Zed boots up instantly, and when you open a file with a certain extension, then it starts analyzing the content. For example, if you open a Rust project, it doesn't immediately start. If you open the first file, then lazily it sort of builds up its index. And I think that's kind of a great... Approach because in the past when I worked with IntelliJ products the boot up time was a bit frustrating so I always wondered, okay when's the project done when is it loaded when can I use the IDE properly do you feel the same and are there ways on how to improve that. So I will speak behalf of RustRover because this is what I am focused on. And RustRover is actually designed for more complex use cases. So in the case that you're editing a single file, RustRover might not make sense. There is, of course, a mode called light edit, which you can just run. From the CLI and just edit a single file without loading all the plugins or all the indexing features you could use that, but RustRover itself is is something that comes out of the box with all the features that you need to do rust development, and that's why it is been it's a bit heavy and we are not, trying to compete with with like, light editors in this in this space we are trying to be as much as, as much productive as for for the rust developers themselves we have the the debugger we have the, the library support for the web web frameworks we have other rust specific features so, it comes with everything everything bundled and, this is this is why it feels a bit heavy and the startup time it has improved a lot because there's a lot of ongoing work on that in the platform side And there's actually, another Java runtime you're using in the platform side to make it better. So we are aware of these issues and we're trying to solve them. But like I said, the RustRover itself is for more of a... If you have a complex Rust project, RustRover is the great fit. And just for editing a single file, it might not make sense. There was a new IDE from JetBrains called Fleet, which is now deprecated, and it used a hybrid architecture. That means it was partially written in Rust. Do you know which parts were written in Rust and why Kotlin wasn't used there? So just for some context, Fleet was a lightweight, cloud and collaboration oriented experimental IDE, and it was announced in 2021. And now the Air is the agent-centric successor to Fleet. And Fleet used Rust in its file system daemon. This was the agent that lives next to your code spawns processes and does a bunch of, other like file system stuff so it really made sense to use Rust there because you need performance you need to fast, do some fast indexing for example you need to call some processes so that's why we picked Rust there, we had the small always running cross-platform service so we didn't really need a JVM We wanted to have less memory usage, less CPU usage. So yeah, this was the part of Fleet that used Rust. So Air is, like I said, it is the successor to Fleet. So it uses the same file system daemon. And that's where the Rust made sense for us. But the rest of the IDE is, again, based on the IntelliJ platform. The other thing I remember about Chatbrain's IDEs was that debugging was always a joy. You could really look at the data structures, and I really liked that part. So you could really go deep on this. But then I also know that Rust has the... MIR, this mid-level intermediate representation. How does RustRover hook into that ecosystem, if at all? How does that part work? Do you use that for debugging sessions in RustRover? Yeah, first off, RustRover right now is the best way to debug Rust programs, in my opinion. There isn't, I think, a better way of doing that. Because it is the same as we are used to for a long time. Before using Rust, I was using IntelliJ IDEA, for example, and just debugging Java applications. And I was really used to the debugger itself. Now I use Rust, and it is almost the same experience, and I am very used to it by default. So the experience is very intuitive and the way that we do debugging in RustRover is we use this, mid-level ir and maybe i could just talk about the life cycle of a rust code before i get more into the technical details so. Let's say you type something in the editor. First, we take that code and we turn that into a super detailed syntax tree. So every character comment, every code is being turned into this PSI, which is Program Structure Interface. Then we take that and we build a cleaned up, type checked version of your program, that matches how Rust understands the code. And this is called typed high-level intermediate representation. And after that, MIR comes, which is the mid-level intermediate representation. And that's where there's like small, simple steps and basic blocks. And this is where it's easy for the compiler and tools to analyze and transform. And that's that representation used in the debugger itself and then after that the machine code comes. So we build our own MIR inside the IDE and we use that in the debugger to interpret Rust expressions. So when you evaluate an expression or a function in a debug session we lower that to MIR and sends that to the debugger, and we execute that against the paused process state. So we can support things like macros or other code that wouldn't be directly available from the compiled binary alone. Of course, this comes with some trade-offs in complexity and edge cases since we use our custom intermediate representation. So if something goes wrong in the debugger we basically fall back to the classic, evaluate in the debugger mode so it has its own fallbacks but it, General overview is that we basically have this transformation in the Rust code. And since we have this custom way of doing things, we have the full control, in the debugger itself. And we can execute expressions. We can step over, step into, and do many things with the Rust code itself. So that's why it's very powerful. And you don't have to rely on any other debugger tooling for this. It's all done in the IDE itself. You don't need things like, for example, JDB or some other LLVM-powered thing. It's all done in there and that's why it makes it so powerful. The Rust-sender library is pretty stable for the most part. But what about Rust internals? It must be a nightmare to keep up with the changes in your own representation of the MIR. So we run some regression tests whenever, a new thing comes out and we have this, way of testing things we have a test suite and we basically make sure that things do not break and we have some automation when it comes to the regression tests. When it comes to Nightly's, for example, they usually break the parser inside of the IDE, and we have to make sure that there is no regressions between new versions. So we built a big parser regression suite over the Rust standard lib. And we specifically test against today's nightly so we see breakages as soon as they land. And whenever that happens, we get a notification on the CI and the on-duty person picks it up and adjust the grammar or extend the fixtures so we don't. Ship something that is broken. So the platform that we use for this is actually something custom and something that we have built with Rust. It's called Crate Rover and it runs almost on, every RustRover commit. So whenever we land a feature or a fix, we run some tests, some diagnostics on 60 real projects. And CrateRover aggregates those results and we highlight the false positives, and we get notifications. We also have a classic way of testing, which is called Crawler. And we use the same like diagnostics. Approach but the scroller periodically scans thousands of projects on an external linux machine and dumps everything on on a duck db, and we basically go ahead and mine the easy false positives and see like the global health, of our analysis so this is more like a less less automated but more like a manual approach, so that's what we use to make sure that nothing breaks And this is actually quite similar to what the Rust project itself, the Rust compiler itself is doing. There is a service called Crater, and this is the tool that rebuilds a lot of crates against new compilers to catch breakages. Inspired by this and built CrateRover. And we basically have this test regression suite that runs very frequently. We catch any regressions or bugs this way and we don't really ship anything broken. I like the name CrateRover because it's a fun play on CrateR and RustRover. Kudos to whoever came up with that one. Earlier you mentioned procedural macros. And these can be particularly gnarly to get right. And procedural macros are also very powerful because you can run pretty much any code on a user's machine. That means they can be a hazard. How do you sandbox those heavy, malicious procedural macros without freezing the IDE or without really troubling the user too much about it? Have you seen the pop-up box whenever you open a Rust project in RustRover ? Yeah, yeah. It asks for a confirmation because we don't trust projects by itself. You have to actually click trust project. And this notification box is actually very tied to this procedural macros question because we don't want to run any untrusted code as default. So based on your input to this notification box, we either run the macros or we don't run them. So they are untrusted by default. And they're also running in a separate helper process. And in this way, we... We catch panics or crashes. So they don't really affect the IDE itself, but it just crashes the process itself. So we run them off the UI thread with timeouts, size limits, and caching. So if macro is malicious or too slow or laggy, we basically cancel that and fall back to the no expansion, which is close to the untrusted mode. And so that the editor does not affect from it. Also, you're not affected from, the side effects of macros. We talked about the Rust MIR, the medium intermediate representation. But the other part of Rust's static analysis ecosystem is Rust Analyzer. And that's another huge project with a lot of contributors. There's a lot of, work that went into that project. Do you use that somehow or do you have an alternative to that in Chatbrain's products? There's a really good talk from our rust ecosystem leader vitaly and there's also a live stream from some time ago with, with someone from our team and also from rust analyzer team lucas from rust analyzer and, vlad from our team so they're like really good conversations happening in this space and we are actually trying to solve the same problem and we complement each other in some ways. But let's put it this way. So. We are solving problems in the same space, but we have different answers to those questions. So JetBrains program structure interface and Rust Analyzer's internals, they both keep a lot of stuff in memory. And that's why they can be quick in doing operations in, in terms of lsp features we just have like like i said different answers to those so, the the way that we handle things is different in the way that we organize them differently in the memory so rpsi, keeps one big shared picture of the whole project, whereas Rust Analyzer keeps lots of tiny cached, questions and answers. They are just in different ways and different ways of spanning the memory. Another difference is that our way of, handling things in terms of memory is good at doing refactors, renames, and cross-language changes because we have this big picture of the, layout of your Rust program, whereas Rust Analyzer is super fast for quick questions such as what is this type doing or what is the, the underlying thing behind this Rust object, and so on. So there are some differences, but they are just different tools that are solving, a similar, same problem, let's say. And JetBrains PSI is written in a JVM language. That means there's no chance to merge those efforts into a shared library at some point. If I understand you correctly, that's also not the goal because you're looking at the problem from a different angle. One is the global view, the other one is the local view. But I still wonder if there's any middle ground that both projects could profit from as part of a shared library, so to say. I think there are some parts that they're handling very similarly and we are, basically sharing those with each other and just trying to inspire each other to make things better. But I don't think there's an effort to merge things together and just have one shared way or like a common way of handling things. So Rust Analyzer's internals, which is called the Salsa framework or JetBrains PSI indexing, is just different approaches and we usually share those things with each other but there isn't a work going on to have a middle ground. We don't share code but we share a lot of ideas. But if you wanted to share code inside of jetbrains ide would you then use the classic jvm, jni ffi interface or would you keep them strict strictly separate sorry let me rephrase that, no i would just ask it just like it is here, do you run any rust code inside your classic jvm ide's via, the j via the java native interface or the foreign function interface or do you keep those parts strictly separate. So there's nothing that that runs rust so they are strictly separate because we have this intellij platform that is JVM and Kotlin, and we have some helper utilities, some external tools that we call, and those use Rust, but we don't actually have Rust code that is running inside the IDE. We talk to these processes via IPC, inter-process communication, so those Rust libraries are not loaded into JVM. This also helps us to avoid any crashes or panics when they happen and we don't, we don't crash the whole id basically we just, the process just crashes so that's also the benefit of that so we don't have any like rust code, running inside of the jvm runtime. You said that you have this global overview of everything that's going on in a rust project but, doesn't that consume a lot of memory? Do you really load all the objects into memory for indexing libraries or do you use stops? So we don't load everything. We just keep a skinny table of contents in memory. So we have name, signature, types, instead of the whole thing. So the library index is just a thin graph of their APIs rather than just having the whole AST in the memory. So we keep a lot of crates as known without using the memory, but we still have some kind of understanding of what, the library is doing, how to go to their function definitions, how to do code completion and refactors on their public APIs. So there's some optimizations that we do in order to keep the memory usage low as possible, but also keep the functionality as much as possible. A lot of your competitors are open source projects. We talked about that before. JetBrains is not, at least at its core. Do you still support the open source ecosystem? So JetBrains has always invested in open source. There's some examples of Kotlin and its ecosystem, intelj idea community edition many plugins are open source so we are actually, we are we keep supporting open source in any way that is possible and in the rust world as well we have RustRover is a commercial id it's for professional teams, but we actually give complementary all products pack licenses to open source, projects and individuals to support them and they can build, non-commercial open source applications and they can just use the ides for free also, many people in JetBrains they are active in open source themselves and the company gives them room. For example, me, I am usually in my free time and in some places. In some ways that I am contributing to open source rather to other projects that I maintain. And it's very welcome in JetBrains to do that because it's been seen as a part of my work. And this is an improvement in the Rust ecosystem, in the Rust tooling, and it's a contribution to the community so it's been supported in JetBrains. We also support the human side of the open source ecosystem as well with meetups and events so for example we just did a meetup in the berlin office two days ago, we try to bring many people together we try to create a network we try to learn, experiment and you know give people some way that they can represent themselves. And this is how we try to contribute to the ecosystem and open source ecosystem at scale. Supporting local communities is always great. Are there other ways you support the Rust ecosystem? So our primary objective is to bring more people to Rust. And sometimes it's a bit confusing in terms of what I'm doing is because I am a Rust developer advocate and it's been seen as I've been advocating for RustRover . But our main objective is to bring more people to Rust. So in order to do that, we ship JetBrains Academy plugin and in-ID Rust courses. So you can basically, use Rustlings and some other exercises inside of the IDE to learn and practice Rust. One of the courses that we ship is called 100 Exercises in Rust by Luca Palmieri from Mainmatter. So we try to bring more people to Rust by teaching them Rust in an easy, easy way. Now that's pretty cool. How deep does this 100 exercises in Rust integration go? Can I see the exercises I still need to do? I would say it's fully IDE native, so it's not just 10 layer of exercise runner. It shows up directly on the Rastrover welcome page in the learn tab, so you can just click on things and it installs the academic plugin. You can pick the course, you can start it in the same IDE window, and also it adds some additional UI elements such as the core structure, there's a progress tracking, some, inline hints and everything just happens in the normal IDE. So it is quite a nice way of using Rust and also learning Rust in one place. We recently had the Rust Foundation on the podcast and they announced the Rust commercial network. Is JetBrains already part of it? Yes, JetBrains is a part of it. And we have been collaborating with the members already. And I am also part of it as well as a maintainer of PradaTui. I haven't initiated anything yet, but it's good to always have contact with the Rust project to build commercial Rust tools and services. And it really helps to keep Rust sustainable and well supported in production. I had no idea that there was such a deep integration with the 100 exercises in Rust. But I know that there's a deep integration with the testing frameworks in Rust, in RustRover . Can you talk a little bit about that? Yeah, we have integrated Cargo Next Test, which is next generation test runner for Rust projects. It's quite fast and more modern. So we have integrated this tool inside of the IDE. And you can simply just switch to Cargo Next Test as a runner. And it takes all the stats and all the logs from it. So it's showing the output of Nexttest also as a part of the IDE itself. And it's way faster to run this way and also use it like I personally use it in my own open source development. Speaking of integration with other tools and libraries, maybe it's a good time to announce the new version of RustRover , which just shipped two days ago. It's called 2026.2. And in this release, we have new integration with the Axiom framework. So if you have a web project, if you have a Rust web project that is using the Axiom framework, the IDE just recognizes everything. Including the endpoints and the handler functions. So you can basically jump back and forth between the endpoints, the functions, the routes, and there's a dedicated UI for this as part of the IDE that shows all your endpoints. So let's say you have a really big Rust project that has hundreds of endpoints. You can basically browse them really quickly. You can explore them. You can see which HTTP method they use. And there are like inlay hints for each of these features. So you don't have to actually go and look for. What this method is using or like which function it's calling. One of the problems that I had in the past while using Web Frameworks in Rust was I had util functions that was just laying in some module. And if you don't look at the code for, let's say, two months, you just forget which function is being used for which endpoint. And now this problem is solved by this because there's a hint just on just above the function that shows which endpoint it's calling. And this is very useful. And on top of that, there's now request library support, request the HTTP client library for Rust with the W. So now when you click on one of the endpoints, you can generate example test code for those endpoints for using the request library. So let's say you have some endpoints as part of your Rust project and you have some HTTP client code. So this code can be easily generated from this window and can just copy paste and you can just have like a HTTP test methods easily for your Rust web application. My first JetBrains product was PHPStorm. And I was fascinated how much you can auto-generate with that IDE. Even 10 years ago. When someone knew what they were doing, they would be able to create very quick stops for endpoints and routers and so on. And we used Symfony back then for a project, and they were pretty heavy on dependency injection, and JetBrains really hooked into that system. So I envision a future where you can do the same with Rust, maybe building larger backend applications with the same automation. Of course, we have LLMs now, but that doesn't mean that creating stops is obsolete. There's still value in this because first off it's accurate it's always correct you you generate the code based on a model of your language and second is super fast, do you have any plans for larger refactoring tools for rust code in general, And I asked that because recently you had an interview with Andrew Kelly on the JetBrains podcast. And he specifically said that he would like to see more refactoring tools for SIG as well. So what's cooking? So it seems like everyone is trying to align themselves with the latest AI changes. And of course, JetBrains is trying to find its place while these things are happening. When it comes to rust side of things we have, some nice things cooking and we want to just get as many feedback as possible from the ecosystem to just see what is the best to build next, so maybe i could not reveal too much here but i could talk about what we have cooked in the last release because there are some really nice stuff that I think change, how we use Rust code and how we use these development environments. So one of the really nice additions that we had in the 2026.2 release was the macro tester. This is something that I haven't seen anywhere else before. And just to remind you, I was using NeoWim and I was using all the Rust plugins there. And I was using also some web tools to just generate Rust code and check Rust code. But this is, I think, very game changing. So we had already the macro expansion and cargo expand integration. You could generate... The Rust code from macros, but now there's an additional menu where you can see your macro and you can give some input and see the output real-time. So this makes it possible to debug your macros and just see for which input, you are getting the correct result and and for which input it's failing. Or let's say you have some macro which has different branches. So based on some conditions, you generate different code. You could also select that in this menu and you could basically just see the macro generation real time. And I think this is very useful because macros are painful to debug or painful to read. So now this menu just makes things very simple. And I think this is a really nice addition to the Rust development ecosystem. And as a part of that, we had many other UX improvements. Now you can basically copy the fully qualified paths for functions, which means that you can. When you copy some line from a Rust file, it gives you the module definition instead of just the line or things like that. We always had other things such as. Optimize imports, which does some cleanup for your import statements, this is now quite improved. We have now some other like inlay completion related improvements. So we are actively monitoring the Rust developers to see what they are using and what they need. And based on that, we try to adjust what we're going to build next. And each time, it's always, I think, something useful and something that we need. For example, this macro tester feature was something that I needed, and now we have it. So the feedback from the Rust ecosystem is something that we consider all the time. That import optimizer is a feature i wished for in rust analyzer for a long time and it's still in the making there's still an open issue, so i'm glad to hear that it's integrated into RustRover with all of that what makes RustRover the best platform for writing rust code today. I think it's best for serious rust projects, big-scale projects rather than best for everything because the idea itself, it comes out of the box. It builds a deep understanding of your whole codebase with all the lifetimes, macros, traits, and tests. And it's built on top of IntelliJ platform, which has been battle-tested for many years. So you get industrial-grade refactoring tools. Really nice navigation between files functions modules an awesome debugger and test, coverage tools you know i'm not even talking about the git integration and also the database explorer so everything is in one place and, it's exactly what you want if you're working on a large long-lived Rust projects rather than just editing a few files. What I like the most about RustRover is that the setup part just works. You just install it, you can start using it instantly, and everything works. So I have installed it on two of my machines. First, the personal one, and then I configured it and I installed it on my work laptop and both of them now work in the same way and some people are usually, a bit lost on the setup in terms of the key bindings and so on and, Rust Rovers. Actually can be used very keyboard-oriented. If you use the IDEA Vim plugin, you can just spawn up a codec session and then say, just port my NeoVim config to RustRover . And for me, it just worked. So now I just use it in the same way that I use NeoVim. And that's why it's like out of the box. It just works and it's the best for serious RAS projects. You do so much. How do you split up? You do so much. How do you divide your time between your work projects and your personal projects like ratatui? I try to do other things every once in a while. I work out quite often. We actually did a workout together with Matthias today. Yeah, yeah. That was quite fun. So this is one of the things that I try to do. And ever since I moved to Berlin, I don't really have much time other than doing a workout and working. The live streams are usually also good. I try to play Minecraft and just sometimes chat with people. But go to the gym. Everyone listening to this episode, go to the gym, for sure. What does the gym and Rust development have in common? The plates are rusty. You work close to the metal? Close to the metal. It's embedded systems. When will you launch your Rust-based workout app? We are working on that. just two weeks ago i had a workout session on a live stream with one of the rust people swen shout out to swen from cargo generate, no we are not actually working on that but i want to make it happen i want to actually do more rust and workout, related content one of the ideas is to just interview people in the gym like the rust maintainers so, i'm trying to find the the common i'm trying to find some clash between those two it's it's not easy other than the plates are rusty i guess. Yeah i wonder what the intersection of rust developers and people go to the gym is but we will see. We will see. One thing that's fascinating about you other than your rust work is how you can build communities and bring these people together, How do you do that? I think people just see the crazy stuff that I do on the internet and I try to bring them together through some platforms. The main one that I have is Grindhouse, which is, it was supposed to be a joke, but it turned into a reality. It's now a real community. We have really talented Rust people there, also other people from other backgrounds. And it's just because I've been trying to keep myself visible and just share most of my steps. I have a blog, I have social media, so I post what I'm doing and as a part of that, I am also sharing that I have this Discord server. So people just come there and I met a lot of friends there. Some of them actually now work together. So I am quite happy with what we're doing there and. As a part of my other community work now i am organizing a podcast about terminals so it's called terminal tuesdays and is part of our terminal collective discord server so i'm trying to like interview people about their terminal setups so i just like talking to people and just you know get, get some insights about what they are doing and also collaborate with them on on projects not just talk but share ideas share code, i have recently released a 3d terminal emulator called ratty and the the foundation of that terminal emulator was actually built by one of my friends that, that has been active on the discord server and he basically built that because we've been just talking and we've been saying hey would it be nice to have this and So this way we collaborate, in terms of code, ideas, and just have fun. What's your message to the rust community. Rust is a growing language and if you want to be ahead of the curve write rust it's now the perfect time, you're not going to be late but we need more people we need more interested people we need more cracked people So the common problem with open source is that there isn't, enough people to do the work. So if you're interested in compilers, tooling, terminal UIs, embedded, we need you. You can start small. Don't be afraid to contribute. Don't be afraid to talk to people. And you will find your place in this community. we are very welcoming and I guess keep grinding, keep building stuff thank you so much it's been a pleasure. Rust in Production is a podcast by corrode it is hosted by me, Matthias Endler and produced by Simon Brüggen for show notes, transcripts and to learn more about how we can help your company make the most of Rust visit corrode.dev. Thanks for listening to Rust in Production.