Trampolines and algebraic Fibonacci in Rust

2026-02-23T00:00:00+00:00

In previous articles, we explored tail recursion and the trampoline device in JavaScript and Go as a workaround for missing tail call optimization (TCO).

This article continues the idea, but now in Rust.

Rust is interesting here because it makes the algebraic structure explicit.

In this post, we’ll clarify whether Rust supports TCO, implement a trampoline in idiomatic Rust, write a generic Fibonacci implementation, and finally compute Fibonacci numbers over strings.

Does Rust support tail call optimization?</h2>
Rust does not guarantee tail call optimization. Even if a function is tail-recursive, you must assume that each recursive call consumes stack space.
Why?

Rust compiles via LLVM, which may eliminate tail calls but does not guarantee it.</li>
Rust has deterministic destruction (Drop</code>), which may require stack frames to remain alive.</li>
Rust favors predictable performance over implicit optimizations.</li> </ul> Deep recursion in Rust can overflow the stack. </blockquote> If we want recursion without stack growth, we can use the same workaround mentioned in the previous articles: a trampoline. Return of the trampoline</h2> Instead of calling itself recursively, a function returns a thunk. That is a function describing the next step. A trampoline repeatedly executes these steps until a final value appears. The trampoline</h3> enum Bounce<T> { Done(T), More(Box<dyn FnOnce() -> Bounce<T>>), } fn trampoline<T>(mut b: Bounce<T>) -> T { loop { b = match b { Bounce::Done(value) => return value, Bounce::More(step) => step(), }; } }</code></pre> Despite the name, nothing magical happens here: Done(value)</code> → computation finished</li> More(step)</code> → keep going</li> </ul> The loop replaces recursion. Tail-recursive Fibonacci as state</h2> If we look back at the tail-recursive logic from the first post: (previous, current) → (current, previous + current)</code></pre> Instead of building stack frames, we carry forward state. A generic Fibonacci</h2> Fibonacci needs only an addition-like operation and two seed values. No ordering, no multiplication, not even numbers in the usual sense. In Rust, we can express this precisely. use std::ops::Add; fn fib_thunk<T>(n: usize, f0: T, f1: T) -> Bounce<T> where for<'a> &'a T: Add<&'a T, Output = T>, T: 'static, { match n { 0 => Bounce::Done(f0), 1 => Bounce::Done(f1), _ => Bounce::More(Box::new(move || { let next = &f0 + &f1; fib_thunk(n - 1, f1, next) })), } } fn fib<T>(n: usize, f0: T, f1: T) -> T where for<'a> &'a T: Add<&'a T, Output = T>, T: 'static, { trampoline(fib_thunk(n, f0, f1)) }</code></pre> We chose a 'static</code> trait object for simplicity. This prevents using T</code> that borrows non-'static</code> data. If we parameterized Bounce</code> with a lifetime, we could remove the 'static</code> bound. What does this bound mean?</h3> for<'a> &'a T: Add<&'a T, Output = T></code></pre> It says: references to T</code> can be added together to produce a new T</code>. </blockquote> This is exactly what large mathematical types do: big integers</li> rational numbers</li> matrices</li> vectors</li> </ul> We only read values and create a new result. No mutation required. This code now works for e.g. num_bigint::BigInt</code> without changing a single line of logic. It's the kind of abstraction Rust’s trait system was designed to express. Fibonacci is algebra, not arithmetic</h2> At this point we can state the key insight: The Fibonacci algorithm does not fundamentally operate on integers. It operates on any type whose references support addition. Rust’s trait system allows us to express this algebraic requirement precisely. </blockquote> Mathematically, Fibonacci works for any structure with an addition operation. Rust lets us encode that idea directly in the type system. If Fibonacci truly depends only on addition, then numbers should be optional. Let’s test that claim. A surprising example: Fibonacci over strings</h2> Rust prevents us from implementing: &String + &String</code></pre> directly because of the orphan rule: You may implement a trait for a type only if either the trait or the type is defined in your crate. </blockquote> If both the trait and the type come from other crates, the implementation is forbidden. But we can wrap String</code> in our own type. The Cat</code> type</h3> #[derive(Clone, Debug)] struct Cat(String); impl From<&str> for Cat { fn from(s: &str) -> Self { Self(s.to_owned()) } } impl<'a, 'b> Add<&'b Cat> for &'a Cat { type Output = Cat; fn add(self, rhs: &'b Cat) -> Cat { let mut out = String::with_capacity(self.0.len() + rhs.0.len()); out.push_str(&self.0); out.push_str(&rhs.0); Cat(out) } }</code></pre> Addition now means concatenation: ab + cd = abcd</code></pre>Fibonacci, but with cats</h2> Let’s compute: F(0) = me F(1) = ow</code></pre>fn main() { let result = fib( 6, Cat::from("me"), Cat::from("ow"), ); println!("{:?}", result); }</code></pre>Step-by-step</h3> term</th> value</th></tr></thead> F₀</td> me</td></tr> F₁</td> ow</td></tr> F₂</td> meow</td></tr> F₃</td> owmeow</td></tr> F₄</td> meowowmeow</td></tr> F₅</td> owmeowmeowowmeow</td></tr> F₆</td> meowowmeowowmeowmeowowmeow</td></tr> </tbody></table> The structure follows Fibonacci exactly. Only the meaning of addition changed. The algebra hiding underneath</h2> Notice that the code doesn't care about numbers. By using the Add</code> trait, we've generalized the algorithm into an algebraic structure: (T, +)</code></pre> Any type that defines addition can generate a Fibonacci sequence. Rust’s trait bounds let us express this requirement exactly. This is the FP move: define the algorithm by its required structure, not by a concrete type. What this costs us</h2> While the trampoline saves your stack, it’s not free. You’re trading stack space for heap allocations by boxing a closure on every single step. If you need a high-performance Fibonacci in Rust, you’d use a for</code> loop. We’re doing this for the conceptual elegance and the TCO workaround. The future: explicit tail calls</h2> While we can use trampolines today, there is a keyword for this exact purpose: become</code>. In future versions of Rust, we could potentially replace our Bounce</code> enum and heap-allocated Box</code> closures with a single keyword that guarantees the stack frame is reused: // Potential future syntax fn fib_native<T>(n: usize, f0: T, f1: T) -> T where T: Add<Output = T>, { match n { 0 => f0, 1 => f1, _ => become fib_native(n - 1, f1, f0 + f1), } }</code></pre> It eliminates the performance penalty of heap allocations. Landing on four feet</h2> Trampolines began as a workaround for missing tail call optimization. In Rust, they reveal something deeper. A tail-recursive function is really a state machine in disguise. Once the recursion disappears, what remains is algebra: values evolving under an operation. Fibonacci never depended on integers. We only assumed it did. Rust’s type system lets us remove that assumption and state exactly what the algorithm requires. And once you see that, Fibonacci stops being a numerical algorithm and becomes a structural one. Four architectures, one system 2026-02-20T00:00:00+00:00 Infrastructure waits quietly - until everyone needs it at once. </blockquote> In early 2015, I built a scheduling system that was supposed to replace a shared spreadsheet. It is still running today. During those eleven years, the software was rewritten four times. Not because it failed, not because new technology appeared, and not because performance demanded it, but because reality revealed that the problems worth solving were different from the ones I had originally optimized for. This is the story of how a small prototype for one group of doctors evolved into a long-running production system, and why every rewrite made it simpler. A small problem</h2> The project began with a complaint. My brother, a physician participating in the Ärztlicher Notdienst in a German federal state, was dissatisfied with how shifts were assigned. The regional organization generated rosters using a round-robin scheme based on an alphabetically ordered list of doctors. Administratively simple, but practically frustrating: vacations, family events, and professional obligations were ignored. Doctors spent significant effort trading shifts afterward to make schedules workable. He asked whether doctors could organize the roster themselves. The first users were a single region - a few hundred physicians coordinating emergency duty around one hospital network. The problem looked small. The first attempt resembled little more than a structured alternative to a shared Google spreadsheet. I expected a hobby project. Instead, adoption spread quickly. Other regions joined after hearing how much organizational friction disappeared. The most surprising discovery was not technical at all: a relatively small piece of software solved a coordination problem that had persisted inside a large institution for years. Architecture 1: a prototype that escaped</h2> To build something quickly, I reused a CMS platform I had co-developed years earlier as founder and CTO of a startup. The company had closed in 2002, but the software (a Java-based CMS) remained privately maintained. It was available, familiar, and adaptable. That was enough. The initial system: CMS-based application</li> interpreted environment</li> SQL database backend</li> single tenant</li> </ul> Speed mattered more than architecture. The goal was validation. The prototype worked well enough that it entered production and stayed there for more than two years. Growth exposed its limits. Additional regions required isolation of users, schedules, and workflows. Multi-tenancy was unavoidable. The first real rewrite began. Architecture 2: doing it properly</h2> In December 2017, I rebuilt the system using a conservative and well-understood stack: Kotlin on the JVM</li> Ktor 0.9.5, one of the final pre-1.0 releases</li> Tomcat application server</li> JDBC persistence</li> MySQL database</li> </ul> The objective was straightforward: transform a successful prototype into a maintainable multi-tenant system. The rewrite itself was uneventful. The system entered production and operated reliably for about a year. Then the system encountered its first real failure. The incident</h2> At the start of a booking phase - the busiest minutes of the entire scheduling cycle - the database became corrupted. The shift table became unreadable. A backup system existed and functioned correctly. Recovery took roughly fifteen minutes. Technically acceptable Operationally disastrous. During booking openings, hundreds of doctors attempt to reserve preferred shifts simultaneously. Fairness depends on responsiveness in those first minutes. A fifteen-minute outage destroyed that assumption. Shortly after recovery, the corruption happened again. The failure revealed something unexpected: The problem was not availability. The problem was recovery time. Architecture 3: removing the database</h2> In December 2018, persistence moved from a relational database to the filesystem. Recovery became an atomic file replacement. Instant. This eliminated the dominant failure mode but transferred responsibility for consistency into the application itself. Access to tenant data had to be synchronized: reads remained concurrent,</li> writes were serialized per tenant,</li> requests occasionally waited during heavy activity.</li> </ul> Latency increased slightly but remained below 500 ms even during peak load for the largest region with approx. 500 participants. The optimization target had changed. Before</th> After</th></tr></thead> maximize concurrency</td> minimize recovery time</td></tr> database-managed consistency</td> application-managed consistency</td></tr> complex restore</td> instant recovery</td></tr> </tbody></table> The filesystem was not superior in general. It would have been the wrong choice for tens of thousands of users. But it was superior for this workload. History as a side effect</h2> Each modification wrote a new backup file alongside the primary data file. Over a booking season: approx. 500 doctors participate</li> roughly 3,000 shifts exist</li> a little more than 4,000 history files accumulate through cancellations and rebookings</li> </ul> The database version also logged activity - but those logs vanished together with corrupted data. Filesystem backups, copied asynchronously to independent storage, survived runtime failures. The improvement was not absolute safety but separation of failure domains. Backup moved outside the request path. The system unintentionally gained a transparent history of decisions. Stability</h2> After the filesystem rewrite, the system stabilized. It runs today on a Netcup Root Server (4 cores, 16 GB RAM, Ubuntu Linux), operating below 10% CPU during peak booking phases. Memory usage remains under 8 GB. Users rarely noticed deployments. Interfaces remained stable. Updates were scheduled during off-hours; writes paused briefly while reads continued uninterrupted. Major incidents disappeared. Only one long-uptime Ktor session bug required introducing a scheduled reboot every couple of weeks. Otherwise, the system simply ran. For years. Architecture 4: when time becomes the problem</h2> The next rewrite was not triggered by failure but by aging dependencies. The Kotlin/Ktor/Tomcat stack depended on early ecosystem libraries. Some repositories disappeared. Builds survived only because I backed up my local Maven .m2</code> cache. The application became locked to: Ktor 1.6.x</li> old dependencies</li> Tomcat 8</li> </ul> Upgrading further was impossible. The system was stable - but frozen. Evolvability had vanished. In December 2025, I performed the final rewrite: modern Kotlin</li> current Ktor</li> embedded Netty server</li> standalone deployment</li> </ul> Tomcat disappeared. WAR packaging disappeared. Dependency surface shrank dramatically. Deployment became a simple scripted restart of a systemd</code> service. Functionality remained unchanged. The rewrite restored the ability to evolve. What changed and what didn’t</h2> Across eleven years, nearly every technical layer changed. The domain did not. Doctors booking shifts fairly among themselves remained constant. The core model survived four complete rewrites almost untouched. Each rewrite removed a layer whose original benefit had expired: Rewrite</th> Removed Constraint</th></tr></thead> CMS → Kotlin</td> framework limitations</td></tr> Database → filesystem</td> slow recovery</td></tr> Tomcat → Netty</td> dependency lock-in</td></tr> </tbody></table> The system did not become more sophisticated. It became smaller. Eleven years</h2> Three things surprised me. First, how a small coordination problem could spread organically once solved well. Second, that serious failures appeared where I least expected them - not in complex logic, but in infrastructure assumptions. Third, that longevity rewards simplicity more than sophistication. Long-lived systems optimize for properties that are easy to underestimate at the beginning: recoverability matters more than uptime,</li> operational simplicity matters more than architectural completeness,</li> evolvability matters more than technological modernity,</li> smaller dependency surfaces age better.</li> </ul> The project began as an alternative to a shared spreadsheet for one group of doctors. It still runs today - simpler than before, and closer to the problem it was meant to solve. Software longevity, I learned, is less about choosing the right architecture at the beginning and more about removing what turns out not to matter. Adding audio to your blog 2026-02-11T00:00:00+00:00 There are two practical ways to add audio to a blog: use the native <audio></code> element or render a custom player with JavaScript. The Zola</a> theme Zolarwind</a> provides two shortcodes that map to those choices: audio_simple</code> uses the native element, audio</code> uses a custom player. Both are usable as-is, and the choice comes down to how much control you want over the player UI. The baseline native <audio></code></h2> You get built-in controls and good accessibility. If you are fine with browser-native styling, this is the fastest path. <audio controls> <source src="audio.mp3" type="audio/mpeg"> </audio></code></pre> </audio> The tradeoff is consistency. Browsers style the element differently, and you get limited control over the UI. audio_simple</code> shortcode</h2> This wraps the native element and keeps the setup small. It uses no JavaScript, like the baseline audio element, but adds a small amount of CSS for layout. {{ audio_simple( src="audio.mp3", title="Audio in your blog", year="2026", artist="Female Speaker", label="Blog of Thomas Weitzel") ) }}</code></pre> Audio in your blog</h2> Female Speaker | Blog of Thomas Weitzel | 2026 </div> Your browser does not support the audio element.</audio> </div> Custom player</h2> If you want a consistent player UI across browsers, the audio</code> shortcode renders a custom player with JavaScript. The native <audio></code> controls are not used; the UI is fully custom. {{ audio( src="audio.mp3", length="0:48", title="Audio in your blog", year="2026", artist="Female Speaker", label="Blog of Thomas Weitzel") ) }}</code></pre> Audio in your blog</h2> Female Speaker | Blog of Thomas Weitzel | 2026 </div> Loading ...</div> 00:00 | 0:48</div> </div> </div> </div> </div> </div>

