Season 8 Episode 7 May 26, 2022

Faking DEI Efforts, Ruby at Scale, and Diving Into PyScript


The hoops companies will jump through to make it look like they're putting effort into DEI, even when they aren't, is incredible.


In this episode, we speak with Tara Robertson, a diversity and inclusion consultant about some of the ways the tech industry has continued to fail when it comes to DEI, which is a topic spurred by a recent piece in the New York Times titled, At Wells Fargo, a Quest to Increase Diversity Leads to Fake Job Interviews. Then we speak with Stefan Marr, researcher and Senior Lecturer at the University of Kent’s School of Computing about Shopify’s investment into Ruby at Scale, and the research he will be doing for them. And finally we speak with Fabio Pliger, Principal Software Architect at Anaconda, Inc. and creator of PyScript about, you guessed it, PyScript! Which was unveiled at PyCon US 2022.


Saron Yitbarek

Disco - Founder

Saron Yitbarek is the founder of Disco, host of the CodeNewbie podcast, and co-host of the base.cs podcast.


Tara Robertson

Tara Robertson Consulting Inc. - Principal

Tara Robertson partners with leaders eager to make their organizations more diverse, equitable, and inclusive through systemic change. She previously led Diversity and Inclusion at Mozilla and her work has been included in Harvard Business Review, Forbes and other publications.

Stefan Marr

The University of Kent - Senior Lecturer, Royal Society Industry Fellow

Stefan does research on how we can make dynamic language interpreters faster. These days, he is particularly interested in speeding up TruffleRuby’s interpreter.

Fabio Pliger

Anaconda - Principal Architect

Fabio Pliger is Principal Architect at Anaconda, where he spearheaded the creation and development of PyScript—a framework that allows users to create rich Python applications in the browser using HTML's interface and the power of Pyodide, WASM, and modern web technologies.

Show Notes

Audio file size





[00:00:10] SY: Welcome to DevNews, the news show for developers by developers, where we cover the latest in the world of tech. I’m Saron Yitbarek, Founder of Disco. Our co-host, Josh, is still out so we’re doing something a little different. This week, I’ll be speaking with three really awesome guests about three really interesting topics. First, I’ll chat with Tara Robertson, a diversity and inclusion consultant about top of the ways the tech industry has continued to fail when it comes to DEI, which is a topic spurred by a recent piece in the New York Times titled “At Wells Fargo, a Quest to Increase Diversity Leads to Fake Job Interviews”.


[00:00:45] TR: We’ve seen the number of women, especially in technical roles, increase over the last 10 years. And I think the progress with increasing representation of people of color and black indigenous folks, it’s been slower.


[00:00:59] SY: Then I’ll speak with Stefan Marr, Researcher and Senior Lecturer at the University of Kent School of Computing, about Shopify’s investment into Ruby at Scale, and the research he’ll be doing for them.


[00:01:09] SM: And that’s why I’m trying to look into on top of this to kind of move up the baseline that improves the performance as soon as possible before we actually need to do just in-time compilation.


[00:01:22] SY: And finally, I’ll speak with Fabio Pliger, Principal Software Architect at Anaconda, Inc., and creator of PyScript about, you guessed it, PyScript, which was unveiled at PyCon US 2022.


[00:01:34] FP: The choice of Python is pretty much natural in that sense, if we are trying to create a framework that we would like people that are not technical to be using.




[00:01:53] SY: Here with us is Tara Robertson, a diversity, equity, and inclusion consultant. Thank you so much for being here.


[00:02:00] TR: Hi!


[00:02:01] SY: There was what I found to be a pretty shocking piece. I’m curious if it was shocking to you as well, being much more familiar with this space in the New York Times about how Wells Fargo allegedly interviews people of color for jobs that were already taken to boost their diversity records and just kind of makes them look good out of potential fear of regulator audits. Can you talk about your reaction to that? Were you as surprised about this news as I was?


[00:02:30] TR: I was disappointed, but I can’t say that I was shocked. And actually, it was interesting. When I read the article, there were so many things. I was scribbling notes to myself and kind of murmuring out loud, being like, “Diverse candidates? Seriously? Diverse is an adjective that describes a group of people. You can’t talk about an individual that way.” I looked at the timeline. This isn’t new for Wells Fargo either. It starts in 2013 with black financial advisors saying, “You’re putting us in geographic areas that are poor and away from opportunities to win clients.” And then in 2017, they settled that class action lawsuit with those employees and then made this pledge, which is essentially the Rooney Rule. And then again, in June, 2020, the CEO had this really ignorant memo where he said, “Oh, well, we just can’t find again “qualified” black candidates.” Their issue is they got a lot of issues and they’re not new.


