Why I'm so bullish about Rust in 2026

Back in 2024, I decided to give myself a challenge. This challenge was to use a single programming language as much as possible for an entire year. The idea behind this was to push myself to try new ways of working whilst at the same time reducing tech stack decision fatigue for any new projects. That single language that I decided to use was Go. And it ended up being a really worthwhile experience, pushing me to use technologies I wouldn't normally have used and to solve problems in ways I wouldn't have normally done. Whilst I didn't end up sticking with every technological decision that I made when it came to using Go, it did give me a much broader perspective and appreciation for many of the projects that I had built throughout 2025 and beyond. One such project is my new video editor application called Kiru, which fun fact means to cut in Japanese. Kiru is an application that's available on major platforms such as the web, Mac OS, Linux, and Windows, and is probably the most challenging and ambitious project I've built to date. I'll talk more about the underlying architecture and challenges of building Kuro in another video. However, the one thing I want to talk about in this one is the language that I used to build the majority of the project, Rust. Now, me and Rust have been on a bit of a hiatus. However, since now using it pretty much full-time for the past month or so, me and my once favorite language are now definitely back together. In fact, not only am I now committed to using Rust full-time, but I'm incredibly bullish on the language. So much so that I think it's going to be my main language of choice for the foreseeable future, especially given where the language now sits in the modern era of software development and some of the key reasons I think it's poised to become extremely important in the notsodistant future. So in this video, I'm going to go through some of my reasons as to why I'm so bullish on Rust, as well as why I'm so excited to be using it once again. The first reason on this list is one that I have quite a bit of recent experience with. Uh desktop applications, which in Rust are starting to get quite good. A few years ago, it used to be the case that if you wanted to build a desktop application using Rust, you would either need to use bindings to a C or C++ framework such as either QT or GTK or use a framework like Tori, which allows you to have a Rust backends with a web frontend. Now however in 2026 we have quite a few different Rust native options such as ICE GPUi egeuey and even Dioxysus who recently released their native Rust renderer in the middle of 2025. I'll do a video talking about all of these options in more detail in the future. But basically when it comes to Rust desktop applications we're now in quite a promising place for stutters. One of the nice things about having so many options is that you can now choose between different guey paradigms such as declarative Elmike, which is what I provides, retained mode, which is the case with GPUi, or immediate mode, as is the case with egeey. Not only do we now have multiple paradigms when it comes to Rust, but we also have access to low-level GPU primitives through the WGPU crate, which has quickly become the most ergonomic way to do low-levels graphics programming in 2026. WGPU is a modern crossplatform GPU abstraction that lets you write one renderer in Rust and run it across Metal, Vulcan, and Direct X without being constrained to a game engine or UI framework. In my case, I've been using WGPU quite a lot when it comes to my video editor application in order to render video frames to a WGPU service that's then presented by my UI framework. This is one of the major benefits of WGPU as it allows you to use custom GPU shaders with frameworks like ICE, Dioxysus Native, and even euey. Basically, any of the major frameworks you might want to use. All of this to me points to strong confidence in the ever growing maturity of Rust on the desktop. Although this wasn't the only signal as there was another huge development that occurred in 2025 which was the v1 release of the cosmic desktop environment. Cosmic is a full desktop environment written in Rust created by the team at system 76 and is something I've been trying out now for the past few weeks. Yes, not only is my own desktop app built using Rust, but so is my entire desktop environment, which is really cool. All of this to me makes the future of Rust on the desktop look very promising. However, it's not all rainbows and sunshine, and there have been a couple of setbacks going into this year. For starters, Tori is becoming less and less desirable due to the ever growing divergence between native WebKits and Chromium. Additionally, the team behind GPUi, who also happened to be the team behind Zed, announced they were no longer adding features to the framework that didn't align to the road map for the Z text editor. Despite these setbacks, I'm still incredibly bullish when it comes to Rust on the desktop, especially considering its fantastic cross-platform support, which means you can write your code once and effectively run your application on any of the three major operating systems without needing to dig into their own native frameworks. This is one of the main reasons why Electron right now is king. And so the fact that Rust supports this is a really big deal when it comes to writing applications for the desktop, especially when you couple it with that blazing fast Rust performance. Speaking of Electron, there is another major reason as to why people use it over typical native frameworks in that you can easily deploy these applications to the web as well. However, as it turns out, this is something that Rust can do as well. Now, one thing that web applications have over desktop applications is ease of distribution. There's nothing that compares to how easy it is to deploy to the web, which makes it a fantastic place to ship fast and ship often. This unfortunately creates a bit of a problem when it comes to working with Rust, as the web is mainly dominated by JavaScript. But just because it's dominated doesn't mean it's exclusive. And in fact, we're starting to see Rust become more and more capable when it comes to building web applications. For starters, we now have a number of different Rust web frameworks, including those for single page applications such as U or those for more full stack solutions such as Lepttos. In addition to these, we also have a couple of desktop frameworks that I already mentioned that can also publish to the web as well. These include ICE which has a web assembly mode uh basically rendering the display to a canvas and dioxysis which goes a step further and actually exports to the DOM. This creates a lot of potential when it comes to Rust web development especially with Dioxis which I think is going to be a very compelling option in the future for anybody wanting to create full applications using Rust. Now, whilst the ability to create web applications using Rust has been around now for a little while, there's one specific reason as to why I'm so bullish for it in 2026. This is because of the rollout of memory 64, which was a modification to the Wom specification to support 64-bit memory addresses, meaning you can now build applications that use more than 4 gigs of memory. Whilst not every application needs this much, some certainly do. And therefore by removing this limitation it makes rust on the web far more appealing. Right now memory 64 is available on the latest versions of Chrome, Firefox and Opera I believe. So whilst it doesn't have unanimous support, it's certainly a large market share. Despite this great news, Rust on the web still is far from perfect with the most major issue being that the ecosystem is far less mature than what you would get using something like React or vanilla JavaScript. Additionally, whilst you can interact with JavaScript frameworks and web APIs using the JS cyis or web crates respectively, it's certainly not the best experience and in fact can be quite hostile to actually use. Fortunately, this isn't the only way to use Rust on the web. And in fact, I've been using a different approach that gives me the best of both worlds through the use of web assembly. In my video editor, I have quite a lot of complex logic around enabling and disabling cuts based on word and paragraph timings. Rather than reimplementing this logic both in the desktop version in Rust and on the web version using TypeScript, I instead decided to create a single module that I could share between the two, which is fortunately possible thanks to web assembly or WOM. This means I can effectively implement this code once using Rust which provides me type safety and ensures I have a decent test framework and then reuse this module across both projects knowing that the behavior will be exactly the same. Whilst there is a bit of a performance tax incurred when it comes to moving data across the JavaScript web assembly boundary, it's one that I'm actually happy to pay, especially when it comes to ensuring code correctness. In fact, in some situations, this cost might actually be offset, especially if you're doing anything CPU inensive, as WOM often provides better performance when compared to JavaScript. That being said, there are cases when using web APIs are going to be preferred, especially when it comes to things like webcu. Basically, anything that makes use of a systems hardware. Speaking of hardware, that leads on to the next reason as to why I'm so bullish when it comes to Rust, especially for 2026 memory usage. Unless you've been living under a rock this year, then you'll know that the price of RAM modules has become kind of ridiculous. So much so that Apple is now considered an affordable option in the space. I really did not have that on my 2026 bingo card. Unfortunately, this RAM issue isn't looking like it's going to be a temporary problem. And in fact, there's a good chance it's going to get worse. Now, as software developers, part of our jobs, in my opinion, is to be prepared for any future known problems. And the rising cost of memory is one such problem that I can see exploding. Right now, it's mainly affecting desktop PC builds. But soon, I imagine it's also going to affect application deployment infrastructure, and I'm sure we'll see the price of memory usage on hosting providers starting to go up as well. Speaking of which, if you're worried about the price of memory going up, especially when it comes to using, say, a VPS, then you may be interested in the sponsor of today's video, Hostinger. When it comes to deploying web applications or self-hosting my own services on the internet, my preference is to use a VPS. Whilst there are a lot of VPS providers out there, the one that I've been using now for over a year and a half is Hostinger, and it's been pretty great. For starters, the instances that they provide specialize in providing high amounts of memory, which makes them perfect for running multiple services on the same machine. In my case, the instance size that I like to use is the KVM2, which comes with two vCPUs and 8 gigs of RAM, meaning there's plenty of memory to host all of the services that I like to run, whether it's traditional self-hosted applications or newer ones like Open Claw. Of course, as I mentioned before, the price of memory has started to go up. However, fortunately with Hostinger, you can get the KVM2 for the low cost of only $6.99 a month when you purchase a 24month term. If that wasn't good enough, however, by using my coupon code dreams of code when you check out, you can also save an additional 10% off this already low price, which makes it a really compelling option for hosting in 2026. So, to get your own high memory VPS locked in for 2 years at an incredibly affordable price, then make sure to visit hostinger.com/dreams a code or use the link in the description down below. And make sure to use my coupon code dreams of code when checking out to get an additional 10% off. A big thank you to Hostinger for sponsoring this video. Okay, so back to memory usage and why I'm so bullish for Rust. Well, as I mentioned before, memory usage is going to likely cost more in the future, which means in order to save costs on infrastructure and application deployment, then it's only going to be a safe bet to consider using a more memory efficient language such as Rust. To show loosely how efficient it is, here I have two simple APIs set up. One written in Rust using Axom and the other being TypeScript with bun/ elicia. If I go ahead and call the stats endpoint on each, you can see that the Rust API consumes about 3 MGB of memory uh compared to the bun one which consumes almost 80. That's just short of being 30 times more. Whilst this isn't a huge amount in absolute terms in either case, it still is an order of magnitude relatively. And if you happen to have a lot of services deployed, then this can start to add up. Speaking of memory usage, if you happen to follow me on Twitter/X, then you'll know that I recently ran into an issue where a certain TUI application began eating all of my available system memory. Now, I'm not meaning to throw shade at the TUI application in question. Uh, but it is part of a current trend that we're seeing of TUI or CLI applications having incredibly poor performance, especially those written in languages like TypeScript and in some cases also using React. Whilst there is a case to be made that this allows companies to ship fast, as an enduser, it's kind of annoying to watch my SSD slowly die in real time or my terminal emulator doing its best impression of a strobe light. Additionally, I'm not the only one who feels this way, and I think in 2026, we'll start to see a reckoning where tools that prioritize a systems resources are going to be preferred over those that just ship fast. This makes it the perfect environment for us to start seeing more rust based tuities emerge in the future. In fact, a recent example has been the codeex CLI which is written in Rust and has been praised for its performance. As for how to build TUI applications using Rust, well, this is something I plan to explore more on in 2026. Uh, specifically looking at a framework called Ratatouille, which besides having another fantastic name is really great to use. For example, here is a simple Vim clone that I built using it, which as you can see looks pretty great. By the way, if you yourself are interested in more TUI based content in 2026, uh then let me know in the comments down below and I'll draft up some videos on building TUI applications without the need to bundle either Node.js or bun. Speaking of both NodeJS and bun, this actually brings me on to my next reason why I'm so bullish for Rust, which is to do with the humble API. If you asked me about 12 months ago what the quickest way to build an API was, I would have answered go with no hesitation. Now, however, I most likely would blink. This is because I've been playing around more with the Axom framework when it comes to Rust, which I now believe is the fastest way to build a web API in 2026. This is because it makes use of Rust's powerful macro and type system to effectively remove a lot of the boiler plates that comes when developing APIs in other languages uh such as Go. Additionally, thanks to the fantastic Sur crate, serializing and deserializing JSON data is not only incredibly easy, but it's also really powerful. So much so that you don't ever feel constrained when you have a weird edge case that you need to implement, such as, say, casting integers into strings or handling aliases. Additionally, something that I've been implementing a lot recently has been open API specifications. Given that I want to ensure that my desktop application is always matching my API schema in Go, having this schema be generated is somewhat challenging due to the lack of meta programming and basically requires you to litter your code with comments. Whereas in Rust, thanks to its powerful macros and the fantastic Utopia Crate, it's incredibly easy to set up. In addition to all this, Axom v0.8 8 was also released in 2025 which brought a couple of other quality of life improvements such as changing the path parameter syntax to be in line with RFC6570 and also removing the dependency on the async trait macro. All of these improvements compounded together now make it quite exciting to build APIs when using Rust, which is something I'm looking forward to doing more in 2026. Okay, so this next reason as to why I'm so excited for Rust in 2026 is another language feature that I've been using quite a lot recently, uh, especially when it comes to building my video editor. This is FFI, also known as foreign function interfaces. To anyone who hasn't done systems programming before, this is basically the ability to call functions or code from libraries written in other languages. And it's extremely useful by having FFI. It means you can make use of more system levels libraries without needing to dive into C or C++. In my case, I've been using this a lot to write Objective C bindings on Mac OS so that I can build a render pipeline that uses AV Foundation, giving me the best performance when it comes to the platform. Now, to be fair, whilst Rust is really good at FFI, it's not the best language for it. That title, in my opinion, goes to Zigg, which basically makes FFI its bread and butter. Regardless, Rust is still perfectly capable when it comes to FFI. Just the ergonomics aren't that great. However, that's actually the reason why I'm so excited about it in 2026, because now it's more easier than ever to write FFI code, thanks to the use of LLMs. Now, I know there's a small subset of my audience that really doesn't like it whenever I or any YouTuber talks about AI, but unfortunately, it would be disingenuous of me to pretend that it doesn't exist, especially when it's likely going to be the way that most code is written in 2026, specifically through the use of agents. Personally, I like to think of these as a form of pair programming, where the driver is exceptionally fast at typing, but kind of dumb, uh, but has the benefit that it doesn't argue back. This means I get to act as a navigator focusing on forward thinking architectural decisions and ensuring code correctness. Unfortunately, that last part, code correctness, is getting harder and harder, especially as more and more code is now being generated. And to review all of this code line by line is starting to become a fool's errand. Now, some people will argue that this means we shouldn't use agents at all. Uh but my style of software development has always been to instead tackle problems either through mitigation or through solutions. For me in 2026 that solution or mitigation is going to be through the use of Rust which as anybody knows has an incredibly strict compiler which in this case is a huge benefit as it applies a deterministic layer to non-deterministic output. This has the benefit of reducing a whole class of potential bugs. And additionally, when combined with tests for logic, you have a really solid foundation for using agents effectively and preventing them from breaking things. So far in 2026, this has been a really powerful combination, although it does come at the cost of some velocity. However, I always feel like velocity should be balanced with stability. And for me, using Rust helps to counterweight the scales when it comes to using AI. Ultimately, I think 2026 is starting to look like the year of Rust, at least when it comes to what I'm working on. And [snorts] I got to say, it's good to be back.

