A Cautionary Rusty Tale

A Cautionary Rusty Tale

Hi! My name is Sergio Tortosa, and I made my AI-powered documentation generation... in Rust. Take into account I started this a year and a half ago, when LLMs weren't as advanced as they are today. So I hope this will serve as a story to learn both some technical info as well as what to do (or rather, what not to do) when starting a startup; this should also serve as a kind of evolution of the viability of Rust for web projects. Was this a good idea? You'll find out.

About the Project

Imagine that you could generate elegant, simple, and complete (even if the comments themselves weren't as complete) documentation with just connecting your repository; that is the goal of my project Dokumentado: https://dokumentado.dev/ .

As I said earlier, it's written in the wonderful language of Rust. Why? If I were honest, the most possible explanation is because I could, and I love working with Rust (I guess that is expected when you see me running to my friends, "Hey, I made this 3D piece ... in Rust", that actually happened, BTW).

If I were to give more concrete, definite reasoning, having your project in Rust is a trusty way of knowing that once done, the amount of maintenance needed would be very low: Rust is more robust to errors than other languages, is more efficient by default so it needs less optimization, and its dependencies don't break too often (something I had much more trouble with on my dabs on JS, for example). All of that turned out to be pretty true; even updating dependencies nowadays isn't too bad (there's a bot that helps you even, which is pretty good).

Technical Challenges

Technically speaking, I would say the biggest challenges are integrating different platforms that operate in different ways in a single codebase, concretely how the Salesforce API operates in a per-file way while everything else operates in a per-project way.

So you might be asking... and? Join this with lifetimes, generics, and Rust's incredible async story... and you get one of my worst nightmares in this regard... the dreaded ASYNCSTREAM.

For all of you who are scratching your heads. An AsyncStream is basically a series of events that is processed in an asynchronous way; that is, if the resource isn't present, instead of sitting like a precious, extremely expensive duck, your thread will go to do other tasks of your program, which is great. The same thread working on your program means no thread must be swapped by the OS, which is time lost. When your thread does come back to your function, the program needs to know where it was, all the variables that it had, etc. So an .await in Rust is essentially a save point.

So when you do something like:

async fn send_file_through_http(path: &Path) -> Result<()> {
    let file = tokio::fs::read(path).await?;
    if !verify_file(&file) {
        return Error::WrongFile;
    }
    my_http::send_file(file).await?;
    println!("Sent file correctly");
    Ok(())
}

You are effectively generating two save points, at which the program will ask, "Is this done?" Since the answer is going to be no, it will leave your function and come back later at that exact point, knowing all the variables that were there. This is actually a kind of complicated way of doing async, but it has the advantage that it allows the compiler to not need allocations, making it a near-zero-cost abstraction, and all of this complicated code generation is handled by the compiler, making it a non-issue... usually.

Magic like this is wonderful... until it breaks, and oh boy, when it breaks. Now AsyncStream enters the stage; the thing here is that it is a trait, so it must be implemented, which kind of makes making use of the sugar provided by the compiler more difficult, and this breaks the illusion... HARD.

... TODO revisit async stream...

Developing the Project

Going back to the project itself, why did it take me almost a year to get a product that seemed usable? Because while it had certain difficult things to take into account and consider, it was more of needing to integrate SO MANY... MANY... PLATFORMS. The nice part is that this is not a difficult task, but given that Rust still doesn't have APIs for everything, doing this is tedious as 🦆. I have to say that my own curiosity/perfectionism didn't help either.

Running in the 20's

So I wanted to make sure that I would be able to escalate... that I would be able to dispatch all those users that would come with the utmost efficiency so that prices could be kept low (or if things went great, a great margin), and I had the mentality that efficient programming makes managing much simpler (I still do, BTW; not needing more than two instances of your web server in the worst of cases and only for redundancy simplifies things A LOT, especially in the first stages).

Was this worth it? ... Not really. Out of the hundreds of users I expected, I got ... 0. It took me so long that by the time I got a kind of finished product, part of my project was taken over by AI integration, and for those who would still benefit from that, well, they just saw it as another AI product. Many may say this is just bad marketing... and they're probably right, but if I were to give any advice to someone starting:

Why didn't I try to share my idea earlier? Great question. Truth be told, I was scared that my opportunity at creating something that could be my work would be taken over... and it happened regardless. I learned that in the end, while ideas are great, taking them to action and doing it with finesse, especially understanding how to talk to your market, is way more important than the idea itself, but in this case, Rust didn't help either.

So is Rust a bad language to create your own project/business from zero? It used to be, but not anymore.

Today: LLMs to the Rescue

It is funny, as the same thing that kind of took the small possibilities that my project had is the same thing I feel like advertising today. If Rust wasn't always a wise decision given that it is way more verbose and asks you to have everything under control, this is mitigated thanks to AI and LLMs.

Newer LLMs (like the one I'm using right now, "KLM 2.7 Code") are doing a fantastic job of creating Rust code, as long as you can guide them and know what you're doing. They make writing the code insanely fast; pair that with a subscription like OpenCode Go (seriously, go check them out; good models and fantastic pricing, and no, unfortunately this is not sponsored, I wish) and you get a cheap, good enough code assistant.

Now, I'm not advocating for just vibe coding all the way, but rather using an LLM to write code that you could write yourself, or in the worst case, you would need to look at some examples (sometimes you don't remember all the patterns, or in specific cases like a token parser, you might need some help), and this is fine.

Not only does AI help Rust in that it mitigates the time it takes to create a Rust project, but also Rust helps the AI. LLMs make, from time to time, some mistakes, like reordering, using a variable that's not defined in the current scope, null references, etc. Rust not only makes it impossible but also makes the AI transparent to solve this: by the time the AI tells you it's done with the prompt you asked, it has already checked your program where cargo will have complained about all of those problems and fixed them on the spot.

I'm running a service where I have a Next.js service serving as the frontend and a Rust backend that handles part of the business logic and the access to the DB. The backend has needed much less work for it to be reliable than the frontend does, and while I admit that doing a React frontend might also have to do with that, I didn't find this unreliability in any of the Rust projects that the LLM aids me with.

TL;DR

• Don't start a business unless you've understood that market and validated that idea.
• It's fine if your MVP is made with crayons (despite what your mind might tell you); if your idea is good, it will still be good even with crayons.
• In the era of AI, Rust is a wonderful language to create projects with.

If my project is still useful to you, let me know. I'm not throwing it away, and it would be nice if we could find a way to help programs with it in this difficult-to-navigate field.

And as I like to end everything I write with: I hope you have a good day!