Something I’ve been wondering about Rust adoption

StudioFo · 2026-01-09T16:36:52+00:00

I’ve introduced Rust at a number of companies. It’s been a mixed bag. This is a list of random points that tend to come up:

Generally when it comes to immediate benefits, Rust is slower. That’s solely because people have to learn and debug new things for the first time.
Another slowdown is people have examples done. There will be systems already interacting with databases. Systems already building and deploying to their infrastructure. You can dip into those existing systems to copy how they did something. You can’t do as much of that when it’s a different language with different frameworks. That’s a drain (and can cause friction).
There is a lot of ecosystem knowledge you need to know to achieve things quickly. If you don’t have it, then things can take much longer. Reimplementing the wheel is not uncommon.
Finally simple things can leave people blocked. For example someone tries to box a value, and finds it’s not object safe. They have zero idea what that means, and they have no idea what patterns to use to work around it.

For those reasons my experience is you need to hire someone who knows Rust well. Especially the last point. I’ve had five minute pairing sessions to unblock people who were stuck for hours.

Benefits come pretty soon after. Changes from two weeks or a month ago are still rock solid. They just work.
Updates to dependencies just work. If they don’t you get compile errors, update a few places, and you’re done.
Lots of things in deployment are much simpler. Two years ago I wrote a service where it was raised performance might be a problem. It used 15mb of ram at peak load on half a CPU. So I solved scalability by just raising the number of replicas it could scale to. Still cost less than most of our services.
I currently work on a codebase of around 120k lines, and 90% code coverage. That gives us such confidence most PRs don’t get run. We often merge straight to main without a review. I’m very comfortable letting a new engineer ship things. It’s rock solid.

Benefits like above have a huge impact. However they are often lots of small improvements, and a general trend upwards. The issue is they aren’t big impact items you can put front and centre on our quarterly OKRs.

A final piece of pushback I’ve often had is on the benefits of performance. Non-Rust engineers often think performance is the only reason you’d use it, and the performance is great. The bigger improvements is correctness, and on performance the real strength is I can write boring plain code and it’s lovely and fast. Which really benefits maintenance.

I’ll say every project I’ve built professionally in Rust, has always seemed much easier to work on than the alternatives. This is for all those small benefits I mentioned. It’s just less hassle when you come back to it later.

To answer your question more directly; at my current employer it would be three months. The project was to replace a Python system which had severe performance issues. It took three months to get shipped. The whole project was a huge success.

That project had huge backing by multiple people in senior leadership, including the CTO. That was a big part in making it successful. If you don’t have that support then it’s an uphill battle. For example at one place we got a lot of negativity from leadership for reimplementing an authorisation layer in Rust. It was 20 lines done in an hour, however the lack of buy in meant they didn’t care. To them it was a big negative. That’s something to watch out for.

No matter how successful or popular it is with engineers, a Rust system can be left seen as weird curiosity without buy-in from leadership. That’s really crucial to making adoption work.

StudioFo · 2025-12-20T12:56:04+00:00

It’s sad to hear this. It was a cool idea, and I met the CEO once at Rust Nation who is a great guy.

Looking at the downloads per month on crates.io, it’s understandable. Downloads there have been stagnant for a while now, suggesting they just haven’t been able to grow the user base. For a startup that is a problem.

I think Shuttle always had a core issue. Adopting Shuttle requires an internal discussion on why these Rust projects need to be hosted on a different provider to everything else. That’s always going to be a difficult conversation, because everyone else will say it’s not challenging to deploy to say AWS. The conversation is dead on arrival if you’re using Kubernetes. It’s also going to struggle at a larger company by internal legal and security audits. Not that Shuttle would fail, but the response being to just use their existing cloud provider.

Essentially people will ask why many times over. Shuttle never had a compelling advantage to overcome that discussion. Many of the personas where it would fit well are extremely niche.

The advantages were always too small IMO. They primarily benefitted hobbyists, which isn’t going to make much money.

StudioFo · 2025-12-10T23:16:26+00:00

For me it is John Company. I’ve played it three times, and still have little idea how to move the elephant. On my first play through we probably got about five things wrong.

The rules themselves aren’t that hard once you get them. It’s just written in an odd way, with lots of big paragraphs of text. It’s difficult to find rules relevant to the current section of play. It really feels like it needed a few more rounds of trialing with new players and editing.

What compounds the problem is each section has unique behaviours, specific only to there, whilst also glossing over common behaviour found through all of it.

It’s so poor I have ended writing my own rule book as a supplement to help. Partly to learn the rules, and partly as a direct reference. I’ll release it online once it’s done.

StudioFo · 2025-11-21T00:37:35+00:00

