• Jan-Erik Rediger on RustFest
• Lucio Franco on the Tonic gRPC framework

Jan-Erik Rediger on RustFest

Ben Striegel: Welcome to Rustacean Station podcast. I’m here with a micro- interview from RustFest. We’re here in a cafeteria, using borrowed audio equipment. So I apologize for the audio quality. You might hear people walking in and out as they mistakenly think this is the dining room. In fact, it is not; it is a recording studio. Very important, not a cafeteria at all. I have with me right now, Jan-Erik Rediger. “Rediger?”

Jan-Erik Rediger: “Rediger”.

Ben: I can’t do it at all. “badboy” is your handle?

Jan-Erik: “badboy” is the handle on the Internet, yes.

Ben: Great. And you are a founder of RustFest.

Jan-Erik: Yes, I’m one of the co-founders.

Ben: Who else is a co-founder?

Jan-Erik: Let’s see, so still around is flaki. He founded— So the very first RustFest was in 2016 in Berlin. It was with a bunch of friends— Florian was the one that initially asked me if I wanted to do a Rust event.

Ben: Florian Gilcher.

Jan-Erik: Florian Gilcher. He asked me back then if I wanted to do an event, and I said yes. So we set off to create what became RustFest, and then a bunch of people that we knew joined in. Flaki is still with us, and still one of the main organizers here. Florian dropped out as the core organizer of the conference this year, but he’s back on stage as a speaker for the first time at the conference he founded. And then we have a bunch of people that are now not part of the yearly organizer team anymore. Ben from Berlin. Johann, my colleague at Mozilla. I’m trying to think who else was there. We were a few more people, and I, unfortunately, I can’t remember who all was there.

Ben: And it was in Berlin the first year.

Jan-Erik: Yes, 2016 in Berlin.

Ben: And it moves around a lot, all over Europe.

Jan-Erik: Yes, so we set out with this conference, to make it as a community conference. And our initial plan was not to stay in Berlin, because we started in Berlin because that’s where we were. And for doing a conference, you need to have people in the city you’re doing it. Otherwise, it’s incredibly hard to do it. So we did it there, but our idea always was to move it around, so we get to other communities. The fact that it happened just six months after the first one already was a happy accident. It moved to— so we started in 2016 in August or September, and we had the second edition in Kiev just six months later, around March, that’s the year after.

Ben: Is that a regular thing? Is it kind of a tradition now, has to be every six months? It’s a pretty tight schedule.

Jan-Erik: It was again a happy accident that it happened every six months since then. So we had six months later, off to Kiev. We went to Zurich, because we had people that wanted to take it there. And then just six months after Zurich, we already moved to Rome— no, to Paris first, and then to Rome in the same year. So it became a six month cycle for the first five iterations. But none of the organizers are doing that as their main job, and doing a conference every six months is neither sustainable for the conference, nor for the organizers that have to do it. So after Paris, we— no, after Rome last year, we sat down and said, We’re not going to do another conference that quickly. We simply don’t have the power to do it. So we took the whole year to now, run here in Barcelona after a full year off, winding down and winding it up again.

Ben: That sounds great. I mean, I think even once a year is still a fantastic effort. I know, also doing a new place every time, you can’t just rely on using the same venue as last time, or the same organizers as last time. You need people who are local, and in Europe, people who speak the language, who are local and care about Rust, and that kind of thing.

Jan-Erik: There are definitely tons of barriers that make this conference organization the way we do it especially hard. Moving from place to place definitely means we always need to look for new venues. It always means we need to adapt to the new venues, and none off the venues is perfect for what we set out to do. We by now have a few vendors that we can reuse across Europe. So we do pay some vendors to do stuff for us. For example, we always have recordings of all the talks, and for the past— for the first edition, and then the past two editions, we used the same company for doing that for us, because we trusted them. They were very reliable and they were willing to fly around Europe as well. But we need to adapt to every new location. And especially the language barrier becomes a problem from time to time.

Ben: And will it be, kind of, next one, also, one year from now, or is there—?

Jan-Erik: It will most likely not be a full year until the next one. It will probably be shorter, but that’s about as far as I will go in this interview.

Ben: So you won’t tell me where the next one’s going to be. It’s not locked in yet, I imagine.

Jan-Erik: The next one, the way we usually do is, we involve new people for the next iteration or edition, as we call it, in the organization already. So we do have people involved already from the next team, and they will take it to stage tomorrow at the second day of the conference to announce where it will happen.