[00:03:27] SY: And can you describe what the Rooney Rule is?


[00:03:30] TR: So the Rooney Rule came from the National Football League. In the final rounds of interviews, you need to have an underrepresented candidate. In the NFL, most of the players are black and most of the coaches were white. So what that looked like in football was that they needed to have a black coach in the final rounds. And a lot of companies and a lot of tech companies tried this as a tactic to shift diversity. And I think both in the NFL and with those companies, it hasn’t worked. So this is where like taking an experimental view and like, “Let’s try different things and try and figure out what’s working,” and this doesn’t work.


[00:04:11] SY: And why doesn’t it work?


[00:04:13] TR: Like in the case of Wells Fargo, there’s this idea that came up in the CEO’s memo around kind of tokenism and that the idea that qualified black candidates at that stage. There’s an air quote around it that they’re not really qualified and they’re here only because we have a special rule for them rather than saying, “You know what? We’ve got a long standing issue about systemic racism here in our organization.” I think it’s much easier to point at underrepresented or underestimated populations and go, “Oh, they’re just not good enough,” rather than say, “Actually, it’s our culture that has a systemic racism problem.”


[00:04:54] SY: So going back to the example with Wells Fargo, you said that you were disappointed, but not surprised. Does that mean that this is a thing? Are you aware of this practice happening at other companies and other organizations?


[00:05:11] TR: The issue of interviewing racialized candidates when you’ve already hired a white person, that specific thing is new to me. I haven’t heard about that at other companies, but I’ve heard lots of stories from really qualified people of color. And I’ve had the experience as well as a woman of color in situations where the person gets hired and you’re like, “Wow, I actually have a lot more education and experience and credentials than that person. Hmm, what happened?”


[00:05:40] SY: So in that situation, if you’re going to interview people anyway, you’re probably putting in time and effort and go into great lengths to find those people, however you’re finding them, why not just take that same effort and put it towards genuine, real diversity and inclusion efforts?


[00:05:59] TR: Like doing the work in a meaningful, lasting way is hard. I can’t think of any country, company, industry, where they’re like, “Yeah, we solved diversity, equity, inclusion issues five years ago. We’re good now.” We all swim in a society that has sexist, racist, homophobic, transphobic views. We get those messages through the media, through education, like we’re swimming in it. So it’s hard to pick the one thing and be like, “Oh, we’re going to fix this one thing.” It’s actually quite complex. It requires I think people at the top to really commit to learning new things being uncomfortable and essentially also as a change management type of work. Some people don’t like the change and change is hard. I think specifically at Wells Fargo as well, in 2020, there was a scandal around I think people at the branch level, creating fake accounts to hit a quota for a bonus or something. So there’s a dishonest culture there in that piece that I’m hearing as well as a lack of psychological safety. So there’s one thing going on, but people are like, “Oh, yeah, everything’s fine.” It’s like, “No, people are creating accounts. That’s not okay. We are interviewing people of color and wasting their time and deceiving them when we already know we’re going to hire a white candidate.” So I think there’s some broader things at Wells Fargo in the culture and in the leadership that are systemic and not new that they need to really think about if they want to change those things.


[00:07:32] SY: I know that since I started my journey in tech, which is about 10 years ago, it definitely feels like we talk about diversity a lot more. It feels like it’s much more mainstream. I see it much more common to call companies out who have homogenous workforces, especially homogenous leadership. That’s the other thing, right? It’s not just diversity at the bottom. Frankly, there's diversity everywhere. And so it feels like a mainstream topic. It definitely feels like a point of embarrassment when companies do a poor job, but I can’t tell if it’s actually getting better or if we’re just more comfortable talking about it. So when you look at diversity and equity and inclusion efforts over the past let’s just say 10 years in tech specifically, have there actually been improvements?


