@penbergi
iAccount based inFinland
About this account
- Account based in
- Finland
- Connected via
- Finland App Store
Account-level information from X, not a live location or the device used for a specific post.
Founder & CTO @tursodatabase; previously @ScyllaDB and Linux kernel. Author of "Latency" (https://nitter.cf/t.co/XWRFq71WaJ).
Espoo, Finland 🇫🇮🇪🇺
Joined January 2010
- Tweets11K
- Following1.2K
- Followers20K
- Likes18.8K
Wait @carllerche you worked on RoR???
Carl Lerche (creator of Tokio, former Ruby on Rails core team) just posted a Topcoat 0.9 update. Worth reading for the author background alone. 🦀
The pitch: make building web apps with Rust as productive as Rails. From someone who's actually done both.
What's new in 0.9:
Shards : server components that re-render when browser-side signals change. Type a character in a search box, the browser sends the signal value, the server re-runs the component against the database and sends back updated HTML. No API layer, no client state management.
Server-push via WebSocket : a live! macro and emit! for streaming UI updates over long-lived connections. Progress bars, chat messages, real-time dashboards, all from the server, in Rust.
Signal-based reactivity without roundtrips : simple state like counters and toggles runs as transpiled JavaScript in the browser. Server roundtrips only happen when you actually need the database.
Toasty (the ORM) also got substantial updates:
update! macro : toasty::update!(user { name: "Alicia", login_count.increment() }) compiles to a single SQL UPDATE with SET login_count = login_count + 1. No load, no save.
Document fields : #[document] on a struct field maps it to JSONB in PostgreSQL, with typed filter support: User::fields().settings().theme().eq("dark").
Polymorphic relations via enums owner: Owner where Owner is User or Team, handled with #[shared] and #[belongs_to] annotations instead of awkward workarounds.
The closing paragraph is the most honest thing in the post: "I don't know where we are going. The world of software engineering is completely different every three months."
🔗 tokio.rs/blog/2026-09-24-top…
#RustLang #WebDev #Tokio #FullStack #OpenSource
I'm working on Turso 0.8 release blog post. Turns out @jussisaur likes @BenjDicken's balls (the animations) so much he wanted us to try out something too.
Pekka Enberg retweeted
Boris's post is the clearest case yet that formal verification is now a practical tool for working engineers, and Claude is a big reason why.
We run this loop on production engines. Three things get right in order to scale this beyond a one-off run. 🧵
I used Opus 5.5 to formally verify the Claude Agent SDK using Lean. A couple short prompts = 16 PRs fixing various bugs and race conditions. Video attached.
TLA+ also works well. I sometimes combine Lean and TLA+ to look for issues around data flow, concurrency, and state mgmt.
I don't know either language well, but Claude is excellent at both. This approach is super useful for formally modeling your code and finding bugs that a human probably wouldn't have spotted.
Is formal verification the future of coding (or at least, bug finding)?
What if your local sandbox was git-aware?
First, run an agent in a sandbox:
$ hmm run -n bug-fix claude
Then merge its commits into your branch:
$ hmm merge bug-fix
Simple.
I've wanted a local coding agent since forever. With Bonsai 2 out with 6 GB weights, I couldn't resist to do something. Fun to see AMD Radeon RX 5700 XT from 2019 do some coding! Need to get me a MacBook M5 Max to see if I can use this for real. github.com/dwim-sh/dwim
I am impressed with what Bonsai 2 can do on an old AMD Radeon GPU with 8 GiB of VRAM! Not really fast enough for local coding, though. Perhaps I just need to buy a new machine...
Perhaps Bonsai 2 is the language model I have been looking for to drive a local coding agent. Some people claim it’s Opus 4.5/4.6 level intelligence that fits in 8 GiB of DRAM. Would run on my crappy ATI Radeon too!
Today, we’re announcing Ternary Bonsai 2 27B.
Based on Qwen3.8 27B, Bonsai 2 27B is 9x smaller than its full-precision counterpart while retaining 98.2% of its aggregate benchmark performance.
Two months after the first Bonsai 27B release, the biggest change is quality. The footprint remains 5.9 GB, but the gap to full precision has narrowed materially, with particularly strong gains in agentic coding, multimodal reasoning, and long-horizon tool use.
Ternary Bonsai 2 27B is available today under Apache 2.0.
Everyone has been saying that a small language model like Qwen3-0.6b is useless for coding tasks. Now that I've played around with it, it seems that way. But I don't understand why. Is it because the larger models remember more details on coding tasks? Or they're not powerful enough to do enough reasoning? Or something else?
How does a large language model run on hardware?
A large language model can feel like magic if your background is in CPU-centric programming. That's because the models combine deep neural network with the transformer architecture with a massively parallel processor, GPU, they run on. Furthermore, although you can express a large language model in a few hundred lines of Python, it calls into large, complex layers of software that are hard for a single person to grasp.
To answer this question for myself, I implemented the Qwen3-0.6B model from scratch, from transformer to ISA simulator, with help from Claude Code as a weekend hack. That is, I implemented the model, the GPU instruction set, a compiler, and a GPU simulator to make every layer small enough for one person to understand deeply. I also have RTL for the GPU in the works to run the system on an FPGA, and perhaps in the future, tape it out to actual silicon just for fun.
What's cool is that you can use it like Claude or Codex, but it runs on the CPU and is therefore fully debuggable and traceable. If you have had trouble connecting the dots between large language models and the GPUs they run on, check out the GitHub repository: github.com/penberg/titania
Turso's transaction tail latency looking pretty decent thanks to relentless optimization work by @Peristocles1 in preparation for his @P99CONF talk.
What are the best books on formal verification I should read? Asking for a friend…
Went back and finished my Viewstamped Replication implementation in Rust. Protocol only, I/O is provided by the caller. Verified with a TigerBeetle-style simulator. Now thinking about doing some verification with Lean...
github.com/penberg/vsr-rs
Pekka Enberg retweeted
Sometimes writing faster software starts with understanding what's happening underneath it.
Whether you're sharpening your C, exploring Rust or Zig, or trying to understand why performance behaves the way it does, these books take you under the abstractions:
• Modern C, Third Edition
• Rust in Action by @timClicks
• Systems Programming with Zig
• Latency by @penberg
All four are included with Manning subscriptions — Annual Pro is 20% off through Sept. 7th: hubs.la/Q04wDVf20
Went back and finished my Viewstamped Replication implementation in Rust. Protocol only, I/O is provided by the caller. Verified with a TigerBeetle-style simulator. Now thinking about doing some verification with Lean...
github.com/penberg/vsr-rs
I love @mitchellh's approach to performance engineering. Make it fast on the low end, and you have something amazing on the high end.