Ben: Oh, so you announce at the very end.

Jan-Erik: Yes, we do announce it at the very end, to meet the— get the hype up again for next year.

Ben: Perfect. Yeah, I want to suggest Amsterdam, but only cause I want to go there at some point in my life.

Anyway, so— look at my list of questions right here. What is it like? Like, so it does it begin— how far in advance do people begin organizing, or— actually, I think I’ve seen a timeline, possibly online, of what you all expect. That you have the milestones, say, you hit this milestone, then this milestone, by a certain point ahead.

Jan-Erik: So one thing we did after the edition, the Rust fast in Rome, was we sat down and we wrote down a timeline of what we think would work to organize a conference. With specific steps that need to happen on essentially a monthly basis because, it was the lookout into like, 8 to 12 months in the future. Looking at timescale of a month is what you can predict the best. So we set out on when certain work needs to start. With the way it worked up until last year, with the six month cycle, it meant that we essentially didn’t have downtime between the conferences. It takes at least six months to do a proper conference of this size, to organize the venue, to actually have an organization in the country, and in the city you want to do this in. And then took it all the vendors in, to get the CFP open, and get people to apply. So there’s at least a six month cycle that you need for the full preparation.

Ben: Yeah, it sounds like you might have been actually organizing the next conference before the— or like, the one coming up before the one about to happen.

Jan-Erik: There’s definitely overlap. And that’s why we always have people in the cities we’re doing it in, because these people are important to scout the venues, to scout the vendors we use for catering, for maybe live recording or whatever additional stuff we need. So the people in the cities we’re going to need to do this stuff for us, and then we have a small team that’s now moving around to all conferences, and essentially helping them out. That’s also my role, given that I run my fifth of these conferences now, out of the total of six, is that I have a very broad overview of what needs to happen. But the work is not all on my shoulders. I can delegate this work and make sure that it actually happens.

Ben: And it seems like it’s actually pretty anarchic, almost. I have been in the Telegram channel, I think once, that is used for at least some kind of collaboration or coordination, and it’s kind of just a big, giant echo mess of people talking all the time. I had to at some point mute it, because I was, like, I can’t take this any more.

Jan-Erik: We don’t have a public Telegram channel. We do know that there’s an unofficial RustFest Telegram channel. Maybe we’re—

Ben: Possibly. This was a while back. This was a year or two ago.

Jan-Erik: It might be, I don’t know. It’s not that archaic inside. It’s definitely clear that none of us is a professional event manager, and we’re doing this on top of our paid work that most of us are doing, so there’s definitely things that are working in a rather crude way because off the amount of time everyone can spend.

Ben: I think it works out well. This in my first RustFest, but having a great time so far. So I mean, it doesn’t show that you aren’t professional event organizers.

Jan-Erik: That is absolutely our goal. To make it a conference that, like, is very, very good in what we provide to the attendees, and we want to make it a very nice experience for everyone. I can guarantee you, we fixed a lot of problems that the attendees never saw today. The fact that they don’t see it is because I have a team of, now 15 people behind me that fixed these problems before it affects the attendees.

Ben: Very nice. And that’s what a professional manager would do for an event. So maybe you could at some point quit software and sell your services as an event coordinator.

Jan-Erik: I thought about that. I actually thought about doing, like, this more as part of my profession, but right now I do enjoy it so much because it’s also not my job. I do like to see 400 people turn up at these conferences and really enjoy it. But I couldn’t think about doing this every day because it is very hard and stressful work, especially in the last weeks before the conference.

Ben: I think even too, like, you mentioned the schedule that you made, and I know other conferences like the— I interviewed someone for the Colorado Gold Rust Conference this year, who used that schedule to plan their own conference, and so it’s very helpful. Even people who aren’t in Europe, or, even for the communities, I imagine. You’ll need to be a Rust person to benefit from all this stuff.

Jan-Erik: This is a thing we also set out. We do know we now have a lot of people with a lot of experience in organizing events. RustFest grew to a conference with over 400 attendees. But what we tell other people is that if you gather 20 or 50 people, that can be a conference.

Ben: That’s true.

Jan-Erik: And you should make it your own conference. There are things in how you can make sure this conference runs good, and so we are trying to do— to write down our experiences and provide resources for others to run these events, and also be available for these people. If they have questions. If they’re running into trouble, to ask people that already dealt with these problems. Where they don’t need to hire a full event manager to make it all happen.