[00:08:28] TR: Well, the numbers don’t lie, and that’s why I think taking a data-driven approach is really important as well as disaggregating that data. Like instead of talking about underrepresented minorities, which is something people on tech like to say, which is black, Latinx, indigenous, and Native Hawaiian people, I think disaggregating the data to look like, “How are black staff doing versus Native Hawaiian staff?” Like, “How many people are here? What levels are they at in leadership?” And not just the numbers about how many people are here in the door, but what are the promotion paths look like? When we cut the employee engagement surveys by those different demographics, do people feel the same sense of belonging and the same sense of like engagement? Maybe. Maybe not. I think in tech we’ve seen the number of women, especially in technical roles, increase over the last 10 years. And I think the progress with increasing representation of people of color and black and indigenous folks it’s been slower. So some of the same tactics that we tried and were successful in increasing women’s representation haven’t necessarily worked with people of color.


[00:09:39] SY: So when you think about the problems specifically in the tech industry today, is there any one area that you feel is particularly weak that we’re particularly failing at? Or do you feel like to kind of do this right, we need to have a comprehensive attack plan to kind of hit all these areas at the same time?


[00:10:03] TR: We’ve talked about gender and race and ethnicity, but there are so many different dimensions of diversity, including disability, transgender status, neurodiversity, and there are all these other pieces. And as individuals and as communities, we’re multifaceted. So taking an intersectional approach I think is really important. Even if you just start out looking at the intersection of race and gender together, our black men and black women having the same experience at work, maybe, maybe not. I’m thinking about gender. I think, traditionally, we’ve thought about gender as a binary, about men and women. But what about non-binary folks? I'm thinking about that as we’re designing interfaces or designing databases or people’s systems, like how are we designing these different systems and products and who are we designing for and who are we leaving out. And I think when you look at who’s on a team and who’s at the table building stuff, if you don’t have diversity there, you’re going to have messes in the product.


[00:11:05] SY: So in that situation where diversity is so much bigger than, as you said, the two most talked about, ACTE, when we’re talking about diversity, and age too is like another huge one in tech.


[00:11:17] TR: Yes.


[00:11:19] SY: But when you’re thinking about the fact that diversity comes in all shapes and sizes, as an employer, as a leader in the organization, how do you begin to solve that problem? I’m especially thinking if you’re working on a small team, right? If your team can only have 10 people, I don’t know if you can get 10 people to represent everybody. That’s a small number to represent such a wide range of human experiences. And so when you are the leader of a team, you’re the CEO, whatever it is, and you’re thinking about just how wide that range can be and how many different directions it can go in different ways you can think about it, how do you begin to kind of wrap your mind around that problem if you’re looking to do it honestly and do it well?


[00:12:03] TR: There’s the honest conversation about who’s in the room and who isn’t and thinking about who’s missing and who you’re designing for and then being really deliberate to reach out to those people in communities to make sure that those points of view and those people are being missed. I think about Annie Jean-Baptiste, who’s an amazing leader in the inclusive design space and the work that she’s leading. And if we include people with disabilities or people of color or old people and young people from the very beginning, we’re going to design things in a very different way. And the way we expect things out, the way we do use user research, the way we build, the way we test, the way we market products and bring them to market, it’s going to look different, and that’s actually what the world needs right now. So in some ways, it’s a problem to solve, but there’s also an opportunity to unlock there.


[00:13:00] SY: And so in that example, I’m trying to translate the goal with the action and the action item. And so I’m wondering, do you make a list of kind of all the different gaps of people that you’re missing and try to fill them in? Or is it more holistic than that? I’m wondering kind of what’s the first step and kind of breaking this down into something that a company can actually try to implement and act on?


[00:13:30] TR: Yeah. It’s not really making a list of, “Oh, we are missing women. Maybe we can go find women.”


[00:13:33] SY: Right. That sounds weird. Yeah. Exactly.


[00:13:36] TR: And asking like, “Where are the women?”


[00:13:38] SY: Where are the women? Yeah.


[00:13:40] TR: But being intentional about who’s in the room and who you’re designing for, I’m not a user experience designer. I’m not a user researcher. I know that they have their kind of toolkits and best practices and whole subject matter around that. But if you’re not having those conversations out loud and explicitly, your implicit assumptions are going to be woven in there and you’re going to be missing the mark. And then when you try and tack things on at the end, which we’ve seen a lot with accessibility, because people with disabilities weren’t involved and you build out something and you're like, “Oh! Oh gosh! It’s not accessible,” we need to fix that. Now it’s more expensive, it’s more time-consuming, and it’s like an add-on, instead of being designed thoughtfully from the beginning.


