Me too! A couple days ago I gave claude the JMAP spec and asked it to write a JMAP based webmail client in rust from scratch. And it did! It burned a mountain of tokens, and its got more than a few bugs. But now I've got my very own email client, powered by the stalwart email server. The rust code compiles into a 2mb wasm bundle that does everything client side. Its somehow insanely fast. Honestly, its the fastest email client I've ever used by far. Everything feels instant.
I don't need my own email client, but I have one now. So unnecessary, and yet strangely fun.
Its quite a testament to JMAP that you can feed the RFC into claude and get a janky client out. I wonder what semi-useless junk I should get it to make next? I bet it wouldn't do as good a job with IMAP, but maybe if I let it use an IMAP library someone's already made? Might be worth a try!
The JMAP client itself is hosted here: https://seph.au/claude-webmail/
I can't prove this but its a purely static web app. You need a jmap server to use it. If you use stalwart, set:
server.listener.http.permissive-cors = true
server.listener.https.permissive-cors = true
Defect free. Immaculate types. Safe. Ergonomic. Beautiful to read.
AI is going to be writing a lot of Rust.
The final arguments of "rust is hard to write" are going to quiet down. This makes it even more accessible.
Oh my, there's a new language called Rust? Didn't they know there already is one? The old one is so popular that I can't imagine the nicely readable one to gain any traction whatsoever (even if the old one is an assault on the senses).
I honestly can't tell if this is a humorous attack or not.
Poe's law is validated once again.
It's not the best tool for the job for a lot of things, but if the LLMs make writing it as fast as anything else - whelp, I can't see any reason not to do it in Rust.
If you get any language outputs "for free", Rust is the way to go.
I've been using Claude to go ridiculously fast in Rust recently. In the pre-LLM years I wrote a lot of Rust, but it definitely was a slow to author language. Claude helps me produce it as fast as I can think. I spend most of my time reviewing the code and making small fixes and refactors. It's great.
EDIT: Not who you think, apparently. lol.
Let me rephrase: who owns ALL of the "AI companies", along with everything else--every other big name you've ever heard of?
Feel free to keep shoveling all your data in their direction and using the tech they tell you to use. I'll sit this one out, thanks.
Claude is an Anthropic offering.
It's not, nor is it well informed. People are currently developing languages specifically for use by LLMs.
> It's not the best tool for the job for a lot of things
Then how could it possibly be the final language?
> if the LLMs make writing it as fast as anything else - whelp, I can't see any reason not to do it in Rust
This has nothing to do with the claim that it's the final language.
I used to think that I would never write C code again, but when I decided recently to build something that would run on ESP32 chips, I realized there wasn't any good reason for me to use Rust yet. ESP-IDF is built on C and I can write C code just fine. C compiles quickly, it's a very simple language on the surface, and as long as you minimize the use of dynamic memory allocation and other pitfalls, it's reliable.
My biggest problem with rust right now is enormous target/ dirs.
We're working on that and it should get better soonish. We're working on shared caches, as well as pruning of old cached builds of dependencies that are unlikely to be reused in a future build.
Even rust has need of this. For example, I want a nopanic effect I can put on a function which makes it a compile error for anything that function calls to panic.
I really like how flix.dev looks, but there's always a little nagging at the back of my head that something like rust will always produce more performant software.
This!
This apart from build times is my biggest request for the language.
Nopanic, nomalloc, etc.
> Defect free.
I am an upstream developer on the Rust Project (lang, library, cargo, others), and obviously a big fan of Rust. This kind of advocacy doesn't help us, and in fact makes our jobs harder, because for some people this kind of advocacy is their main experience of people they assume are representative of Rust. Please take it down a notch.
I think Rust is the best available language for many kinds of problems. Not yet all, but we're always improving it to try to work for more people. It gets better over time. I'd certainly never call it, or almost any other software, "defect free".
And I'd never call it "the final language"; we're building it to last the test of time, and we hope things like the edition system mean that the successor to Rust is a future version of Rust, but things can always change, and we're not the only source of great ideas.
If you genuinely care about Rust, please adjust your advocacy of Rust to avoid hurting Rust and generating negative perceptions of Rust.
For a taste: I wish we didn’t need lifetime annotations, somehow. I wish rust had first class support for self borrows, possibly via explicit syntax indicating that a variable is borrowed, and thus pinned. Unpin breaks my brain, and I wish there were ways to do pin projections without getting a PhD first. I wish for async streams. I wish async executors were in std, and didn’t take so long to compile. I could go on and on.
I feel like there’s an even simpler & more beautiful language hiding inside rust. I can’t quite see it. But I really hope someone else can bring it into the world some day.
I would like all of that as well. I think we can do much of that in Rust. I would love to see self-borrows available, and not just via pinning; I would also like relative pointers. I would like people to almost never have to think about pin or unpin; one of my rules of thumb is that if you see Pin or Poll, you've delved too deep, and nobody should need those to write almost any async code, including the interiors of trait implementations and async runtime implementations. And I would absolutely like to see async iterators, async executors, and many kinds of async traits in the standard library.
I also think there are plenty of things we are unlikely to get to even in an edition, and that might never happen without a completely different language. I'm not sure if we'll find a path to doing those in Rust, or if they will be the domain of some future language that makes different trade-offs.
Yes, this is my feeling too. All programming languages - perhaps, all computer programs - must decide how malleable they should be. Fast moving systems are exciting, but they're very annoying to use, or build on top of. I think generally we want a very slow moving language for infrastructure software, like databases or the linux kernel. Slow moving languages are often good for users, because they don't need to learn new things or rewrite existing software. (I think thats one of the reasons python3 was so poorly received.)
It might be too late for large changes in rust. This a sign of maturity, but its also a little bit sad. I want all those features you mention too.
Some day. Maybe LLMs will help somehow. Rust is, thankfully, not the last programming language humans will invent.
> > Defect free.
There's a Google talk on the matter. "Defect rate" / "defect free" is a term that is used quite a bit. I've latched onto this, because I find it true. Rust is a far more defect free language on a line by line basis measured and compared to other statically typed languages.
> And I'd never call it "the final language"
I honestly disagree, and I'm sticking to this prediction.
I don't think we're going to be writing code much longer by ourselves. The machines are going to outpace us soon.
Maybe something that's LLM-oriented will take over, but at that point these won't be "human" languages anymore. So I'll revise my claim to "Rust is the last human language".
If I want to serialize my thoughts to code, Rust is the language for it. It's probably the last one I'll be hand-writing or sending my revisions back to the LLM for.
Rust will also be an order of magnitude easier to author, at which point there shouldn't be much holding people back from producing it. If you have a choice between generating Java, C++, Go, or Rust, you're going to pick Rust almost every time unless you have to fit into those other ecosystems.
If you haven't used Claude or Codex with Rust, it's sublime and you should drop what you're doing to try it.
As AI makes human-readable syntax less relevant, the Erlang/Elixir BEAM virtual machine is an ideal compilation target because its "let it crash" isolated process model provides system-level fault tolerance against AI logic errors, arguably more valuable than Rust’s strict memory safety.
The native Actor Model simplifies massive concurrency by eliminating shared state and the complex thread management. BEAM's hot code swapping capability also enables a continuous deployment where an AI can dynamically rewrite and inject optimized functions directly into live applications with zero downtime.
Imagine a future where an LLM is constantly monitoring server performance, profiling execution times, and dynamically rewriting sub-optimal functions in real-time. With Rust, every optimization requires a recompile and a deployment cycle that interrupts the system.
Finally, Erlang's functional immutability makes deterministic AI reasoning easier, while its built-in clustering replaces complex external infrastructure, making it a resilient platform suited for automated iteration.
We spend quite a lot of time conceptualizing around safe self mod and to build apps that can change at runtime. We ended up using custom Lua VM, type system to catch mistakes, declarative homogenous infrastructure and actor model (erlang inspired).
Actor model provides not just a good isolation but also it's much easier for AI to reason (since most of components are not that large), we already able to use it to write quite complex systems with ease.
Another upside - in actor model you don't really need any of this fluff with cron jobs, queues and etc, all the logic naturally maps to indended architecture, making implementation of agents _very_ easy.
https://wippy.ai/en/tutorials/micro-agi It takes 4-5 files to create mini sandboxed AI agent at top of actor model with ability to modify own toolkit while having system guardails and no access to core filesystem.
Bullshit walks.
It's not a dunk that agents can't produce "as fast as can be" code; their code is usually still reasonably fast; it's just often 2-10x slower than can be.
Early on, these code agents wouldn't do basic good hygiene things, like check if the code compiled, avoid hallucinating weird modules, writing unit tests. And people would say they sucked ....
But if you just asked them to do those things: "After you write a file lint it and fix issues. After you finish this feature, write unit tests and fix all issues, etc ..."
Well, then they did that, it was great! Later the default prompts of these systems included enough verbiage to do that, you could get lazy again. Plus the models are are being optimized to know to do some of these things, and also avoid some bad code patterns from the start.
But the same applies to performance today. If you ask it to optimize for performance, to use a profiler, to analyze the algorithms and systemically try various optimization approaches ... it will do so, often to very good results.
Use it as if you're the tech lead managing a fresh hire. Tell it clearly what you want it to focus on and you get a much better result.
Claude’s toy email client gets closer to the speed limit than Gmail does. Why is Gmail so slow? I have no idea.
I asked a cursor agent to do the same for a geotiff to pmtiles converter. It managed to optimize the performance from tens of days to half a day for the case I wanted to solve.
And fyi, jmap is just a protocol for doing email over json & http. It’s not that hard to roll your own. Especially in a web browser.
Would be interesting to see it, did you publish it yet?
Only the client parts. And only the client parts its actually using. JMAP clients can be much simpler than servers. A JMAP server needs the whole protocol. JMAP clients only need to implement the parts they use. Servers also need to parse email message envelopes - which is way more difficult to do correctly than people think. JMAP clients can just use pre-parsed messages from the server.
Anyway, the code is here if you wanna take a look:
https://github.com/josephg/claude-mail
Claude put its JMAP API wrapper code in a child crate (confusingly also called jmap-client).
Live version: https://seph.au/claude-webmail/
Drupal is the future. I never really used it properly, but if you fully buy into Drupal, it can do most everything without programming, and you can write plugins (extensions? whatever they're called...) to do the few things that do need programming.
> The Epilogue: That site has since been ported to WordPress, then ProcessWire, then rebuilt as a Node.js app. Word on the street is that some poor souls are currently trying to port it to Next.js.
This is the problem! Fickle halfwits mindlessly buying into whatever "next big thing" is currently fashionable. They shoulda just learned Drupal...
Wordpress loves to shove php objects into the database (been a good long while since I used it, don't remember the mechanism, it'd be the equivalent of `pickle` in python, only readable by php).
Not sure if they've improved it since I last dealt with it about 15 years ago, but at the time there was no way to have a full separated staging and production environment, lots of the data stored in the database that way had hardcoded domain names built into it. We needed to have a staging and production kind of set-up, so we ended up having to write a PHP script that would dump the staging database, fix every reference, and push it to production. Fun times.
No idea what's used in wordpress, but back in D6 and before, it was common to see it when it would store multiple values for an instance.
Pardon me, and, yes, I know we're on HN, but I guess you're... rich? I imagine a single run like this probably burns through tens or hundreds of dollars. For a joke, basically.
I guess I understand why some people really like AI :-)
This is the biggest bottleneck at this point. I'm looking forward to RAM production increasing, and getting to a point where every high-end PC (workstation & gaming) has a dedicated NPU next to the GPU. You'll be able to do this kind of stuff as much as you want, using any local model you want. Run a ralph loop continuously for 72 hours? No problem.
No that’s a stretch, but firing up a AAA game.
How long time do we have to wait before these people get bored? Or might they actually find what they generate useful and it doesn't all go straight to /dev/null, since seemingly it seems to gain usage, not drop in usage?
At least it gives _something_ back. Until of course we've obsoleted all of them as well.
Most of the AAA games I've paid for sit there in my Steam library and never get played. At least _some_ of the money probably went to those talented people whose work was used for training GenAI and coding models (and yes I say this as someone who has used all of these tools to prototype my own games, and still think human created content is of a much higher quality, just more expensive to produce).
But let's be honest to ourselves, the sort of useless code the GP meant will never ever be used for any of that. The code will never leave their personal storage. In that sense it's about as valuable for the society at large as the combined exabytes of GenAI smut that people have been filling their drives with by running their 4090s 24/7.
I had a broken, one-off Perl script, a relic from the days when everyone thought Drupal was the future (long time ago). It was originally designed to migrate a site from an unmaintained internal CMS to Drupal. The CMS was ancient and it only ran in a VM for "look what we built a million years ago" purposes (I even had written permission from my ex-employer to keep that thing).
Just for a laugh, I fed this mess of undeclared dependencies and missing logic into Claude and told it to port the whole thing to Rust. It spent 80 minutes researching Drupal and "one-shotted" a functional import tool. Not only did it mirror the original design and module structure, but it also implemented several custom plugins based on hints it found in my old code comments.
It burned through a mountain of tokens, but 10/10 - would generate tens of thousands of lines of useless code again.
The Epilogue: That site has since been ported to WordPress, then ProcessWire, then rebuilt as a Node.js app. Word on the street is that some poor souls are currently trying to port it to Next.js.