Ben: Great. Do you want to say anything else before we go? Like anything else about RustFest, or any last words?

Jan-Erik: I just hope that everyone enjoys RustFest on the second day. And also, RustFest is actually a four day conference. We also have the impl days, in its fourth iteration now. So this conference is going on until Tuesday, so people will stick around to hack on Rust, to talk to each other, to build very cool stuff, to maybe improve Rust documentation, to improve Rust projects. So I’m just hoping that a lot of people will take this, not as a finished thing, but like, as a stepping stone to also improve Rust and the community.

Ben: All right. Well, thanks a lot, Jan-Erik.

Jan-Erik: Thank you.

(Musical break)

Lucio Franco on the Tonic gRPC framework

Ben: Welcome to Rustacean Station, live in a sense, from RustFest. Everyone just says live. I can’t just not say live. I’ve always wanted to do that. So I am here with Lucio Franco. Is that your actual name, or only your tag?

Lucio Franco: No, it is my real name. “Lucio” Franco, actually.

Ben: “Lucio.”

Lucio: It’s Italian.

Ben: Italian, Okay. And you work on Tower and Tonic.

Lucio: Yeah. So I’m a core contribute to the Tokio project, which also contains the Tower Hyper project, and then the Tonic project, which is built perched on top of the entire stack, there. It’s like the tip of the top.

Ben: And to give the extremely high level overview, Tower is kind of like a way of making a foundation for middleware for services, quote unquote, in Rust, where service could be many things. and then Tonic is a gRPC framework, would you call it?

Lucio: Yeah, so it’s a gRPC implementation that is built on top of Tower. So it uses Tower as its abstraction layer. Tower is a— it can do many— play many roles. It can be a middleware layer. It could be an actor framework. All in all, it is just a way to handle async request to response. And it’s something that we— I use at work. It’s used very heavily in the Linkerd proxy, and has been kind of growing alongside the Tokio project as kind of the higher level abstraction. And Tonic is kind of our first real project that really shows the power of Tower.

Ben: Okay. And could you also talk about what gRPC is.

Lucio: So, gRPC, I believe the G stands for “general” RPC framework.

Ben: Not Google, as is so common these days?

Lucio: I don’t think so.

Ben: Okay.

Lucio: It could be— actually I think every release of gRPC has a different definition for what the G means, actually. I think there’s a doc inside the main repo that has that—

Ben: A mapping. There we go.

Lucio: Yeah, and so gRPC is just a general RPC framework, remote procedure call, pretty much, allowing you to call a function on a remote computer somewhere else. And the main idea is that it has very strong language interop. So I can define a service in the protobuf, or a protobuf file, which is an encoding format. But it allows you to define an interface, kind of like a trait, and then you could have different codegen units, that can build, create code in what— Go or C or Rust is what tonic does, and each of them have their language specific implementation, but they can talk to each other. It’s all done over HTTP/2. So it’s built on top of the strong base that we have with hyper, and has a large feature set. So supports things like bi-directional streaming and, things also just like regular unary calls and TLS and all the things you would want when you’re really communicating with another server.

Ben: And so it would be used for maybe microservices, that kind of thing.

Lucio: Yeah, so it’s used very heavily for microservices. Especially, where maybe you have different languages or different teams using different languages, and your service might be, like, the contract that kind of glues together your entire microservice architecture. It’s used very heavily in databases. It’s starting to be used even to replace things like GraphQL and HTTP REST, where you can call it from the browser, and use like— if you’re implementing, like, a front end for something, you might use gRPC for it.

Ben: It’s like a standard, then?

Lucio: Yes, so gRPC is basically a standard. There’s a protocol, it’s like a giant markdown file just defines it.

Ben: Okay.

Lucio: It’s usually on top of HTTP/2. It is also encoding agnostic. So I’ve mentioned protobuf earlier, but there is support for FlatBuffers and JSON, and really any type of encoding format you want. Obviously, the other languages need to also have that encoding format. So generally protobuf is the, like, de facto one, that is, kind of, that you think of them together. But we’re starting to see a lot more usage with things like FlatBuffers, starting to be more common. Yeah.

Ben: Okay. And you mentioned Tonic as kind of the flagship for showing off what Tower can do. And then Tokio— is tokio a dependency of tower?