[00:14:28] SY: Where are some places in the process that companies who are honestly trying to do the right thing end up doing the wrong thing? An example that comes to mind is we had a conversation with Aubrey Blanche for the CodeNewbie Podcast a while back where she talked about a lot of DEI efforts leading to tech companies hiring only white women. So I’m curious from your years of experience, working with companies, what are some other things where people who might be putting in an honest effort might not get right?


[00:15:05] TR: I think this is where data can be really useful and looking at the aggregate trends and like, “Who have we hired over the last year?” And kind of taking that more holistic kind of systems level approach. So I think it’s having a high-level strategy and high-level goals so you all know where you’re going and then aligning those processes with that, thinking experimentally, like, “Maybe the Rooney Rule is the right way to go.” And as we’ve seen with data, we know that that’s not the right way to go, but then figuring out what the next thing is that you’re going to try and what the data’s going to look like that will tell you that you’re moving in the right direction.


[00:15:42] SY: Do you feel like this problem is something that people can solve kind of just by using common sense and just reading a couple of blog posts? Or is this something that requires training? Right? If you’re a company, you want to do this, right? You want to not make those mistakes and want to really change their workforce or establish a workforce for some new company. You want to do it the right way. What is the best way to do that? Is that hiring a consultant or is this something that you feel people should generally be able to kind of figure out?


[00:16:19] TR: I think if people were generally able to figure it out, we wouldn’t really have the problems we do right now. So I think having people who have that focus and experience and subject matter expertise and what that looks like is a pretty wide range as well. Some people have organizational psych backgrounds. Me, I came from academic libraries and the accessibility world. Some people come from HR background. Other people come through product inclusion. There’s a bunch of different paths. There’s a whole wide range of work. Having that expertise is important. We resource things that we care about. So if you care about this, you have someone on staff or you’re hiring an expert. But also I would say equally important as having this be baked into the company’s goals. So whatever the KPIs are or the OKRs for the year, having one's around DEI in there and having onus and having the visibility and having it be treated just like any other business goal. I see a lot of companies who are like, “We’re really serious about this.” We don’t resource this function. We rely on volunteers and it’s not part of our regular goals. It’s like, “Hmm, would you actually run your finance team that way where once a month people who really like money and numbers come together and throw their best ideas and not actually track revenue or track budgets, like just kind of feel good about it?” Of course, you wouldn’t.


[00:17:48] SY: Yes, it sounds like a bad idea.


[00:17:49] TR: Yeah. That would be wild, but it’s interesting that we wouldn’t do that with any other function, but we do it with DEI. So when people tell me, “It’s very important here,” and they’re not doing the things that we do for things that we actually think are important, I’m like, “Is that really?”


[00:18:09] SY: So the New York Times’ story talked about when one of the people brought up and complained about the fake interview practice at Wells Fargo, they ended up being fired. And so it seems like there are real consequences at stake, depending on what you say, what kind of organization you work for. And so I’m wondering, if you are an individual, you’re not necessarily in a position of power, you’re not a hiring manager, you’re not the CEO and you want to help your company or maybe call out your company for their DEI practices in an effort to do it right, to make it a better place, do you have any advice of how to handle that? Are there kind of best practices for individuals who want to change the place they work or help those efforts out? Or is it really something that just needs to happen at the top?


[00:18:58] TR: Y-Vonne Hutchinson, who is the CEO of the ReadySet, which is also a DEI consultancy, wrote a book called How to Talk to Your Boss About Race: Speaking Up Without Getting Shut Down.


[00:19:09] SY: Nice!


[00:19:10] TR: And it’s focused on race. Obviously, it says on the title, but her advice in the book is really solid and I think can be applied more broadly to any DEI issue. And that’s one, figuring out as an individual what is your stake, what do you want to see happen, figuring out what support you’ve got, talking to your manager once you’ve kind of assessed what the support you’ve got is, and then strategically advocating for action.


[00:19:38] SY: Very nice.


[00:19:38] TR: And if that’s really important to you and you’re working somewhere where it really isn’t, you need to ask yourself if you want to continue to work there.


[00:19:47] SY: Fair.