Trampolines and algebraic Fibonacci in Rust

Return of the trampoline</h2>
Instead of calling itself recursively, a function returns a thunk</strong>. That is a function describing the next step. A trampoline repeatedly executes these steps until a final value appears.</p>

Four architectures, one system

Adding audio to your blog

Audio in your blog</h2>
Female Speaker | Blog of Thomas Weitzel | 2026</p> </div> Your browser does not support the audio element.</audio> </div>

Audio in your blog</h2>
Female Speaker | Blog of Thomas Weitzel | 2026</p> </div>

Loading ...</div>
00:00 | 0:48</div>

</div> </div> </div>
</div> </div>

Trampolines and algebraic Fibonacci in Rust

Return of the trampoline</h2> Instead of calling itself recursively, a function returns a thunk</strong>. That is a function describing the next step. A trampoline repeatedly executes these steps until a final value appears.</p>

Four architectures, one system

Adding audio to your blog

Audio in your blog</h2> Female Speaker | Blog of Thomas Weitzel | 2026</p> </div> Your browser does not support the audio element.</audio> </div>

Return of the trampoline</h2>
Instead of calling itself recursively, a function returns a thunk</strong>. That is a function describing the next step. A trampoline repeatedly executes these steps until a final value appears.</p>

Audio in your blog</h2>
Female Speaker | Blog of Thomas Weitzel | 2026</p> </div> Your browser does not support the audio element.</audio> </div>