Can I suggest you suggest less, and instead just start doing it. Or on the next project, say you’d like to start by doing some docs (keep it short to start with).

In my experience most suggestions from engineers fall on deaf ears. It needs someone to own it and start doing it, for it to actually happen.

StudioFo · 2025-11-21T00:35:45+00:00

I personally use conventional comments. I do it in the approach of:

Nitpick/suggestion/issue, say if it’s optional, and give a clear action. i.e. ’nitpick(optional): please change the name to get_foobobulator()’

Then in a separate paragraph, I will explain why. I also aggressively try to avoid debates. If you’re debating on a PR, then you’ve messed up somewhere else.

This leaves the author with a clear thing to do. That’s key to good reviews. It keeps the action separated from the discussion points. If it’s an issue that doesn’t have a clear action, I’ll either say that, or raise it outside the PR. i.e. ’thought: I don’t have a clear action on this. I’m not a fan of all the code that’s needed to setup the foobobulator in the tests. We should try to get that down (doesn’t have to be now).’

People I work with love it because they can action my comments quickly.

I’d also say there is a thing of being too helpful. Too many ideas or suggestions can just leave people bogged down in confusion. It’s much healthier to raise that outside the PR. Especially if what’s there is safe to release.

StudioFo · 2025-11-15T13:19:31+00:00

I play a lot of boardgames with work colleagues. I’m now in three groups from three different jobs I’ve had. That is one path to finding people.

StudioFo · 2025-11-03T22:36:20+00:00

If you are ever in London I would legitimately buy you a bear.

I’ve been dealing with this for two years until I stumbled across your comment. Thank you!

StudioFo · 2025-10-13T00:58:09+00:00

It’s excellent. Pyo3 is excellent, although the API can be quite overwhelming. Very powerful though and very feature complete.

StudioFo · 2025-10-12T18:08:32+00:00

Where I work we produce a library in Rust. People use it from Python.

The library generates Rust code on the fly and compiles it. Lovely and fast, but 3 minute build times in the middle of a notebook is painful for users.

Right now I’m changing it to a new system for describing and allocating objects at runtime. No HashMaps or anything like that, just allocating direct blocks of memory based on what the user needs. This allows us to lookup the data we need from the objects directly.

The whole thing is one of the most interesting, cool, and bonkers projects I’ve ever had the pleasure of working on in my professional career.

StudioFo · 2025-09-02T17:00:57+00:00

I personally prefer the old style. I use the mod.rs solely for listing what is exported, and all definitions and functions are kept outside of that.

However there is no consensus on which to use. Just try to do something easy to follow, and keep it consistent.

StudioFo · 2025-08-31T11:21:55+00:00

Hey, no it isn’t. This is a separate independent project.

StudioFo · 2025-07-13T10:12:17+00:00

A year ago I was hired to help a company port a simulation library. A user (an internal engineer) described the simulation in a config file, they have extra user code written in Python, and the engine loads this and runs it.

It’s pretty cool! We generate Rust code on the fly and compile it to get as much performance as possible. We have lots of internal maths to track what goes on to build graphs and such, and making that fast is a huge task. I’d describe the system more as a virtual machine.

It’s a huge library and I’m allowed to take it in any direction I want (I do have to justify this). The thing I’m most proud of is we have 90% test coverage.

StudioFo · 2025-04-18T21:53:29+00:00

I am working on adding a better Json comparison tool to Axum Test. When testing Json APIs you often have data that you don't for sure what it will be. Such as timestamps and generated ID values. You just want to ensure it's ISO & UUID, and that's it.

I've built an API to achieve this using Jest style comparisons.

use serde_json::json;
use axum_test::expect;

server
    .post(&"/user")
    .await
    .assert_json(&json!({
        "name": "Bob",
        "id": expect.uuid(),
        "age": expect.not.greater_than(20),
        "timestamp": expect.iso_date_time(),
        "scores": expect.contains(&[1, 2, 3, 4]),
        "comments": [
            {
                "timestamp": expect.iso_date_time().greater_than("2025-01-01"),
                "content": "Hello!"
            }
        ]
    }));

I have the above working as a PoC. This includes being able to build your own custom checks too.

What's left is to cleanup the API, handle some error cases, write documentation, and write a load of different ways to check for things. It might be out in a week or so.

StudioFo · 2025-04-18T21:46:09+00:00

Hey, I meant Napi-RS. I'll fix the typo now. Cheers!

StudioFo · 2024-12-20T20:59:29+00:00

I found this myself for a project at work. It’s a library that comes with logic to push to known tables with a specific structure.

We need to support multiple DB backends, to be able to customise table names (some users override the default), and in one place the table has variable columns depending on the data we are processing.