[00:19:48] TR: And I think with the great resignation that’s happening right now, some people are like, “No, this is actually a deal-breaker for me. It’s part of my core values and I want to work somewhere where there’s alignment on that.” In the case of Wells Fargo, I really admire the courage that it took the man who was the whistleblower. He put his job on the line and he lost his job, but wow, he really embodies integrity, honesty, and commitment in doing that.


[00:20:21] SY: Well, thank you again, Tara, so much for joining us.


[00:20:23] TR: Thank you so much. This is a really great conversation.


[00:20:31] SY: Coming up next, we speak with one of the researchers Shopify’s investing in to find ways to make Ruby at Scale after this.




[00:20:51] SY: Here with us is Stefan Marr, Researcher and Senior Lecturer at the University of Kent School of Computing. Thank you so much for being here.


[00:20:58] SM: Thank you for having me.


[00:21:00] SY: So before we start talking about Ruby at Scale, tell me about your engineering and research background.


[00:21:07] SM: I’m a researcher, lecturer, so kind of a professor for all the non-UK people. And I have been working on language implementation for, yeah, since 2007, roughly. So I have the research interest of making programming a bit easier, these better tools, and part of that has always been how we implement languages because often you need just the tools to be fast enough, for instance, when you think about debugging or profiling things. So yeah, I have a strong interest also in programming language implementation, interpreters, and very recently we started working together with Shopify on making the interpreter for Ruby faster, specifically the TruffleRuby interpreter.


[00:21:51] SY: And that’s what I want to dig into. So Shopify is investing in research for Ruby at Scale. Can you talk about the investment that they’re making?


[00:22:01] SM: So in the case of my own research, we are working together as part of the fellowship actually from the Royal Society. So I’m getting a bit of access to the things behind the scenes, but just for me as a researcher, always a challenge. So a lot of companies have large code bases. Shopify is one of them in the Ruby community, but you can think of a lot of other ones. So I think Stripe and so on. They have massive amounts of Ruby. But for us, as the language implementation researchers, we don’t get any access to these things, if you don’t start collaborating with these companies. So here, that opportunity was great. So now we can kind of see how programs actually behave at that scale, which is quite a different challenge for what a normal researcher would have access to. We have typically very small, tiny programs that we can work with. That’s kind of where Shopify comes into the equation.


[00:22:59] SY: Why do you think that putting research into Ruby at Scale is important, especially today? Because Shopify is, I feel like they’ve been at scale for a long time. They’re a huge organization, tons of engineers, tons of workers, huge company. So it’s kind of interesting that the scale research is happening today. Why do you think that is? Why do you think that there’s an interest in doing that currently?


[00:23:26] SM: I think from the perspective of Shopify, it’s really a question of how much they need to pay for their cloud infrastructure, I suppose. From my own research perspective, I think we can go a little bit broader. Interpreters and the kind of technology behind Ruby is kind of common to a lot of different systems, and that’s not any different. And if you think about, for instance, a browser or something, like V8 for JavaScript or the various other things for Safari and Firefox, they all use interpreters because often enough, you have the programs that you just want to run as a piece to start up, and it needs to be reasonably usable and fast. And ideally, if you’re on the phone, that shouldn’t drain your battery, right? And if you run something on the cloud, like a function as a service thing, it should be immediately fast as well. And if you don’t want to use a dynamic language like Ruby or JavaScript, interpreter is often the choice for the first, at least, couple of seconds of a program to run and often all programs only run a couple of seconds. So from my research perspective that I had, you just want to make that kind of baseline performance better to be able to run larger code bases, but also to drain less our mobile phone batteries.


[00:24:45] SY: So the press release that Shopify wrote said that your research will examine how we can make interpreters faster and improve interpreter’s start-up and warm-up time. Can you talk about how you’re tackling this research?


