Comment by ottavio
2 days ago
Why should a developer use this for anything beyond a pet project? Just because it is written in Rust?
All these "rewritten in rust" projects only reinforce the idea that a significant part of the rust community consists of software talibans and not of engineers who must deliver something that works and is reliable over time.
> software talibans
I will note that, very funny
Well, this approach is more similar to imposing a dogma thank engineering.
Is managing memory safely important? YES
Is managing memory safely the solution to most of the problems? Absolutely not.
Advocating the language ignoring everything else (having as first and only argument that the code was rewritten in rust fully qualify for this case) is dogma and not engineering.
Yeah I'm using that one.
We have a problem with software religious fundamentalists in our organisation and it's an apt description.
I actually had a lot of problems with software cult followers of influencer gurus like ThePrimeagen, Lex Fridman, Theo, etc... Those are so worst. You can't resonate with them.
1 reply →
what does it mean ?
Pushy fundamentalists, I suppose.
1 reply →
Often the biggest blocker on moving to a new programming language, is the cost of re-writing everything.
Cue some story here on a bank or airline somewhere still relying on cobol backend servers.
These LLM conversions really seem to make modernization of large parts software layers possible!
I have some familiarity with the bank situation, and while a lot of them are on some very old systems (maybe COBOL, maybe something else, either way they want off it) the cost of actually re-writing the code is far from the most significant issue.
Consider: You have a big mainframe running your tier 1 bank. Assume that you can see all the code on it, and you can feed all that to an LLM if you like. Getting it to spit out a Rust version is not what you actually want - you now have a modern language but it's still a singleton instance, so where do you run it? Most hardware doesn't give you enough uptime for what you need here, because what you actually needed was a re-architecture for distribution / failover / whatever, and while you could ask your LLM to do that you aren't going to run your bank on the result.
> while you could ask your LLM to do that you aren't going to run your bank on the result.
Why not?
I feel like we're entering a new era of prejudice against not a category of humans, but against non-human intelligences.
The design patterns for distributed and fault-tolerant systems are well-known and established in the industry. Both humans and AIs are familiar with them!
So if you sketch a design for the AI to follow, establish the rules in AGENTS.md, have a robust test suite, use a frontier model dialed up to eleven, etc... why not rely on the LLM output?
At the end of the day, humans are not without fault either.
I've been wading through some legacy "pre-AI" code recently and it has more bugs than a rainforest! Static fields used incorrectly, causing data races. Floating point types used for money amounts. JavaScript and SQL injection up the wazoo. Wildly unsafe password handling. So on, and so forth. This is the norm for most human-written software, not the exception.
As a proof-of-concept, I tried an AI rewrite of one such legacy app[1], and it is not bug free, but it notably has fewer bugs than the original. Different bugs, sure, and I'll have to iron them out after a round or two of UAT, but I'm honestly more confident with what I got from the chatbot than the code inherited from humans.
[1] Deals with money, but admittedly at a much lower level of risk and consequence than a banking app running on a mainframe.
5 replies →
> but it's still a singleton instance, so where do you run it? Most hardware doesn't give you enough uptime for what you need here, because what you actually needed was a re-architecture for distribution / failover / whatever, and while you could ask your LLM to do that you aren't going to run your bank on the result.
If only we had a way to solve these issues with tools capable of running Rust programs in that way. I guess every company that needs distribution / failover has a mainframe sitting in their office nowadays huh?
https://k3s.io/
https://kubernetes.io/
https://aws.amazon.com/
https://www.erlang.org/
etc.
1 reply →
It's not enough to do a rewrite. Someone has to maintain it. Such a huge codebase with literally zero experts is unmaintainable. There is no one who knows how the internals work.
Sure you could keep vibe coding it but I wouldn't bet my data on that. A database needs to be rock solid.
This seems to be the issue with using LLMs for any code generation. Even with my own code bases that I've written entirely by hand over years, if I use AI to implement anything, I don't go through the mental model of architecting it, so I don't know how it works. I can only imagine this to be far, far worse for large code bases maintained by a team of people who are all using AI.
2 replies →
> Cue some story here on a bank or airline somewhere still relying on cobol backend servers.
There's existing money and expertise in those environments to rewrite the whole thing, yet they don't. You may loan them free engineers/experts and they might still not rewrite anything.
It's a clean-cut financial decision.
The existing system works. Yes, it costs a lot to maintain, and you could definitely reduce that if you moved to a more modern system. So now you're talking payback periods. Cost of development / maintenance cost savings per year = number of years before you pay back the project.
Problem is, that the cost of the development is often unclear, and the maintenance cost savings, while definitely above zero, and often unclear, and approximated the numbers usually come to a payback period in decades.
And that's without the usual tech caveats; We can't promise there won't be bugs. We can't promise deadlines will be met. We can't promise the project will succeed at all. We can't promise existing functionality will be faithfully reproduced in the new system. The normal risks around any software dev project.
All in all, it looks really expensive and really risky compared to just doing nothing and running the same old system for another five years.
Source: I helped do some of the maths on this for a Y2K project.
OK but, Postgres is not one of those clunky "we have to replace this" systems.
> the biggest blocker on moving to a new programming language, is the cost of re-writing everything
In 2026, not sure if it was satire. Do some people truly believe that all their software stack has to be single tech, from device drivers to end user apps? Does that extend to remotely accessed services?
At the same time that was ever the only reason for moving to a new programming language: abandoning all the bad ideas and craft that had accumulated in the previous language ecosystem. Needing to rewrite everything meant starting from a clean slate, allowing the new systems to be designed for the new age, making everything in that new language feel sleek and modern and thus appealing. Of course, as time progresses even the new language starts to accumulate bad ideas and cruft, historically necessitating yet another language to offer the clean slate again.
If the code is going to be translated forward instead of abandoned and then rewritten, as is now completely viable via LLM, there is no reason to move to a new language at all.
As someone who loves Rust the language and tool set: This class of projects [LLM rewrite of a reliable piece of software honed over decades) is embarrassing.
If you are watching this and haven't used rust: Please don't judge the language by this part of its users.
> significant part of the rust community consists of software talibans
I seriously don't get it though. Rust is a nice language, but so is X. However we don't see X people brigading existing projects with constant bombardment with "rewritten in X". What is that about Rust that prompts this behavior?
Rust attracts zealots because of the various kinds of safety guarantees. The speed means it can replace more or less anything.
People see the safety as a moral superiority so it attracts obnoxious zealots.
Other languages' features and syntax aren't nearly so easy for zealots to form behind. The perception of absolute safety it puts in some people makes them crazy.
This is a good point, actually. Might well be the reason.
A more plausible explanation:
People were told for years they can't use Rust for their new projects because it hasn't been "proven" in industry yet. So the option was to sit back and wait (chicken and egg) or move to rewrite a bunch of projects so that it could actually be "proven". Not saying this is the only reason why it happens (every language has its Zealots) but it certainly makes more sense.
Due to the explosion of new programming languages over the past few decades your options are to either aggressively expand wherever possible or die out because you're not "proven".
what do you mean by that? were there people brigarding postgres to rewrite to rust? otherwise relative to popularity i do also constantly see posts on here about Project X rewritten in Go, Zig, C etc...
It's pretty ergonomic to agents. Like typescript.
How exactly are rewriting something the equivalent of being the taliban?
Because they are blowing up old monuments as part of an attempt to enforce a hardline but nonsensical purity on other people.
what is the metaphorical blowing up here?
Except for the monument still being there, and being the main thing everyone uses still.
I think this shouldn't be taken too seriously, from what I understand it's an exploration of what's possible with today's LLMs.
You're right to talk about the trend though, because what it shows is how the cost of re-writing well covered project has completely crashed, so that in itself is a learning.
The cost of surface level rewrites has crashed. Which will probably cover 80% of cases. Caveat emptor on which side your project falls.
I have no issues recognizing that I had memory-related problems in production (I program embedded systems in C).
But most of my issues were related to concurrency and data sanification, especially when the other end of communication fails with unexpected behavior. These bugs are nastier than memory.
So, I have pointers, and I am not afraid to use them.
> All these "rewritten in rust" projects only reinforce the idea that a significant part of the rust community consists of software talibans and not of engineers who must deliver something that works and is reliable over time.
Nailed it ! There are some folks who behave holier-than-thou just because they happen to use some language. Language missionaries if you will, and they are insufferable.
> Why should a developer use this for anything beyond a pet project?
If it _is_ 50% faster, then that's the reason
Obviously like any new database it's very risky to use so probably only used for niche use cases at first, but if it turns out to be just as reliable as postgres and faster then why not?
It probably is 50% faster, probably by skipping flushing data to disk.
I'll make it 100% faster, skip saving any data to disk.