Lucio: Not directly. There is really only a couple places, I think in the timeout module, we use the tokio timer. And then there is one abstraction we have, that abstracts creating connections. So, like, you know, maybe connecting to a server and that is bounded by the IO traits that we have in tokio. And yeah, so the goal of Tonic when I first started writing it— so Tonic replaces tower-grpc. So that’s where the original Tower kind of thing was. And tower- grpc was originally an experiment that Carl had written, I believe a year, year and a half ago, alongside his— the HTTP/2 implementation that hyper has, to allow the Linkerd proxy to talk gRPC for the service mesh microservices architecture. But we never got the chance to really get it to a point of polish before we had to update everything to async/await. And so— and the same thing with Tower. Same story. Tower’s a bit difficult to use right now, because there’s not much documentation. And this was unfortunately because we’d finally come to an agreement about how we wanted everything to look, like, everything from how you might want to build services together to, you know, yes, the service trait is what we like. And then we had to update everything. And so we didn’t— we kind of got, like, sniped right there from really finishing it. Just a bit unfortunate, cause I was really excited to, kind of, get, like, I thought it was really— I think it’s very cool, and I was very excited to get it out there. And so once we kind of got the most majority of things moved, I was decided that, you know what? Now is the time to really show people what this entire technology stack that we’ve been working on can do. And so that was the goal of Tonic, was to make something that— Tower’s not very accessible to people in general. It’s hard to use if you don’t— if you haven’t written tons of Tower services than you might be very, like, to spend a lot of time trying to figure out how it all fits together. I know I did when I first started learning it. So Tonic’s goal was to, kind of, provide a reference implementation. But also a new gRPC implementation that uses async/await and David’s async-trait crate as well. So you can write services, or service-side services very easily and very naturally.

Ben: David, who’s that?

Lucio: David Tolnay, sorry, or dtolnay on GitHub, I believe it is. He has a really awesome crate called async-trait, which allows us to kind of, in a sense, simulate what GAT might do, or generic associated types—

Ben: —Essentially use async keyword in trait methods, which is not currently supported but it makes it seem supported if you use this crate of David’s.

Lucio: Yes, it makes it feel like— Yes, magical.

Ben: That’s great.

Lucio: It is awesome. And so, the goal of, kind of, Tonic was really kind of make these things accessible and so people could start really building things on top of async/await. Currently, actually, Tonic doesn’t really show much of Tower, like to the user themselves, but internally, the transport layer has a very, what we would call a thick client, that Tower provides, and using the different Tower services. And the goal for that was to hopefully upstream things into Tower, but also to give a reference for people, like, here’s how I would write a client for building on top of Tower services that might provide things like load balancing and retries and timeouts.

Ben: And you said that Tower isn’t currently very well documented. Is Tonic documented?

Lucio: Yes, Tonic is documented. We actually have— I’m very proud of the docs that I wrote for the actual crate, but we also have two tutorials, and about, I think six examples showing off everything from a very basic hello world greeter thing, to talking to Google Pub/Sub and listing all the topics, really showing the full feature set that we have in Tower. Yeah, Tower right now doesn’t have much of a doc— and we’re still in kind of this alpha phase, like we are with Tokio, hoping to get out of that soon, really. But there’s a lot of things in the stack we need to finish.

Ben: Does renaming from Tonic to Tower, from tower-grpc to tonic kind of imply that you want it to be agnostic over the like, underlying service layer, or that you want to separate the projects some or just, why?

Lucio: I think in general the philosophy we, kind of, are going with is, Tower is generally just the abstraction. Right? Like a high level abstraction around these things, doesn’t really know about HTTP, doesn’t know about what type of request. In fact, all the requests and responses in the entire tower repository with all the middleware, have no idea what type of request is. It’s all generic. And so it doesn’t really make sense to tie it directly to something. And so we wanted to kind of make Tower its own kind of abstraction and then things like Hyper, instead of calling it what, tower-http or whatever, it’s just going to be called hyper as it was before, is going to now have service implementations, with the new version of it. And Tonic kind of follows that as it lives on top of Hyper.

Ben: And is Tonic, it fully async/await compatible right now? Is it using the new futures?

Lucio: Yeah. It runs on stable. It uses the new futures. It supports anything that you’d want to do with the new futures that is available in stable currently.

Ben: And is it using, like, the alpha releases of tokio and tower underlying it?