[00:24:57] SM: Let me just go a little bit into the whole warm-up story. One of the big challenges is modern language implementations is we have all these fancy technologies starting from the ’90s or other people invented things like just-in-time compilation, which you have in your day-to-day browser usage everywhere. So over time, our computers kind of see what our programs are doing and then produce native code to execute that really fast. Now at the scale of Shopify where you have millions of lines of code, we know that just-in-time compilation can be a real challenge. And the problem here is that it takes quite a long time until the system, not necessarily in the context of Ruby, but in the context of other languages, like for instance, JavaScript, actually had a chance to see all the codes and compile everything. So in the context of other big companies, they see that for the first half hour they actually were basically at 50% capacity until it slowly ramps up and gets to a hundred percent capacity. So you lose a lot of capacity on the service side in terms of being able to respond to client requests and users and respond in immediate fast pace. Now on top of that comes, especially in the context of Shopify, I think they had a blog post a couple of years back where they said they redeploy every, I don’t know, 40, 30 minutes or so. So if you lose in your system half the capacity because you have to warm up slowly and then you redeploy every half an hour, you kind of take off an hour to get fast and then you start over again. So here’s a just-in-time compilation system that makes these dynamic languages really useful and usable and has a lot of kinds of problems. And that’s why I am trying to look into interpreters to kind of move up the baseline to improve the performance as soon as possible before we actually need to do just-in-time compilation. And the base we are looking into that is by looking at what our programs do before they execute and kind of identify patterns and rewrite basically the interpreters by combining the most common patterns we see and optimizing specifically for those.


[00:27:20] SY: What kind of research has already been happening in this field that might help you along with your journey?


[00:27:27] SM: So the whole research field on the interpreters and generally virtual machines is quite old, in a sense, at least when we look from our fast-moving technologic point of view. So a lot of research around interpreters has been happening in 2010, around that time. There’s also a researcher from Germany who looked into the concept of quickening, which is something I pretty much rely on as a foundation. The idea being that at runtime, similar to just-in-time compilation system kind of observes what the program is doing and then starts combining the most common patterns in the interpreter. So they did that in the context of Python and slowly Python is also picking that up and integrating that into the interpreter. It only took 10 years. But in Python, you have classic examples around their garbage collection approaches based on reference counting, which means whenever you kind of start referencing an object or losing a reference, you have to increase and decrease the counter. So one easy one there is if you have a sequence of instructions that does a couple of things to these objects that you can kind of in that sequence, for instance, avoid having to increment these counters. The situation on the Ruby is a little bit different, but the general kind of ideas apply, especially if you think about working a lot just for instance strings or data structures, like hashes that are relevant for large programs. If we can try to combine operations and avoid redundant operations that have to happen because of the way our code is structured. A classic compiler can already remove many of these things, and the interpreter’s a little bit harder, but I think we can still push the boundary here and get the bit of speed up for our interpreter’s performance as well.


[00:29:25] SY: What do you think might be the hardest part about scaling Ruby?


[00:29:30] SM: For me, as a language researcher, one of the biggest challenges is the complexity of the language. So in my previous research, I kind of used only research languages because they are very small, very restricted languages where you focus on the key concepts, things like objects and methods and variables, and maybe blocks or closures or whatever you want to call. And now we’re working with Ruby and suddenly there was a whole different variety. There are all kinds of different language features, which makes the life of a programmer really easy. You have very concise ways to express yourself, but that comes at the cost of the complexity of how we can implement these things. So from a researcher perspective, whenever I make a change, for instance, on TruffleRuby, it probably takes me 3, 4, 5 times as much time as it does in one of my research languages. It’s just because there are so many more considerations I have to take into account to not break the language accidentally. Right? I mean, if you want to make it faster, but we don’t want to be kind of caught making it faster. So one of the typical compiler part of users, you can cheat as long as you don’t get caught or as long as we don’t observably change the language, then we can under the hood do whatever we want, which can be a challenge in Ruby. So I think that’s one of the challenges. On the other hand, because there is kind of the larger surface language, there’s also more opportunity to optimize these specific language features. So that has a lot of trade-offs, but I would say the hardest part is really the complexity and the size of the language, which makes things take more time in terms of what we need to do in optimizing.


[00:31:22] SY: Do you know what other kinds of research Shopify is investing in when it comes to scaling Ruby?


