RustFest Interviews Triple Feature: Rust Release Engineering; Developing the Developer Tools; Rust in Latin AmericaBack to Episode Page
Ben Striegel: Welcome to Rustacean Station, here at Rust 2019 from Barcelona. I am here with Pietro Albini.
Pietro Albini: Yeah.
Ben: Great to have you here. You gave a talk today about Crater, and about the Rust release process.
Pietro: Yeah, like, the talk was— it started, like, how can the Rust team ensure that the— with the fast release cycle we don’t have regressions. Then it moved into the tool that actually guarantees these, which is Crater, which is, for those who didn’t listen to the talk, it’s basically a tool that fetches all the crates, all the projects on crates.io and GitHub and compiles them with the compiler, with stable and beta.
Ben: Let’s back up— your credentials. You are on the Rust team.
Ben: Which Rust teams?
Pietro: So I’m the co-leader of the Rust infrastructure team, and I’m a member of the release team.
Ben: The release and infrastructure teams, okay.
Pietro: I’m also involved in some other teams, but I do most of my work on infrastructure and release.
Ben: And I don’t want to rehash the talk you gave today. We should
definitely— someone should— go watch the video. I assume RustFest has videos of
this talk somewhere. I wanted to kind of follow up on that, though, but in a way
that people wouldn’t have needed to see the talk to appreciate. And so one thing
is, kind of, the— Rust has a six week release schedule. Kind of hard to ignore;
if you follow Rust at all, you get the regular release announcements and you can
rustup update, and it’s very simple. And you mentioned before in your
talk, some tension with Rust 2018, where suddenly you move from time-based
releases to, like, a feature-based thing where it’s, like, we want to have this
future out by this time. And it did not go very well, from what I hear. I mean,
it ended up pretty okay. Rust 2018 is a success, but it took a lot of blood,
sweat, and tears to get there.
Pietro: Yeah, like, we are pretty satisfied with the outcome on the release. But that wasn’t something that we can take for granted because we as a team, we don’t have experience with feature-based release cycles and, like, we broke a lot of our internal policies, like, we made a lot of changes close to the stabilization, or even directly on beta. And so, like, it’s something that the whole team felt a lot, and we learned a lot about that experiment, because we started working on the edition late. I think we started planning it by the mid- to end of 2017. And so, like, we didn’t really have much time to actually get the work done. So the period that would have been reserved to just test this stuff, fix regressions, was really squeezed in at the end of the cycle, and we mostly forgot about that, for the most part. So if we actually end up doing another release, which— I don’t know if we have made a decision yet whether to do a 2021 edition. If we do that, we’re surely going to, take things more slowly and learn from the mistakes made in the past.
Ben: If I may speak my own personal opinion, I feel, like, people want to extrapolate, Rust 2015, Rust 2018, so obviously: 2021. But I think in this case, 2015 came out just because it was time to do a stable release. And in terms of 2018 I feel like the most important kind of thing to change there was more like, the non-lexical borrows— and also introducing keywords for async/await. And there were a few very high priority features that kind of motivated, this quote- unquote “breaking” change. And is there even a need for that in the future?
Pietro: Like, I’m not aware of one? I think most of the team members have their own little wishlist, of maybe some small things that they’d love to change. But I don’t think we have— so we have as many changes— as many possible breaking changes for 2021 edition, like we did for 2018. 2018 also had the whole module system revamp, which improved the learnability and usability of the language as a whole. Like, we don’t really have that many headline features to go—
Ben: Yeah. So I would say, don’t feel pressure to, you know, let’s not try to assume there’s going to be a Rust 2021. Maybe in the future when we batch up enough things that could be breaking changes, it would make sense. But in the meantime, just— let’s try and— there’s a great talk today on burnout by Katharina Fey. And I think it shouldn’t really go into, like, open source burnout; it was more about corporate company burnout for a programmers in industry, but it definitely applies to open source developers, even including, especially, Rust developers, who work themselves very hard.
Pietro: I mean, like, one another point of the edition was also, not just to have a way to make breaking changes, but also to be a sort of rallying point where we can sort of celebrate all the features that we introduced since the previous edition. And more for a marketing point of view, and like, then I think— I personally think those are still really useful things. Like, all of these is just my personal opinion. It’s not something that the whole team agreed on. But, like, I don’t know if using the edition mechanism to actually make those changes is good. Like we we might want to figure out another mechanism, I guess.
Ben: And it might even be a more frequent thing if you can find, like, ways of doing it that aren’t breaking. But you still want to celebrate a certain period of time like maybe, for example, when, if— Rust recently just released, or stabilized the async/await feature. And so— but there’s still plenty to do with regard to things to add to the standard library, language features like async closures, that kind of thing. Maybe when that’s all done, wrapped up, you could have, like Rust 202x, where here it’s like, “let’s celebrate all the async stuff we’ve done” but more of a marketing thing than a technological thing. So that sounds great.
I wanted to talk to you about— you showed a slide in your talk today about showing different languages and how often they release, where like, Python: 18 months; Java: one year. That’s a new thing, even, the one year release cycle for Java, and most languages are at one year, some are at six months, Rust is at six weeks. Kind of with, like, you know, showing up with web browsers. And even Firefox is moving to an even faster release schedule, four weeks. Do you feel any pressure to move to a faster schedule?
Pietro: Like honestly, no. Also because, like, it’s— we are sort in a comfortable spot.
Ben: Comfortable spot.
Pietro: Where we actually have the time to test the release to make sure there are no breaking changes. And like, right now, if you look at— except for 1.49 when we actually added async/await, most of the releases don’t have a lot of groundbreaking changes. There are incremental changes that make the language better, add new stable APIs to the standard library. But like, we probably don’t even have as many features to ship in a fast release cycle. Like, to be honest, the release cycle being fast, yes, it’s really useful for us because we don’t have to worry about deadlines. But still, it’s work for the release team to make releases out, because we need to write blog posts, so we need to test that there are no regressions. So with a release team that’s only made of volunteers, we need to be careful about switching to a faster release cycle.
Ben: At the same sense then, does that maybe imply that a slower release schedule is what you want? Have you considered, maybe, moving to an eight week schedule of a six week? Would that give you more time to test, more breathing room for beta testing? That kind of thing?
Pietro: Like, I think we are in a sweet spot right now.
Ben: You think so? It was like, six weeks, the first time we picked it out was perfect. It was just ideal.
Pietro: I don’t know if it’s perfect, but like, it works. We don’t feel, in the release team— I don’t feel like there’s much pressure.
Ben: That’s good.
Pietro: And like we’re good at doing this, nowadays. We have processes. We have roles inside the team, who gets to write the blog post, who gets to review it, who does (unintelligible— 8:31). And so, like, I don’t really see a reason to change that, honestly.
Ben: Okay. Yeah, one of the themes, I guess, of this RustFest is, like, avoiding burnout and, as long as the team itself isn’t too stressed out or pushing themselves too hard, because they’re all just volunteers, so people have to get on with their lives, their work and their personal lives. All that stuff. So, great, I’m glad to hear that you’re still rolling with it.
You also mentioned in your talk Crater, which is a tool that is used to test for— to make sure that the Rust compiler doesn’t break, so kind of like— used to— You have crates.io and then you have the old compiler and then you have the new compiler and you compile them both and make sure everything still compiles and passes as expected. And you even run all the test cases, which I didn’t know about, on all the crates.io crates. So it’s fantastic. You did mention that there are a few regressions, like in one release there was, like, four, another there were three. And are these usually, like, type inference changes, or what is actually regressing here?
Pietro: Like, those regressions that you mentioned, that Crater didn’t catch?
Ben: That crater didn’t catch. Those that were filed as issues after the release came out.
Pietro: Yeah, because Crater does not have perfect coverage. Like of course, we don’t test the private code.
Ben: So where those in private code?
Pietro: Like, those were actually other stuff, because Crater is currently running just on Linux x86.
Ben: Oh, okay, so other platforms—
Pietro: Yeah, a lot of those regressions were, for example, on ARM, or other tier 2 platforms. And also, performance regressions or error messages regressions are things that Crater can’t catch yet. So like, Crater is not perfect. We know there are a lot of flaws in Crater and we don’t test everything. But still, it provides enough test coverage that people don’t fear upgrading the compiler. Like, Red Hat Enterprise Linux, which is one of the most conservative Linux distributions, is actually starting to update their Rust compiler every two releases on their stable release. And the accomplishment we made here is that we are so good of a track record about testing our releases with Crater, that we actually convinced them to do these—
Ben: For enterprise users, which is very significant. I’d say.
In terms of— you mentioned a thing in the talk today that caught my attention, which was— you mentioned that if, say, Rust adoption took off— right now out crates.io has, like, 70,000 crates or something?
Pietro: I think crates.io is more about 20,000. Because Crater also, other than crates.io, tests all the public repositories on GitHub.
Pietro: So if Crater—
Ben: So Crater is using 70,000 or so.
Ben: Okay. But if that ever, like, increased dramatically, it just wouldn’t become feasible economically to continue to do this. And then, what is the plan for then? Would you only try and find the most popular crates, and then just test those, or what?
Pietro: The honest answer is that we don’t actually know because we didn’t— we are not at that point yet, and I think there is no point in, like, prematurely optimizing Crater when it works great right now. Because if every solution that we can implement is either to, just, do a longer release cycle because we can’t afford to test any more, or just test just a subset of crates. But implementing that doesn’t really make much sense at the moment, because we just— it works right now.
Ben: Do you have a threshold where you feel like— so for example, right now,
you said doing a
cargo check on every crate in Crater takes, like, three days.
And a full
cargo build and
test takes, like, an entire week for one thing.
And so, at what point would that become too slow? Would you actually pass a
threshold where you would need to say, hey, to the team, this is getting too
slow. We need to come up with a plan.
Pietro: So the plan right now, if it gets too slow, is to actually get just more machines, because we’re still at a scale where we can ask sponsors to get us some virtual machines where can run the tests.
Ben: And is that the Microsoft sponsorship I saw recently?
Pietro: Like, we have— at the moment we have two different agents. One is sponsored by AWS and one is sponsored by Microsoft. And there are other big companies that want to give us agents, but we still don’t need them, so we don’t want to just waste resources.
Pietro: And, like, Crater, my personal limit is, if it takes more than three weeks—
Ben: Oh, okay.
Pietro: If it takes more than three weeks to do a full test, it becomes useless, because then we don’t actually have the time to prepare the fixes for the regression it found.
Ben: That’s a good point.
Pietro: But, like, we use Crater not just for regressions, but also when we get a pull request to the Rust repo that we think is probably going to break something, we actually run a separate Crater run just for that pull request. And so, if we get to a point where the Crater queue is too big, we can just tell the teams to stop doing those pull requests, be our answer.
Ben: Okay, so you did mention you have good utilization, currently, of all the machines, where there’s pretty much always— someone’s in line, waiting to do something. But you have priorities where, hey, we’re doing stability stuff, like hold off on these PRs for a while. It sounds like you have a really good system for making sure you have enough machines. You have plenty of room to scale, still, with adding more machines and tolerating more delays, so it seems like you’re doing pretty good from where you’re at. And I think plenty of people still balk at the idea of, you know, I have to wait a week for my results to come back. But I guess if you’re— it’s not that unreasonable to say, hey, this is the stability of an entire project with a big, huge library ecosystem involved, and so it’s worth the time it takes to check.
Pietro: And also, if you are a developer on the Rust compiler, you’re sort of used to wait a lot because, like, we have, our CI is pretty slow— it takes three to four hours at the moment to do a single test, of a pull request, and we merge one pull request at a time. So that means that we have a theoretical maximum of seven pull requests we can merge in a day. So, like, you’re already used to wait days in the queue before your pull request even gets tested.
Ben: And what I need to mention too there are rollup PRs. Which means— that doesn’t mean that only seven commits per day get committed. Because if you look at This Week in Rust, there’s often around 100 commits per week that get in, in which I presume are from rollups.
Pietro: Yeah, mostly, but there are some pull requests that can’t be rolled up, because if there’s some pull requests that we know are risky, that could fail, and those pull requests— if we put them in the rollup will just break— the rollup is probably going to fail. So there’s a lot of people, especially if you do performance improvements or CI improvements, you are pretty used to waiting a lot of time to get your pull request merged. I guess if you’re a Rust developer, you’re sort of used to that. In the infrastructure team, we try to reduce those times. But, like, there’s so much we can do, with the—
Ben: At some point, there’s no more you can do, in terms of— you guys need to— it’s the compilers team’s job to try and find ways to make the compiler faster, I guess, or everyone’s job— it’s the compiler team’s implementation. So, yeah, great. Thanks for talking to us. Is there anything else you want to say, or shout outs? Or, how can people get involved with infrastructure or any of these other teams?
Pietro: So, getting actually involved in infrastructure is an issue we need to figure out. Because to do most of this stuff the infrastructure team does, you need privileged access to our infra. But to get privileged access to our infra, you need to be a team member. It’s like this catch-22 that you don’t actually— we don’t actually know how to onboard new people. But still, Crater is fully open source; you can propose new features, send pull requests. And there are other projects managed by the release team, or the infra team, that allow easily contributors. And you’re interested in working on Crater, just contact me. I’m on the Rust Discord, pietroalbini, and on GitHub. So I’m happy to welcome you all if you want to—
Ben: Awesome. Great. Thanks so much for talking to us.
Pietro: Thank you for asking.
Ben: Welcome to the Rustacean Station Podcast. I am Ben Striegel, live at RustFest. I am here right now, in our improvised studio, with Pascal Hertleif.
Pascal Hertleif: It’s very close. Try “Hertleif”.
Pascal: Perfect. Perfect, first try.
Ben: Excellent. I am German by origin, I suppose, thousands of years ago. Carries down in the genes. So you are here at RustFest.
Pascal: Yeah, long time listener, first time caller. I’m very glad to—
Ben: Do you want to talk about about, what song do you want to request?
Pascal: So, see, last night at karaoke, we never did Wonderwall, did we?
Ben: We could do it right now. Actually, would we— is it possible get copyright striked on your podcast, because we might sing it so well that it might be indistinguishable.
Pascal: Unlikely. I mean, you did invite me and not someone who can actually sing.
Pascal: We can try.
Ben: We’ll save that for the extra content, after (unintelligible— 18:18)
Pascal: Looking forward to the autotuning.
Ben: So you’re the lead of the dev-tools team, I hear.
Pascal: Yeah, and indeed, this year, it’s an interesting team because the
dev-tools team, in contrast to many other Rust teams, and there are a lot, right
now, actually, is not a team of people who just happened to work on dev-tools,
since Rust is actually in a very good position of having a lot of different
tools that help developers out, in their daily usage of Rust, we decided to
structure the team in the way that, the actual leads of the sub-teams that
manage the tools are part of the dev-tools team. So it’s like an umbrella
corporation of the sub-teams. Which is interesting because right now I am
technically only responsible for the
rustfix tool, which has, to be fair, not
seen a lot of action this year. But my role as co-lead in this team is basically
boiling down to facilitating meetings and talking to people about what they’re
doing and how we can work together to make tools interop.
Ben: And what tools besides
rustfix fall under the purview, the umbrella,
of the dev-tools team?
Pascal: It’s a long list. Let me try. So, Cargo is on the list,
on the list, RLS (Rust Language Server) is on the list. There are a few smaller
ones. For example,
bindgen is technically also on the list. Clippy. And, I’m
forgetting at least one…
Ben: And don’t Cargo and some other ones possibly have their own teams?
Pascal: Yes, Cargo, especially, is like, a very large team of people. In
contrast to, for example,
bindgen. That’s a project that is progressing at a
very slow pace, compared to all the features that Cargo has. It is doing one
thing, and not the whole of package managing.
Ben: So you say that
rustfix hasn’t had a lot of development this year,
but does it really need it? Is there, like, after the edition came out, is there
much to be fixed?
Pascal: Ideally, yes. But the fixing itself is pretty trivial, actually, it
is reading the compiler diagnostics output and applying it to files. So that is
rustfix does. The source of the diagnostics output is in
rustc or in
clippy. And that is what actually provides the fixes themselves. So we as
rust-fix, just apply them.
And there’s one big open issue and that is having the ability to fix diagnostics
that span multiple items. So, for example, one good thing is, Rust provides the
Default trait. So when you implement a method called
new and it takes no
parameters and returns
Self, you pretty much always instead want to implement
Default. And maybe still keep
new as just calling
default, because then
every container or method that takes a thing that implements
Default can use
your new type. So one of the clippy suggestions is, when it sees a method called
new without parameters, returning
Self, it wants to to tell you, just
Default. And it can do that by copy-pasting the function
new into this
impl block, for
impl Default for your type. That
involves two parts, though. The first part is removing the
new function, and
the second part is inserting the new
impl block. That is in contrast to other
diagnostics that could have multiple possible solutions. For example, if we’re
not sure what to import, you might, say you’re using an
Error type and we say,
we don’t know what you mean by
Error because you haven’t imported it yet, so
you might use
io::Error, or the
std::Error trait, actually, or the
Error. There’s multiple solutions, so this looks, right now, the
same. It is multiple fixes, and we can’t differentiate between possible
solutions and one solution applying multiple things to make it work.
Ben: Interesting. So aside from
rustfix and, let’s leave aside Cargo for
now, some of these other ones, like
compile-test, isn’t as well known.
Pascal: Yeah, it’s a really good crate, though.
Ben: What does it do?
Pascal: It allows you to write tests, that are especially relevant to crates that generate code. Where you say, oh, you see, I want to have this specific error message from my macro, for example.
Ben: I feel like I’ve seen this in the source for the Rust test suite, the Rust compiler test, where there’s little comments and they have a little arrow and it says “error so-and-so”.
Pascal: Yeah, exactly, that’s—
Ben: With the UI test, they call it, possibly.
Pascal: That’s exactly what it is, and
compile-test is basically the same
codebase, as far as I understand it, taken out and made usable outside of the
compiler, because the compiler contains its own implementation for that, for
Ben: So you think a crate like
serde, things that
generate code, or help you generate code, or— would use this kind of thing?
Pascal: Yeah, I’ve seen used in several codebases.
diesel, for example,
has a huge codebase. I was also previously involved a lot in
diesel. And we,
kind of, want to make sure that the errors users see are at least
understandable, and especially if we generate code by using a macro, we can
easily mess it up. So we want to have some consistency there.
Ben: That’s a great idea, actually. Often, one of the downsides of using macros is, you make errors way more opaque. But if you can test for that, to have a regression test for, oh, our errors got worse, that sounds like a fantastic thing for usability.
Pascal: Yeah, exactly. And you can make sure that your errors actually still work. Like you don’t want to generate code that suddenly allows something that was explicitly forbidden.
Ben: So what else did you want to, maybe, signal boost, of the things that you listed?
rustup has in the the past few months, seen a bunch of
features, like the latest release, for example, contains this awesome
possibility of, you’re saying you want to update your nightly version, but you
clippy to be there. And previously would just say, oh,
sadly, on this day’s nightly,
clippy didn’t build, so I can’t update. But now,
with the newest release, it will actually try to go back in time and fetch a
nightly that is newer than the one you have, that contains all the components
that you want, so you can update to the latest possible date. But talking to the
people involved in
rustup right now, that’s a lot of possibilities, but
there’s only so much bandwidth that people actually have, to review the code. So
there’s first time contributors, and people who want to actively be involved in
this project, but to make sure that it actually works, because it is a part of
the core infrastructure of using Rust right now, we need more people to go in
and review the code, and make sure that the newest pull requests actually don’t
break anything, because it is complex and especially,
something in a broken state will frustrate a lot of people.
Ben: You mentioned RLS. A thing that I’ve heard recently is a tool called
rust-analyzer, and I’ve heard it’s, kind of— referring to it as both as a
replacement for RLS and even potentially for
rustc. And we can get into that
in general, but let’s give it— Can you tell me what
rust-analyzer is? It’s not
part of the dev-tools team, but you know what it is.
Pascal: I know what it is. I’m not sure I can precisely represent the
current status of the project. But I’ll try. Take it with a grain of salt. And
don’t don’t trust me on the small details. It is a, right now, experimental
approach towards building a better IDE experience for Rust by re-implementing
parts of the compiler front-end, in a fashion that it’s easy to incrementally
update, which is what you’re doing when you’re editing a source file. You don’t
just paste in, like, a new module, and it’s perfect the first time. You add
lines, you want to have auto-completion, and the compiler right now is— it does
have support for incremental compilation, but it historically has not been
architected in the way that it is easy to to query what is actually going on,
and to to incrementally update the trait resolution, for example. And people
felt like it would be a good idea to implement an experimental way to do that
outside of the compiler. With the intent of figuring out which parts actually
work, and moving those back into the compiler. So as I understand it, the
tokenizer, for example, is shared right now between
Ben: And do you think that would— isn’t that kind of what RLS was designed for? The whole, like, incrementally updating thing, especially with the IDE use case in mind?
Pascal: I guess so. It always sounded to me like it was targeting the same
goals. But as far as I can tell, the technical implementation is different. Like
it is using the compiler as it is right now, and trying to tweak this source
code that we have in the
rustc codebase right now to emit analysis data, while
rust-analyzer is going from from the other side, of saying, okay, we can have
these components that do trait resolution or macro expansion, and rebuild them
in isolated environments, and make sure that we can now incrementally update
macro expansion, for example. And ideally, they work together really well
because the changes made to the compiler to accommodate RLS go in the same
direction as the designs chosen to implement
Ben: Very cool. So kind of, they might just naturally fuse into one thing
over time as enough things get imported from
Ben: So, pretty cool. As a lead of a team, you say that your job is mostly to coordinate meetings. But can you give me an idea, for people who have ever seen a Rust team in action, what is actually like? How many people show up to a general meeting? Like, Where do you meet? How long does it take?
Pascal: Oh, that’s a tough question, especially because the dev-tools team feels like it’s kind of special in this way because— I expect the community team, for example, to act in a very different fashion just because they’re tackling different topics. We mostly do, right now at least, these check-in meetings where we basically just go through the list of sub-teams we’re composed of. That is, the tools that we want to to maintain, and go around and ask, like, how everyone’s doing, what they’re busy with, where they need help, if they, maybe, need to talk to some other people from other teams, and just make sure that there’s a good flow of information going, and the way we do that is, right now in a monthly meeting, we sometimes do this, of a video call, sometimes just in the Discord channel, and it is pretty informal, I’d say.
I can’t speak for larger teams, like the language team is way, way, way larger than we are. And they have a bunch of very different topics they want to tackle, so I expect them to act in different ways than we do. But it is kind of nice to feel the connection between all these people, and that is what the team stands for, basically, that it’s not just someone who randomly says, oh yeah, actually, I wanted to have this feature in Cargo. There is a team that is responsible for making sure that the features compose nicely, and then it kind of bubbles up to the next layer of teams, in this case, the dev-tools team or, in other cases, the actual core team, where we make sure that across the whole project, this is harmonious.
Ben: very cool. You did show up here with that entire notebook full of notes. Is there anything that you wanted to talk about?
Pascal: Well, it is a long list, I have to say, and basically it is also the same list of— how I liked RustFest, actually.
Ben: Oh, yeah. go ahead and tell me more about RustFest.
Pascal: Yeah, yeah, it was— so I’ve been to every RustFest, starting from the first one in Berlin. I actually talked at the second one in Kiev. I was emceeing Zurich, and it just kept going. So I kind of feel like, I can always get the same vibe from from every RustFest, because familiar people show up, cool stuff happens. The community always goes in with this expectation of, there is always one more project that we haven’t seen, that is really impressive. And we want to give some new person the chance to go in and say, by the way, I’m doing this, and if you want to help out, feel free to join in, and that is really nice. So this RustFest specifically also felt like, this has scaled up by quite a lot. Like, it is the largest RustFest, as far as I can tell, at least. I don’t know, 400, maybe 450 people? So you really felt like, this is on a larger scale than the 100 people— maybe 80, I don’t know— who showed up for the first one. And it is quite humbling to see that this has— that Rust has this impact, and that people show up because they actually, like, right now, work in Rust. And because they see this as a language where they can immediately go in and say, like, oh, yeah, this this all exists, I’m going to do my next project in Rust, because why not? A lot of people are still hobbyists, of course, but to get the feeling that it has become a bit larger than, just the core interest is programming languages, and Rust seems to fit the bill. It is— Rust is a household name, maybe, to a lot more people now.
Ben: Great. I imagine in the first RustFest, there weren’t quite as many people using it at their jobs.
Pascal: Yeah, yeah.
Ben: So, very cool. All right. And then, next one’s in the Netherlands. Will you be there too?
Pascal: I will try to be there.
Ben: You had a streak going. You can’t lose that.
Pascal: That’s kind of the thing, right? I mean, I’m going to make sure that there will be at least someone that looks like me. And maybe talks like me. Maybe also, we’ll sit with you and do another episode of this podcast, in the Netherlands. But I can’t promise it’s actually be me.
Pascal: For example. I can’t tell you next year, right.
Ben: True, true. So, any last words?
Pascal: I’m actually using Rust in my job now.
Ben: Oh, yeah, that’s right.
Pascal: So this also feels, like, maybe that’s why this RustFest feels also different because I’m not just going in there, paying for myself and everything, but it feels like a thing that is related to work now.
Ben: Yeah, I watched you expense your tapas last night.
Pascal: Yeah, that’s what I did, yeah. It was a company dinner, and I hope we can actually hire you. If you haven’t noticed.
Ben: We’ll see. I mean, Sweden is very nice, some time of year, not this time of year, but—
Pascal: I mean, if you really need the sun, I guess you can always fly out to Barcelona.
Ben: Very nice. So, all right. Well, thanks for being on.
Pascal: Yeah, thanks for having me.
Ben: Alright, let’s, 3, 2, 1… “today is going to be the day, when they gonna throw it back to you…”
Pascal: You’re not even playing the music.
Ben: I don’t have a guitar on me. Next RustFest, bring your guitar.
Pascal: Okay, we’ll do that.
Ben: See you around.
Pascal: See you.
Ben: Okay. Welcome to Rustacean Station. It is day four of RustFest. We get to have our improvised studio here, so please bear with us with any audio troubles we may be having. We have a kind of a hilarious set up right now, but with me, enduring this, is Santiago Pastorino. How are you doing, Santiago?
Santiago Pastorino: I’m doing great. How are you, Ben?
Ben: I’m doing good. You are the organizer of Rust Latam, which is a conference in South America. You want to tell us more about that?
Santiago: Yeah, it’s a conference, actually, in Latin America. I’m one of the organizers. We have a team of, like, eight people working right now. We are going for Rust Latam 2020 in Mexico City, May 22 and 23. We have already, like a local, which is an important local team, consisting of five people working in the local duties. But there’s also an international organization, as RustFest also have, a similar setup. And yeah, we’re kind of starting with that, we are starting to look for sponsors, were going open the CFP, closely, probably start to get— just sells tickets, but yeah, we’re kind of just starting.
Ben: Great. What, like, inspired you to start a Rust conference in Latin America?
Santiago: So there wasn’t any, basically. I have been going to Rust conferences since since day one I attended to Rust Camp, actually, that was in—
Ben: That was the very first one. In Portland.
Santiago: The first one, that was in the bay area.
Ben: It was in Berkeley, yeah.
Santiago: Yeah, in Berkeley. I think it was 2014 or 15, I don’t remember exactly. Then I attended to all Rust Confs, Rust Belt Rust, and some of the RustFest. So yeah, I thought to myself, well, okay, there’s conferences in U.S., in Europe, why not having one in Latin America too? And I knew there were a lot of people active, more or less active in the community from there— like, for instance, in Brazil, they invite me to a Telegram group of Rustaceans, Brazilian Rustaceans, and to my surprise, this was, kind of, two years ago to my surprise it was like a 700 people group, which really amuse me. Then there is a huge community in Mexico too. In Argentina, there’s people. There’s people doing some Rust, like, everywhere there. But we are kind of growing, or wanting to grow the community in Latin America.
Ben: How big is Rust Latam? How many attendees do you have?
Santiago: So the first one was in in my country, which is very small country, we have, three million and a half people living there, So we, kind of, made the— so the decision was to do it there— it wasn’t the only place that it could run the thing. But actually, if— we may have prefer, like from the attendees’ perspective, to do that in Brazil, maybe, we will have way more people. But actually we have 200 people.
Ben: That’s really good. That was your very first Rust Latam.
Santiago: That’s— exactly. So, probably, in a place like— if we do that in Brazil we would get way more, I’m pretty sure. But yeah, we complicated ourselves by making the decision. But it was— it ended turning, like, very well, very nicely.
Ben: Yeah, well, 200 for your first conference is great. Like, Rust Camp, the very first one had maybe 100. That was, you know, all of the core teams celebrating 1.0 back then, and even RustFest, their first one was only 80 or so people.
Ben: So, yeah, it’s doing pretty good. So, you mentioned doing it in Brazil? Do you have any, like— what is the overall community like, in South America in terms of, like, Portuguese speakers or Spanish speakers or any of that?
Santiago: I think proportionally, you know, Brazil is a huge country and a lot of people. But yeah, the strongest community in Latin America is the Brazilian one, for sure. But there are, like, from from the Spanish-speaking, there are the rest, actually, the Spanish speaking countries in Latin America there is a— so I would say in Mexico, with a huge amount of Rustaceans, and it’s also a huge country with a lot of population. There will be probably for the next one, which is in 2020, I think I already said this: May 22 and 23. I guess we’re going to have a lot of, also, people that are curious to hear what’s going on. So that was basically the aim to try to get people that are not from Rust to to show them, hey, this is a cool technology. This is kind of new, probably not mainstream yet, but yeah, a lot of curious people are going to show up, and I guess they’re, like, start to get emboldened. They’re going to like the language. So this is more or less our aim.
Ben: And even Mexico City, it’s like, there’s no real Rust conference in the southwest of the U.S. And so, the closest one is, like, Colorado Gold Rust in the Midwest.
Ben: So I mean, maybe someone from that area might even find their way down to Mexico.
Santiago: Yeah, exactly. And we actually had a lot of people going to the first Rust Latam in Montevideo in Uruguay. So Montevideo is the southern capital of the world, so it’s not close to U.S.
Ben: It’s quite far, yeah.
Santiago: Yeah. And we had a lot of people going from U.S. Some were speakers, but some were actually attendees. Yeah, probably this one. And I have already heard that a lot of people are excited that this is going to be there. I’m pretty sure that a lot of people from U.S. are going to go there. And actually, another nice thing is that we have Central America, which— it’s also far from me, like, from from where I live. But, I am pretty sure that people from Central America, maybe Costa Rica, Panama? I don’t know exactly. I don’t know the community’s exactly there yet, but I’m pretty sure that they’re going. They’re going to show up there, too.
Ben: Can you give me an idea of what the overall software industry is like? Like open source wise, but also in terms of people using— what languages are in use, generally? Professionally, that kind of thing?
Santiago: My guess in general, and what I have seen, is it’s pretty similar over all over the world. Like, main languages are the ones that are mainstream in general, like the stuff that is run in the JVM, like .NET stuff, these kind of things are, I guess, what is mostly used. There’s a lot of people, and— I was in the Rust community— in the Ruby community before, and there’s a lot of huge community also in Latin America about Ruby. There is a lot of people doing Elixir in my country also. But also, I know that there is an Elixir conference, Latam conference, that was in Colombia, I think. So in Colombia, there is also a lot of people, like, doing very nice stuff, using kind of, not really mainstream languages, kind of new, like Elixir. And there’s a lot of people doing Go, and I guess it’s more or less like everywhere else.
Ben: I guess, Elixir, is that from Latin America? I’m not sure, I think the— who is the— do you know who the creator of that is?
Santiago: Exactly, yeah. You remind me about that. The creator of Elixir is José Valim; he is from Brazil. I think he’s living in U.S. now. He used to live in Poland. I know him from the Rails community, the Ruby community in general, but he used to do Rails work. And he was in the Rails core team. So I used to share, like, working the Rails core team with him. I remember when he started doing the— building the language. But yeah, it’s originally from from his company, from— out of his work. But it grew a lot in in U.S., mainly, and then a lot of people started to use it because there there are some startups investing on Elixir too. I think that’s spread it, like, everywhere else. So, yeah.
Ben: And then after Mexico City is there, a city that you have in mind for the future? Do you want to share? Or is it a secret?
Santiago: No, there’s no such secret or anything like that. Like, what we’re trying to do, is to have, like, the people that are involved in the organization of the next edition. So this one, the Mexico edition, we have people from Argentina, from Brazil. I don’t know if somebody else is gonna join us too, but we’re probably going to have the next one in a place where we have a really— organizers. So right now it’s Argentina or Brazil. But yeah, like, if we keep doing that thing, is probably gonna be in Argentina or Brazil, I guess.
Ben: Very cool. So what do you do with Rust? And how did you get into Rust?
Ben: But I guess, actually, I remember one of the ways I first saw you working on the compiler was during the 2018 edition cycle. You were instrumental in helping to push the non-lexical lifetimes. And that was one of your first contributions. You’re kind of just like, hey, I want to dig into this very low- level part of the compiler, let me just try this. And everyone’s just, like, yeah. Very helpful.
Santiago: Yeah, yeah. Like during Rust Belt Rust. There was an impl day. Like, it was a couple of days or three days that, I don’t remember. And Niko was there. He wanted people to contribute. So I join him, and we were working— yeah, he was kind enough to share a lot of knowledge with me—
Ben: Yeah, Niko’s great.
Santiago: Yeah, he’s great. And, yeah, like, I had the opportunity to work with him and learn from— he has been doing Rust since a long—
Ben: Pretty much as long as it’s been Rust.
Santiago: Yeah, and I also, like, from the perspective of a person that knows a lot about compilers, it was great for me to be with him. Like, I started compilers since a long while in university. But I mainly spent most of my professional career working in a different field, so it’s kind of— I know when I came back to this stuff, it was, kind of, everything was new to me anyway. And yeah, like in the way you study things, in the theory, like on a very high level, then this compiler doesn’t work exactly the same as described in these kind of books or these kind of courses. But yeah, this was the way I got involved, and I still spend time doing Rust compiler stuff.
Ben: I think it’s a great success story of people being onboarded or mentored, and kind of, how people can contribute. So welcoming.
Santiago: This is great, about the community, is a lot of people willing to mentor you if you want to do something. And, like, as much as I can, I also like to share some— a bit knowledge that I may have. So there’s always somebody around that is interested in help getting people on board in projects. I think that’s what makes— one of the things that makes this community great. There’s people that are really curious and they want— they like to investigate things, like, reach the best solutions possible. And also are kind, kind of people, you know, generous to share knowledge. And I know, like, trying to— If you’re— maybe you don’t know something or you’re stuck working in some particular thing. There’s always somebody that’s willing to help you.
Ben: Is there any kind of native Spanish speaking or Portuguese speaking Rust community that you know of, like, a forum online or some kind of of chat channel?
Santiago: Yeah, in Portuguese, what I was saying: this telegram group, and I was invited there at some point. And I used to share the space for some days. I know there is, like a group, an Argentinian group too, they are 50 people, and I’m there too. There are meetups around everywhere. I run the the Uruguay Rust meetup. But yeah— not huge communities, still. It’s kind of, we’re in the phase of, like, growing the communities around. And this is why I think something like Rust Latam is important. So we, given that the conference is itinerant, we move cities every year. So already is to like to have the event and eventually, like, make people feel motivated about the event and the technology and the community. And, that may help grow in communities or meet ups or groups or whatever.
Ben: If someone wanted to get involved with this community or if they wanted to watch for Rust Latam’s CFP, or know more about it, do you want to plug some websites that they can look at?
Santiago: Yeah, we have rustlatam.org, and there is the Twitter account RustLatamConf. Yeah, we are probably going to share everywhere we can, also in the users group from rust-lang. But yeah, we’re going to spread the word, in all the possible channels that we have. So if people take a— is taking a look or following the Twitter account or just reading users (unintelligible— 52:11), they’re going to figure out when when things happen. We don’t know exactly when we’re gonna open the CFP yet. But just keep an eye on that, and you will see it.
Ben: Great. Well, thanks for talking to us today.
Santiago: Yeah, thank you very much for having me.
Ben: Alright, see you around.
Santiago: This is a very cool set up.
Ben: What we have right now, where we’re hanging out the window, to try to reduce the echoes in this abysmally acoustic room? Yeah, it’s great. So, okay, see you.
Santiago: See you.