Lucio: Yes. So right now it’s kind of pinned to certain tokio versions. There’s a lot of API shift going on right now. Tokio is currently consolidating— before, we had, like, 10 crates, everything that was, like, TCP to like, UDP, to file system stuff, to the reactor. Now we’re kind of merging it all together, and because we’re doing all that shifting, we want to kind of like, wait to kind of get the new version out before we update the whole stack. So I’m hoping end of month we will have, like a proper version out which will allow us to iterate without these very—

Ben: Proper version of—?

Lucio: Like, Tonic, Tokio, Hyper, Tower—

Ben: All of the— all three of those.

Lucio: Mostly I don’t want to go and release 15 crates again, cause it’s exhausting.

Ben: Yeah.

Lucio: So we’re kind of waiting just to get the last little, like, push over the final line, and get everything done. So hopefully end of the month we’ll have 0.1 releases of tonic, which will be built on top of the new scheduler that tokio provides, and some of the improvements we’ve done to the underlying things, like bytes and mio.

Ben: Nice. Are you actually using Tonic for your company?

Lucio: Not yet. We use a lot of Tower, actually, almost all of our code, most everything in our code base uses some form of Tower something. But I think in the future we’ll probably be using something like Tonic to do— the product’s called Vector. So Vector to Vector communication. We might be using it for that. Mostly for me, I was just very interested in gRPC. And I think also, the Rust community deserves a proper implementation. There are a couple other implementations, mainly, the biggest one’s grpcio, which PingCap has provided. But that is just a wrapper around the C++ implementation. And so really, what I wanted was to provide, like a full-stack pure-Rust gRPC implementation that allows you to, say on my MacBook, cross-compile to Linux musl. Because there’s no C dependencies that are going to make that difficult. And so really, it’s like the Rust OS, and the pure Rust, kind of, vision that we have, to provide that kind of new, safe ergonomic API.

Ben: And just for my own edification here, like, I haven’t heard much about gRPC before now, kind of only in passing, and so, like, is it like the new hotness? Or is it already kind of, like, fading into obscurity based on the new stuff is coming in. It’s a very fast moving space, like I hear HTTP/2, and I’m like, aren’t they already on 3 by now?

Lucio: Yeah, so that’s a really good question, actually. I think gRPC’s has been around for a decent amount of time.

Ben: Okay.

Lucio: I wouldn’t say it’s, like, the hot new thing, but it’s definitely one of the top RPC frameworks you would probably want to use. I think it’s mainly what Google is backing. I know Facebook and other companies have their own internal RPC framework. But gRPC is really the common one because its goal of having the interop between languages is an incredibly important feature of it. Like that is one of the core foundational points of it.

Ben: And you say that languages like Go and Python and Java already have good implementations of this.

Lucio: Yes

Ben: So, which is what matters most.

Lucio: There’s Go, Java, everything, Yes. There’s very good implementations, are all very performant. They’re built atop HTTP/2, which, a lot of the Internet still uses HTTP/1, honestly.

Ben: They probably always will, which isn’t necessarily a bad thing.

Lucio: HTTP/3, I think is still in the draft phase, as far as I— or QUIC is still in the draft phase, so who knows when that will be done? I do know Tonic will probably support HTTP/3 when it comes out, and be one of the first year gRPC implementations to really have support for that. But HTTP/2 is kind of generally becoming the de facto transport.

Ben: If I may digress from that, is there an HTTP/3 implementation in Rust yet?

Lucio: Yeah, so I think we have a couple. So QUIC is the replacement for TCP, pretty much.

Ben: Q-U-I-C.

Lucio: Yes. QUIC. There are a couple crates right now that have it, Cloudflare I believe released one. There have been a couple others written in Rust. There’s also a pure futures based one called quinn, which I think is currently trying to be implemented into hyper, so hyper will have just like, by flipping a switch, you can just connect via QUIC. And because of that, since we use hyper and it’s a config option, it will 100% be supported in tonic. So there’s tons of options for it. But I still think it’s very early stage for QUIC and H3 at the point.

Ben: Great. And so if people having to get more involved or learn more, what would they do? Websites, chat channels?

Lucio: Right. So we have the orgs for hyperium and tokio, and we have a Discord, you’re welcome to come and join that. We have everything from Tonic stuff, to Tower, to Hyper, to things like tracing and other weird off-topic stuff too, that run futures and async.

Ben: Very nice. Well, thanks for talking, Lucio.

Lucio: Thank you.

Ben: Lucio.

Lucio: Yes.

Ben: Good to have you on.

Lucio: Thank you.