Rust at the Core - Accelerating Polyglot SDK Development - InfoQ

BT

InfoQ Software Architects' Newsletter

A monthly overview of things you need to know as an architect or aspiring architect.

View an example

Enter your e-mail address

Select your country

Select a country

I consent to InfoQ.com handling my data as explained in this Privacy Notice.

We protect your privacy.

Close

Helpful links

About InfoQ

InfoQ Editors

Write for InfoQ

About C4Media

Diversity

Choose your language

En

中文

日本

Fr

July25,2026

Online InfoQ AI Engineering Certification

Production AI calls on retrieval, agents, evals, and infrastructure, checked with peers.<br>Register Now.

Aug13,2026

Online InfoQ Architect Certification

Distributed systems, decentralized decisions, platform engineering, and AI architecture.<br>Register Now.

Nov16-20,2026

QCon San Francisco

What's working across AI, architecture, and leadership, from the teams doing it.<br>Register. Early bird ends July 14.

Apr13-16,2027

QCon London

What early-adopter teams have proven in production, across 15 engineering tracks.<br>Register. Early bird ends July 14.

InfoQ Homepage

Presentations

Rust at the Core - Accelerating Polyglot SDK Development

Development

Rust at the Core - Accelerating Polyglot SDK Development

Like

Reading list

View Presentation

Vertical

Horizontal

Full

Speed:

1x

1.25x

1.5x

2x

Download

Slides

39:46

Summary

Spencer Judge discusses the architectural pattern of building a shared core in Rust with language-specific layers on top. Drawing from his work on Temporal's SDKs, he shares lessons on navigating FFI boundaries, bridging async concepts, and managing memory safely. He explains the limitations of native extensions and how emerging tech like WebAssembly can streamline cross-language architecture.

Bio

Spencer Judge has worked on tools, libraries, and products for other Developers for over a decade. He has a longstanding interest in, and passion for, learning and developing in multiple languages. Currently he leads the SDK team at Temporal, which develops libraries providing durable execution in 8 languages.

About the conference

Software is changing the world. QCon San Francisco empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

Transcript

Spencer Judge: Spencer. I manage the SDK team at Temporal. Today I'm going to share with you some pretty practical advice about how you can potentially adopt this particular architectural pattern that I implemented at Temporal that has really served us very well, where you have a shared core written in Rust, and then a bunch of language-specific layers built on top of that. That's what we're going to talk about today.

A Messy State Machine Diagram

This first slide represents something called a local activity in Temporal. The important thing to take away from this slide is that it's complicated. This state machine diagram is backed by about 800 lines of code. Who would want to write this seven times in seven different languages? Any takers? No? I was hoping at least one of you would raise your hand, because then I'd be like, good, you like suffering. I too enjoy suffering. No, realistically, you obviously don't want to do that. To put it into context, here is the rest of the state machines. That's about 7,000 lines of code that this whole thing represents. In an overall repository, that's about 10 times that big, about 70,000 lines of code. This logic can't live on the server side. It has to be in the SDKs that our users take as dependencies. Again, we want to provide SDKs in a bunch of different languages. You don't want to write that seven times. That's not going to work.

Why Does Temporal Have This Problem?

Why does Temporal have this problem? Why am I showing you a bunch of messy state machines? Like I just mentioned, we want to offer SDKs in a bunch of different languages. We need to meet our users where they are. We can't really expect them to adopt some unique language that we would make up just for the purpose of writing workflows. You probably are familiar, there's a lot of products on the market that do exactly that. They have some graph-based DSL or whatever, and you inevitably run into limitations with that, and no one wants to learn them. We offer SDKs in a bunch of different languages to meet people where they are.

What is Temporal? We're a platform for durable execution, which is to say you write some code, we take it, we make it resilient in a bunch of different ways. In order to enable that capability, our users, they write some code in their language of choice. They write it against our various APIs, and we do magic and make that durable. Providing all of these durability guarantees is the reason that there was so much code in...