Topcoat v0.6 is out! Concurrent component rendering, URL generation, more UI components, and a lot more. Read all about it: github.com/tokio-rs/top...
Carl Lerche
Carl Lerche
@carllerche.com
I do stuff, I say stuff. It's serious business.
394 followers66 following109 posts
Three years ago, trying to use Rust for web apps was crazy talk. Today is very different than three years ago. Announcing Topcoat, a batteries-included Rust framework for building reactive web applications: tokio.rs/blog/2026-07...
Carl Lerche reposted
Carl Lerche reposted
Carl Lerche reposted
About a month ago I gave a talk at Tokioconf on what shared-nothing and work-stealing are, and how migrating our stack from nginx+lua to rust and tokio massively improved our performance ...because of work-stealing! check it out the recording here: www.youtube.com/watch?v=6QN3...
Carl Lerche reposted
The TokioConf 2026 talks are now available on YouTube: youtube.com/playlist?lis.... Also, TokioConf 2027 will be April 26 & 27, 2027 in Portland, OR. Save the date!
Carl Lerche reposted
my futurelock talk from #tokioconf is up! check it out, enjoy the story of a nightmare bug we saw at @oxide.computer
A big Toasty release (async ORM for Rust)! The relation declaration API improved, added support for multi-step relations, update! macro with ops like increment / add / push, and support for Turso. github.com/tokio-rs/toa... .
This undercurrent within the #rustlang community (and others) has to stop. The attacks on people simply because they are using developer tools that make them productive is 100% out of line. I can respect the anti-LLM arguments, but let's agree to disagree, respect each other as humans, and move on.
prepping for rustweek, bracing to cross paths with all the people who decided to call me a booster/traitor/fascist for using LLMs, the people who blocked me without saying anything, the people who maintain lists of who to shun. a lot has happened in a year that I'm not done grieving about.
I posted a bit about how I use LLM tools to boost productivity with a "complex Rust library" here: reddit.com/r/rust/comme.... If I motivate myself to do os, I will write some blog posts about my work flow.
I wrote a bit more about the release here: tokio.rs/blog/2026-05...
Released Toasty v0.6 (ORM for Rust). Highlights include `#[deferred]` to avoid having to load all fields all the time, `.select(...)` specify exactly which fields you want, and support for `Vec` fields, which is the start towards full "document" modeling. github.com/tokio-rs/toa...
I think the crucial questions are a) is it *worse* than it was before, safety wise b) how will correctness trend over time starting from now.
#30719 is a bit terrifying — they didn't even vibecode a CI check for Miri? Really concerned this is going to seriously harm Rust's reputation github.com/oven-sh/bun/...
I think the crucial questions are a) is it *worse* than it was before, safety wise b) how will correctness trend over time starting from now.
#30719 is a bit terrifying — they didn't even vibecode a CI check for Miri? Really concerned this is going to seriously harm Rust's reputation github.com/oven-sh/bun/...
Ferris by Dzuk, licensed CC BY-NC-SA: weirder.earth/@dzuk/102711...
Released Toasty v0.6 (ORM for Rust). Highlights include `#[deferred]` to avoid having to load all fields all the time, `.select(...)` specify exactly which fields you want, and support for `Vec` fields, which is the start towards full "document" modeling. github.com/tokio-rs/toa...
I can too, the answer is: YES! (kidding). Nicholas is great, so reach out to him if you need help with Rust.
I can help you assess if Rust is a good fit for your team or company, guide your Rust adoption, and help develop a Rust strategy. I have availability pretty much immediately, get in touch for a free chat: nrc@ncameron.org, or www.ncameron.org for more info.
The most surprising thing to me is the Rust port compiles faster than the Zig repo. I thought Zig focused on compilation speed. Does someone know why this would be? xunroll.com/thread/20530...
Carl Lerche reposted
✨AI helps teams build faster. But sooner or later, something in production will behave unexpectedly -and that’s where visibility matters. On Netstack.FM Ep.37 we talk with Jess Izen and Russell Cohen from AWS on Dial9, a tool for seeing inside Rust and #Tokio apps. 🎧 netstack.fm#episode-37 #RustLang
Great talk, which led to this follow up issue and discussion. github.com/tokio-rs/tok...
Using Tokio for CPU-Bound Tasks (Works Really Well) youtu.be/FeqRdDG1Y7g (has nothing to do with AI, just scheduling and Database plans)
Carl Lerche reposted
Using Tokio for CPU-Bound Tasks (Works Really Well) youtu.be/FeqRdDG1Y7g (has nothing to do with AI, just scheduling and Database plans)
What if maintainers for OSS projects said: "If you want security patches in a timely fashion, you **must** pay a subscription. Otherwise, we will just disclose the issue, then make the patch public in ~30 days". You would all lose your minds, but it also points out you *expect* work for free.
I'm just going to say it, I really don't like the "how do we make OSS sustainable" framing. OSS is already sustainable. The only thing not sustainable is users expecting a free lunch (support, LTS, bug fixes, ...). As a user, you are responsible for your OSS usage. Fork/patch if you need to.
Every time an OSS maintainer adds a "funding" notice to their post-install, deletes their package, or doesn't merge a bug fix, and "the community" gets angry and calls it a bad action, that's the problem.
I'm just going to say it, I really don't like the "how do we make OSS sustainable" framing. OSS is already sustainable. The only thing not sustainable is users expecting a free lunch (support, LTS, bug fixes, ...). As a user, you are responsible for your OSS usage. Fork/patch if you need to.
Every time an OSS maintainer adds a "funding" notice to their post-install, deletes their package, or doesn't merge a bug fix, and "the community" gets angry and calls it a bad action, that's the problem.
I'm just going to say it, I really don't like the "how do we make OSS sustainable" framing. OSS is already sustainable. The only thing not sustainable is users expecting a free lunch (support, LTS, bug fixes, ...). As a user, you are responsible for your OSS usage. Fork/patch if you need to.
Carl Lerche reposted
I don't have a totally coherent view on this, but having spent time in this space, OSS funding is just *weird*. Users treat popular projects like products, and how software gets done somewhat reinforces that (packaging, "the ecosystem", etc.). A very tiny # of people do (or even could!) make money.
I'm just going to say it, I really don't like the "how do we make OSS sustainable" framing. OSS is already sustainable. The only thing not sustainable is users expecting a free lunch (support, LTS, bug fixes, ...). As a user, you are responsible for your OSS usage. Fork/patch if you need to.
Carl Lerche reposted