I finally give up on Rust.

This post is reflecting my personal opinion on this topic. Please make your own picture and don't be influenced so much by my unqualified opinion.

Since years now, I was really interested in getting into the Rust language. A low level, compiled, C++ like language with promises of high safety, speed and "bug-freeness" by concept. Seems like a nice alternative to Go or C#, which I have used a lot before in most of my backend applications.

So, because I am a huge fan of learning-by-doing, I threw myself into the Rust book—which is one of the best language documentations I have ever read to be honest—yeah, I'm looking at you, Go …—and studied some Rust projects on GitHub to get a slight clue how to structure a Rust application.

As you can see below, I created some mini projects in Rust in the process of understanding it's concepts—some more and some less polished and "production ready". To be honest, most of these projects starved during development because … well … I got frustrated while searching the internet for hours and hours to fix simple problems. I was literally stuck on working with the language in a way that always resulted in the following thoughts:

"Well, I could continue trying to get this access lifetime problem thing shit solved for another two hours straight … or I could just use some other language I wanted to learn to create a solution for that problem in the same time."

The repository below actually was one of my first projects I created in Rust which actually got into my personal production environment. A tiny microservice which holds basic access tokens via configuration to be used as ForwardAuth middleware service for traefik.

That was actually a point where I thought "alright, now I got it. I guess I understood how to actually build 'production ready' software with Rust which I am actually able to deploy."

Then, I had an idea of a simple web application which allows to lookup Discord User IDs to get basic user information out of it. With this project I actually wanted to dive deeper into Svelte for the web frontend, so I thought that I can build the little backend service in Rust.

So, I set up the project directory, started setting up a simple config parser using environment variables and a REST service using actix-web. And then, I ran into the same annoying access and lifetime problems like every time before. Actually, I got to solve it, but I really thought "well, that code looks so ugly just to solve that tiny lifetime thing—like really?" And instantly, my fear kicked back in of spending hours and hours of figuring out how to build that stupid tiny backend service in Rust instead of spending the time in what I actually wanted to do: Learning Svelte. So, I threw it away, fired up some talks about GenServers and Erlang/OTP on YouTube and built the service in Elixir, which actually was really interesting and I learned a lot about OTP in Elixir. And all of that in like 4 hours or so. I really wonder if I would have gotten so far if I had continued with Rust? I doubt it, to be honest.

Don't mind me wrong, I really think Rust is a great language and opportunity for creating low level software for embedded systems or system drivers or stuff like that which really needs to sit tightly over the hardware. But, to be honest, I think using Rust for stuff like highly abstracted and really high-level web applications is not the way I want to go. I really think, you can build reasonably fast and secure services with tools like Go with Fiber or Gin, C# with ASP.NET or Elixir with Plug and Cowboy. Especially Elixir is a really fast language for web services and is also very bug-secure due to its functional nature. Also Go web applications are super fast—I mean, Google did not start to use and support it because it is slower than most current solutions out there—and if you do it the right way, these can also be error-safe. Its all about code quality and test coverage. Heck even Java must be very performant in this sector of software development—I guess Netflix is not creating services using it because they purely have fun to do so (😉).

And the thing is, I am way faster building back end apps with Go, C# or even with Elixir which I am not as familiar with as the other two. There is also a great video by rwxrob titled "Back to Go, Rust is slow" where he also talks about that issue. Especially when you are getting payed to build software solutions, time is always your enemy, so it is way more important to quickly create smart solutions with actually readable and maintainable code, which is another problem with Rust in my opinion. If you are not working on the back end of any FAANG-like service, you might not even consider pure execution speed as first point when choosing your stack.

Also, he spotlights another thing that must be considered creating web apps with Rust. Even though Rust promises safety built in, there are just things that are not that safe and stable as they actually are promised to be.

Take a look at the following example. Generally, you are able to create slices of strings in Rust. But look what happens when you take the same slice of "special" UTF8 characters.

Yep, this functions would straight up crash the service. Now think about what would happen if you put this behind an input from a parsed REST body. You have only tested this function against general English text and now someone types in Russian or, like in this case, Japanese text. Sure, when you know that you should not use slices on strings, which is also highlighted in the Rust book if you have read it, everything is fine, but you need to know that upfront. Same goes with the other languages mentioned. You will not magically stop making your app crashing in production by just using Rust without knowing the do's and don'ts of the language.

Okay, enough crying around. I decided to stop trying to use Rust for future web services, because there are tools that are as performant and secure as Rust promises to be for that specific purpose—and I will not spend hours of fixing stupid lifetime issues and actually building my code around that. To be honest, I think, If you are creating web backends, most languages will do the job quiet well. Hey, even Ruby on Rails seems to scale well enough. I think you can actually scale everything as long as you design your infrastructure and software correctly for that. And—as mentioned above—mostly coding speed, maintainability and readability just counts more that pure execution speed and error-safety.

Summa summarum: There are specific tasks which can, but should not always be solved with every tool or languages. If you want to build a web app in pure C, good luck. If you want to build an OS in JavaScript, good freakin' luck as well. Sometimes you want to do something really quick, efficient and reliable—use a tool you are more comfortable with. If you want to learn something new, of course, don't be shy to take a maybe "less conventional" approach to do so, nothing holds you back. Just make smart decisions on given circumstances.