[00:31:28] SM: I’m specifically aware of two projects that I find quite interesting. There’s a collaboration with people in Australia that have been working for years and years on garbage collection. So the project is called an MMTk, the Memory Management Toolkit, that comes originally from research on Java. So it’s kind of now transferring to the more dynamic languages and they have been working on garbage collection frameworks that you can pluck it in the garbage collector in whatever language you want. And that’s something I find really fascinating because implementing one of these garbage collectors is very complicated and being able to reuse that kind of investment makes a lot of sense to me. It’s very similar to what the TruffleRuby people do by not having to re-implement a just-in-time compiler, but being able to reuse your thing. So here, at least from an academic point of view, the reuse is really, really interesting. From an engineering point of view, I think it’s also simply put business to be able to reuse that kind of investment. So garbage collector is one thing. The other thing, also here in the UK, in London, the group of Lorry Truck, they are working on repurposing existing interpreters and applying meta tracing as a form of just-in-time compiling to these interpreters. So their goal, I believe, is very similar to the investment that Shopify is doing around a widget project, but instead of having to implement yet another custom just-in-time compiler, build one just-in-time compiler that then can be applied to not just Ruby but perhaps also to other languages, like Lua or Python, if you will. So their approach is really interesting because they’re kind of under the C language implementation and they kind of rely on the information they get from systems like LLVM to be able to compile the executing program based off of that. Then of course there’s a widget project of Shopify themselves, which I find also very interesting because it’s taking kind of a research idea and trying to get the immediate benefits for them in production and it seems to be going pretty well.


[00:33:53] SY: What do you imagine the future might look like having Ruby at Scale, especially when you think broader outside of just Shopify? Do you think that Ruby will rise higher in popularity after we work on the scale issue? Or what do you think the effects would be?


[00:34:09] SM: I think language popularity, from my perspective, that often feels like fashion. So there are fashionable things and I’m not entirely sure that these things will make a lot of difference in terms of wider popularity and fashion. But I think it’s a long-term investment, especially for these big companies, if you imagine you have, I don’t know, three million lines of code, you want to be able to benefit from that investment also in the next 10 years. So you need people that want to program in Ruby, the language system needs to be attractive to the ecosystem, and you probably also want to reduce your cloud bill. So you want the overall thing to be faster. So I think economically, it makes sense to kind of invest into the platform.


[00:34:57] SY: Well, thank you again so much for joining us.


[00:34:59] SM: Thank you for having me.


[00:35:07] SY: Coming up next, we speak with the creator of PyScript, which was unveiled at this year’s PyCon US 2022 after this.




[00:35:26] SY: Here with us is Fabio Pliger, Principal Software Architect at Anaconda, Inc. and Creator of PyScript. Thank you so much for being here.


[00:35:34] FP: Thank you for having me.


[00:35:36] SY: So PyScript was unveiled at PyCon US this year. What is PyScript and what is its relationship to Python?


[00:35:44] FP: So PyScript is a framework basically that allows users to create applications on the browser using Python. It allows to use the web or the HTML markup language as an interface for you to define your Python code. And we offer some components to actually access that and interact with the browser to create your own applications. And Python is arguably the most popular language. It is great. It’s very simple and everything, but it has a lot of things that are missing for the whole story to be complete. Python folks always envy like Vue creation in JavaScript, for instance, or other languages where you can just drop your elements in there and have easy access to a UI or the whole story around how packaging and distributing your Python applications. And outwardly, every other language would love to run on the browser. So we’ve been exploring this idea that the browser is becoming more and more of a virtual machine, and that has a lot of capabilities that are actually things that we consider a virtual machine, like a file system, a networking layer. You can run your processes now with Emscripten and WebAssembly. You can compile code very low level. So all of that together made us think probably the times are mature enough where we can experiment with this.


[00:37:13] SY: So for people who maybe don’t code in Python, don’t really use that language very much, what would you say Python’s place is within the developer ecosystem and why do Python developers need something like PyScript?


[00:37:28] FP: So I think if you’re not a developer, the appealing thing about Python is that it was born as a language to help people learn programming. So it’s very tailored towards the learning experience. Most times the code you’re writing in Python is similar to pseudocode that you would be writing just to develop your algorithm in your head. So trying to think about the series of instructions that you would give to a machine. And that is a huge part of the success of Python. It wasn’t born to be the best web framework or the best data science language or all of that, but because of how easy it was for specific communities to onboard to the language, trading some of the performance or trading some other aspects, it got to grow in so many specific verticals like from data science to infrastructure and scripting language or to a scripting language for C extensions and things like that. So the choice of Python is pretty much natural in that sense, if we are trying to create a framework that we would like people that are not technical to be using.


[00:38:43] SY: Let’s dig into some of the key components of PyScript. What’s it made of? What are the core components of it?