To get your own VPS instance at an incredibly affordable price, visit https://hostinger.com/dreamsofcode and make sure to use my coupon code DREAMSOFCODE to get an additional 10% off. Throughout 2024, I decided to focus on using only one programming language. That language was Go, and by using it for an entire year exclusively, it allowed me to better understand the language and reduce decision fatigue. This year, I plan on doing the same, but this time with Rust, which I'm more bullish about than ever before. A portion of this video was sponsored by hostinger. How I edit my videos: https://getkiru.app My Gear: - Camera: https://amzn.to/3E3ORuX - Microphone: https://amzn.to/40wHBPP - Audio Interface: https://amzn.to/4jwbd8o - Headphones: https://amzn.to/4gasmla - Keyboard: ZSA Voyager Watch my course on building cli applications in Go: https://dreamsofcode.io/courses/cli-apps-go/learn 👈 Join this channel to get access to perks: https://www.youtube.com/channel/UCWQaM7SpSECp9FELz-cHzuQ/join Follow me on Twitter/X: https://x.com/dreamsofcode_io Join Discord: https://discord.com/invite/eMjRTvscyt 00:00:00 Intro 00:02:05 Desktop Applications 00:05:54 The Web 00:09:35 Memory Usage 00:10:40 Sponsor 00:12:06 Memory Usage v2 00:13:55 TUI Applications 00:14:46 Building API's 00:16:41 FFI 00:17:35 What about AI?