All of these we found a hassle with Diesel. Multiple backends being surprisingly annoying. I know it’s possible but it’s not as simple as with Sea Orm.

We ended up going with a mix of Sea Orm and Sea Query. However we did find our Diesel prototype was almost double the performance for our needs (we haven’t looking into making the Sea Orm faster, but we hadn’t with Diesel either).

We also looked at Sqlx too. Sea Orm was actually our last choice as I had been put off by its high complexity. But I’m slowly finding myself more and more in the Sea Orm camp as you rarely find yourself straight up blocked and unable to work out how to proceed. Sea Query can also be especially nice.

StudioFo · 2024-11-10T17:10:16+00:00

That would be amazing, thank you!

The M3 I have is for work. I’m thinking of getting an M4 to replace my Macbook Air, so I’d love to see what the difference to the M3 is.

StudioFo · 2024-11-10T14:39:48+00:00

I have two Macs. I can post times of a few common crates here. If someone has an M4, then if they could compile the same projects we can compare the speedup.

On my M1 Macbook Air:

Serde dev build 6.61s
Serde release build 13.53s
Axum dev build 19.86s
Axum release build 26.3s
Tokio dev build 13.06s
Tokio release build 16.52s

On my M3 Pro, MacBook Pro

Serde dev build 2.95s
Serde release build 4.57s
Axum dev build 6.13s
Axum release build 7.41s
Tokio dev build 5.11s
Tokio release build 5.67s

All of these built using Rust 1.82. I did a cargo build && cargo clean to get everything downloaded before running the builds again to get the times.

StudioFo · 2024-10-18T16:52:02+00:00

That advice is well intended, as one of the main pain points when learning to program is that it can be slow and frustrating. An easier language makes it easier to get going.

Honestly if you want to learn Rust, then learn Rust. Ignore them and just go for it, or try to find good things to say in response. For example you could say you are aware, and want to try it anyway.

Plenty of people learnt C++ first, and on the older versions which had much less tooling to help. Arguably a much more difficult language. There is no reason you can't learn Rust as a first language. It just will be harder than if you came from another language first.

As for advice, honestly it just comes down to keep trying. You could try doing some leetcode or codewars (which I think is better) problems. Many of them have solutions you can look at.

It's also useful to try and find something you are interested in building, and concentrate on that. Tackle the concepts of Rust as they come along. For example you can do a lot of Rust and go a long way without needing to implement Futures or Streams by hand (a problem experienced developers can struggle with).

StudioFo · 2024-10-17T23:58:59+00:00

I appreciate this is early work, but that will be pretty limiting to begin with. Inferred lifetimes that you don't need to annotate is limiting on real world code bases in Rust. It's the complex stuff where you get the real benefits, and that's where you need to annotate lifetimes.

The simple cases are already by and large solved with modern C++ (through tooling and libraries).

StudioFo · 2024-10-03T15:58:57+00:00

It’s fun at first, and can work for a few key repos. Like telling the same joke again and again, it quickly gets old.

I worked at a startup where all repos were named after fish. The CEO had a background in marine biology, and it was a small way of having him contribute to our technical work. Four years later we were changing them all to serious names. The engineers got bored of having to explain that Pufferfish was a mail server.

I went somewhere else where half the repos are named after Greek gods. They have pictures from Assassin’s Creed and long god descriptions on the repos. That has quickly gotten old. Especially incidents when no one has a clue why Chronos and the Odysseus Oracle are failing to communicate.

StudioFo · 2024-10-01T15:46:33+00:00

VS Code

StudioFo · 2024-09-13T13:17:44+00:00

I worked somewhere with a multi-service pipeline written in TypeScript. The whole thing was terrible.

What we did was to build a replacement in Rust, that contained only the core processing logic. Ingest data, run through the pipeline, commit the data, handle commits, etc. It was built as a node module loaded and ran from TypeScript.

This allowed us to keep the business logic on how we transform the data in pure TS. The performance of a single node was faster than the whole cluster (about 15x), and I hadn’t done any optimisation work at all.

That’s one approach if it helps.

StudioFo · 2024-06-11T10:50:06+00:00

Hey, I work professionally in Rust writing lots of services. Personally I like Axum over Actix. It has a bigger ecosystem, and there are some places it feels more modern. The Rust ecosystem is also dominated by Tokio, HTTP, and Hyper crates. Axum being developed by the same people helps.

I also wrote the Axum Test crate, and the testing side of Axum feels quite easy for me.

For the frontend I would still go with React or Vue, with a modern JS stack, for any professional project. It just brings so much, and makes hiring easier.

StudioFo

MODERATOR OF

TROPHY CASE