[00:38:50] FP: We like to call it a framework because it really is a glue layer on top of many things that are already out there. So the stack itself, it is based on WebAssembly that is basically a language that you can run on the browser. On top of that, Emscript is used to basically translate Python code to the WebAssembly architecture. And then on top of Emscript, we use Pyodide, which is a Python runtime on the browser, fully on the browser. That is the execution stack for PyScript. We expose users through that stack through a series of web components that basically we create new tags that extend the standard HTML set of tags, and people can now use a type like PyScript to define a script, a Python code inside either the tag or linking to files or we have another component called PyRepl that basically creates a visual component that users can type their own code and execute live, pretty much like a Python interpreter. And we also have a series of other simple UI generation components that basically the idea is to help users type less and do more with less code. So nothing wrong or bad about the HTML subset, but we wanted to say, “Okay, if I’m a new user and I wanted to create a button, I don’t want to learn CSS. I don’t want to learn how to basically put my button to specific functions and all of that. We wanted to make things very simple.” So we created this button that basically extends the HTML button itself, but allows people to write the code within the tags and say, “Okay, this is the function that should run when the mouse hovers over the button,” or, “This is a function that should run when the user clicks on it. And to do that, we use web components that basically extend the document on the browser.


[00:40:58] SY: When you were tackling this project, what were some of the biggest challenges that you faced?


[00:41:04] FP: One of the principles that we wanted to have is that it needs to be a fun experience and PyScript itself should be extensible, meaning that it comes with a subset of components out of the box. But if the community wants to create new extensions and, I don’t know, create a pyuploader or something that basically extends the language itself and other users can use, they should be able to. So I’ve been designing this plug-in system or rather extension system that people can extend PyScript itself, possibly in Python, in runtime. So without having to compile anything or add previously. And that was quite tricky because a lot of PyScript itself is in TypeScript or JavaScript, let’s say. And only when the Python runtime has loaded, things can run in Python and that loading time is kind of slow. So how to design a plugin system that can run later and pass objects between JavaScript and Python was kind of tricky, also because technically speaking, to extend the DAM, you need to subclass from specific classes in JavaScript, and you cannot subclass the JavaScript class in Python. You can do a lot of interrupt between the two languages, but not have a Python class that subclass from HTML element, for instance. So that was a challenge. And the way you solved it is basically to extend the concept of a proxy object that already exists in Pyodide and basically add an interface that can be lazy evaluated later as the things are loaded. So that was a little challenging.


[00:42:59] SY: So I’m curious about your thoughts on things like Anvil, which is a tool that allows you to build web-based apps. I think that one is more drag and drop, but still using Python to build web-based apps. And I’m wondering, do you see a place for both Anvil’s and other competitors along with PyScript in our tech world?


[00:43:21] FP: I will say I’m not a user of Anvil, so I don’t know the internals of it.


[00:43:26] SY: Okay. Fair.


[00:43:26] FP: But I know that it allows, as you said, a UI creation and drag-and-drop sort of workflows and it has a Python runtime in it. It also has a Python runtime on the browser, I think, option, which one good thing as it is competitive to PyScript. The difference is that I think it’s using Skulpt, I'm maybe wrong, instead of Pyodide. And the difference between Skulpt or Brython compared to Pyodide or CPython or WASM is that the first two, they are really a subset of the language. It’s not really full Python or sometimes they will require some server-side components to it, while CPython or WASM or Pyodide, they are literally the same code base they would have in say Python, just forward it to WebAssembly. So that is by itself already something that they had. But in terms of opportunities, I’d like to think that PyScript opens up opportunities for a lot of companies and a lot of other projects. They could be using PyScript components to deal with UIs and things like that. I don’t see that much of a competition in that sense. I see possibilities for partnerships.


[00:44:45] SY: Well, thank you so much, Fabio, for being on the show and sharing your journey with us.


[00:44:50] FP: Thank you for having me.


[00:45:01] SY: Thank you for listening to DevNews. This show is produced and mixed by Levi Sharpe. Editorial oversight is provided by Peter Frank, Ben Halpern, and Jess Lee. Our theme music is by Dan Powell. If you have any questions or comments, dial into our Google Voice at +1 (929) 500-1513 or email us at [email protected] Please rate and subscribe to this show wherever you get your podcasts.