Code and the Coding Coders who Code it
We talk about Ruby, Rails, JavaScript, and everything in between. From tiny tips to bigger challenges we take on 3 questions a show; What are you working on? What's blocking you? What's something cool you want to share?
Code and the Coding Coders who Code it
Episode 43 - Stan Lo
What drives a seasoned developer from Taiwan to London, and how does one translate a passion for Ruby into groundbreaking projects? Hear from Stan Lo of Shopify's RubyDX team as he shares his captivating journey and his significant impact on the Ruby development landscape. From his essential work on the debug gem and IRB to his current efforts with the Sorbet type checker and Prism parser, Stan delves into the technical intricacies of using C++ for performance and memory management. Gain unique insights into the collaborative decision-making process at Shopify that guided his transition from the Ruby LSP to focusing on Sorbet's integration.
We also tackle the hurdles of progressing Ruby's Sorbet parser to Prism and the challenges of maintaining comprehensive Ruby documentation. Discover the importance of community-driven contributions, and how small acts like fixing typos can have a profound impact on the Ruby ecosystem. Experience Stan's personal anecdotes, from climbing adventures to mastering calisthenics, and explore the innovative shift from VS Code to Cursor, amplifying his development experience through AI capabilities. As we gear up for future events like RailsConf and RubyKaigi, there's an air of excitement for community reunions and ongoing projects. Join us for a blend of technical discussion, personal stories, and a call to action for all Ruby enthusiasts.
Honeybadger
Honeybadger is an application health monitoring tool built by developers for developers.
Honeybadger is an application health monitoring tool built by developers for developers.
Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.
Ready to start your own podcast?
This show is hosted on Buzzsprout and it's awesome, not to mention a Ruby on Rails application. Let Buzzsprout know we sent you and you'll get a $20 Amazon gift card if you sign up for a paid plan, and it helps support our show.
Hello everyone, welcome to another episode of Code and the Coding Coders who Code it. I'm your host, drew Bragg, and I'm joined today by Stan Lo Stan. For anyone who's not familiar with you, would you please introduce yourself?
Speaker 2:Hello everyone. My name is Stan. I'm a developer at Shopify's RubyDX team. Dx stands for Developer Experience, so I'm working in the same team with Vinny Stock, who was also a previous guest of this show, and I moved from Taiwan to London three years ago and then, during my work, I previously mostly working on Ruby SP and I actually also wrote an RSpec add-on for it, and then I contributed quite a bit to the debug gem, even gave two talks about it on RubyKaigi. I'm a maintainer of IRB at Relay and right now I'm focusing on improving Ruby's documentation from different fronts. Oh, by the way, I'm also a new maintainer of RDoC.
Speaker 1:That's pretty much about it Working on a lot of stuff. So the way this is going to work is I'm going to ask Stan three questions. I'm going to ask him what he's working on, which it sounds like there's a lot. I'm going to ask him what kind of blockers he has. If he doesn't have a current blocker, he can talk about a recent blocker he had, how he went about solving it. And then the last question is what is something cool, new or interesting that you've recently learned, discovered, built? It doesn't have to be coding related, doesn't have to be coding related. It can be climbing related, but it can be coding related, because this is code and the code encoders, code it and we talk about code. So I'm going to shut up now and just simply ask Stan what are you working on?
Speaker 2:Right now my main project at Shopify is I'm working with my teammates Emily Semp and Alex Montelove making Sorbet the type checker for Ruby, use Prism as its parser, and to do that I actually started learning C++, because that's how Sorbet is mostly written in, and even a little bit of C, because we integrate Prism as a C library.
Speaker 1:Interesting. I did not know that Sorbet was C++ behind the scenes. Do you know the history behind that?
Speaker 2:I did not know that Sorbet was C++ behind the scenes? Do you know the history behind that? So it's mostly because type checker needs to be very fast, and by fast I mean it can kind of index the Shopify monolith in about a minute, for example. That's a lot of files and to do that they need to have good memory management and everything that could be optimized. So they need to go pretty low level to achieve that optimization.
Speaker 1:Now I remember when I had, I believe, kevin Newton on some episodes ago, we kind of talked about the decision to move YJIT from C to Rust. Was it a similar thing, where it kind of started as a C project and then they were like, well, c is kind of horrible to work with because there's a lot going on, so let's move to C++, where we get some help with memory management, or why was it C++ and maybe not Rust? Or why not just straight C? That I actually don't know about.
Speaker 2:But I will say, when Sorbet was created, rust was not as maybe mature or popular as it is today. Maybe if we started today, it could be Rust.
Speaker 1:Same motivation of wanting the speed of a lower level language and maybe not doing all of our memory management ourselves. Exactly, very cool, very cool. So you also have worked on the LSP at Shopify, which is, I think, every Ruby developer's favorite tool in the world right now. But now you're working on Sorbet. How did you go from the LSP to Sorbet? Is that something where you went to your manager and said, hey, I want to try out something different? Did that team say we need more developers who want to come over? How is it decided what project you work on primarily?
Speaker 2:So the DX team our team will have meetings to talk about what are the most high impact tasks, problems we can solve, and then we create internal projects based on the team's discussion, and my previous two projects were all RubySP related. They have set the assumptions on why we need to work on the project and also what does it feel like a success when to finish the project. So I did that for an entire year, two different projects, and then by the end of the first project I actually wrote the Rails SQL blog post about co-navigation improvements done in Rubysp. We basically do the best as we can to provide co navigation features like go to definition completion, for example, without using any type of information, and that's when we kind of feel like, okay, most of the low-hanging fruits in this front has been picked, and then maybe making Sorbet using Presen as its parser will be the next big thing, because that will space things up even more for Shopify. So then I decided to move on to that project.
Speaker 1:So that's your Shopify life and then your not Shopify life. You're kind of focused on the Ruby documentation, which is an honorable effort because we all use it, we all love it. But it needs some love, it needs some updating. What got you involved in that?
Speaker 2:So similar to many people in our team, we always feel like we want to improve all the Ruby tooling, not just specific aspect of it, and that's why last year and the year before I kind of focused on debug, gem and then IRB, because first I feel like debugging can be improved the most, and then after that I move on to IRB, because console and the default repo could be very important as well. Right now IRB reaches a bit of almost feature parity with Pry, for example. I just spotted that maybe documentation is the next thing, because whenever I go to the official Ruby documentation, which is docsrubylandorg and slash EN, if you read the English documentation, that's the only official English website and half a year ago it's terrible. It's just so hard to look at and then so hard to navigate into it and that's why nobody uses it and then nobody even know that it's the official documentation. So I just feel like, okay, this is the next big thing that can be improved and that will help every Ruby developer. So yeah, that's how it started.
Speaker 1:I agree with you. It is so important to have readable documentation. As someone who hunts down weird Ruby syntax, who has the docs open a lot, I can confidently say they need some love in updating. They can be hard to navigate. You kind of talked about you go for the low-hanging fruit at work. Is it the same with the Ruby documentation where it's well, let's just find really easy wins to start updating it? Or is there a big team behind it? Was is because it doesn't have much investment from the community.
Speaker 2:And so I would say there's some low hanginghanging fruits, because it's been underinvested for so long. A lot of work needs multiple steps to actually take effect to the end user, and so the first thing I tried to do is that me and Colby, creator of RubyAPIorg, after RubyHacky we both became the maintainer of Rdark, and so we decided that To get things starting rolling again, it's best to make some very obvious visual improvements to our users. So that's why we started improving the default theme of RDoC, which will directly be applied to the official Ruby documentation. It's kind of the first step we want to focus on this year. We want to make it more pleasant to read and when more people use it, people will realize maybe there are missing documentation, there are typos maybe, and then they will want to get involved and that's when we can recruit more contributors to this area and maybe also more maintainers.
Speaker 1:So you're kind of looking to not just get contributions but also get people who are like I am willing to take on some of the maintainer burden of the Ruby documentation.
Speaker 2:Yes, the projects I work on moving from debug to IRB to RDoC right now. So the project itself touches a lot of users. But when going into IRB, for example, some but not too many projects actually use it as a platform. The biggest example is Rails use it as the base of Rails console. So it's through that I realized sometimes working on that project may not be enough and also I don't have enough capacity to do that. So it's best to find a way to build a community around it. And for IRB it's actually not as easy and also not necessary. But for documentation it's such a big effort. I feel it's something that this approach really needs to be taken seriously than just co-contribution.
Speaker 1:So if you were thinking we want people to come in first-time contributors, so a good first-time issue or first contribution for someone, but also something that isn't I added a period here something that actually has real impact, what does that look like to you? Or what areas do you think those exist the most in?
Speaker 2:So for Ruby, currently we can split it into two parts.
Speaker 2:One part is the content improvement and the other part is the more technical side, mostly centered around RDoC, because it generates the HTML files, so it controls the parsing of the source code, it controls the theme, how it looks like, and it controls a lot of aspects like the SEO of the final documentation, for example. So we actually have many contributors from the community. They work on front-end, they work on frontend, they know frontend better than me. They contribute small features to RDoC's Depot theme and there are other contributors that are more interested in parsing. For example, we got a contribution on replacing RDoC's Ruby parsers from using Ripper to use Prism, for example. On the technical aspect, rdoc has a lot of places to contribute to and that's one of the things I aim to improve next year to lay out the components and then different things to improve in each component to let contributors have a better view on what part they may be interested in, and then hopefully later we can even provide a contribution guide for each component, for example.
Speaker 1:Yeah, that's actually really cool that someone could contribute to Ruby documentation, but in a very technical way. It's not the same as contributing to, maybe, the Rails documentation, where it's write an article on how ActiveRecordX works. You can have a big impact on the Ruby documentation by doing very technical work. Is RDoC Ruby or is RDoC another one of those? Contribute to Ruby by writing C? It's pure Ruby. Yeah, it's pure Ruby. That's cool. That's even better. Don't have to learn C or work with C, as it were.
Speaker 2:I have to warn that RDoC is a very, very old project older than the time I write Ruby, for example so it has some legacy code you need to first navigate through before you can actually make a contribution.
Speaker 1:I'm very familiar with projects like this. They yield great talks. Those can be a lot of fun too, because by needing to navigate an older code base like that, you can kind of see Ruby's evolution of its syntax. And can be a lot of fun, especially if you're doing it just for fun and it's not like your day job and you can just I'm going to pick this up, I'm going to put it down because, ow, my brain hurts. That can be a lot of fun and also might be a good place for me to find some new game show questions.
Speaker 2:And also, you know what tool will make it easier to navigate? Use Ruby SP with all the navigation features we just shipped this year.
Speaker 1:There you go. You are helping yourself with your work by doing your work.
Speaker 2:Yeah, that's the good part of working on developer experience Every tool I improve, I can use it in another project.
Speaker 1:That's super cool. That was at RubyConf San Diego during community day or hack day. I got to work on the LSP a little bit and it was super cool to use the LSP to work on the LSP. It was so Hold on, we've got to load up the LSP so that we can continue to work on the LSP. When you're working on a web application, you don't get that kind of immediate feedback on your stuff, I guess, and it was pretty funny to be able to do that.
Speaker 2:Yeah, I guess this is the biggest reason I love anything that's built for developers.
Speaker 1:And we all benefit from your work too, so thank you. So you're working on quite a number of things, and quite a number of impactful things. What kind of blockers do you have in your work?
Speaker 2:I can give you two blockers, one on the main job and one on the side quest Perfect. So the main blocker about the Sorbet prism work is to have that translations support error the same level of error tolerance as the original parser, if that makes sense, let me give you an example. So when you use Sorbet and you have a Ruby file that has certain syntax errors, sorbet can provide you additional hints how to fix it, and hopefully we'll need to achieve the same hints at the same locations with Prism. So let me share some background about this main parser replacement. So the main work is that Solbase current parser generates.
Speaker 2:When you parse Ruby files it generates a certain structure of the parse tree, but when present parses the same file, it generates different structure of a parse tree. So currently we write a translation layer to convert present structure into SOBASE current process structure. So then the rest of the pipeline can just not know about the existence of the present parser. So that's what we do. However, it's not an easy job, but we have mostly completed it. But in the error cases, because there are a few ways you can write correct Ruby code, there are infinite ways you can write incorrect Ruby code. So right now. The possibility is infinite. We need to find out the effective way to kind of match that structure in error cases as well, and we have been trying different ways, but extremely difficult. That's the current blocker on this project and I don't have any answer on how to be unblocked.
Speaker 1:Yeah, that's a bit of a crazy one because you're right, there's so many ways to write correct Ruby, but there's so many more to write incorrect and to be able to give that kind of error feedback. But the blocker you're having is that kind of a result of Prism being more error tolerant because it gives you better feedback. You need to account for all of that feedback where the old parser just syntax. We're done.
Speaker 2:Not really, regardless of which two parsers you are trying to translate, to translating incorrect files, past results will always be difficult because the amount of cases you need to learn, cases you need to learn, and also because we will design good process structure for correct Ruby code, right, but we may not pay that much attention for the structure of incorrect Ruby code. And if you don't do that, then you probably don't write documentation for those cases. And then so every case, you need to manually test it and then document it, even though it may not even be a design decision, but you just need to cover everything.
Speaker 1:Everything is an understatement. That's a lot. That is a interesting blocker. I don't envy you for that blocker. That is challenging work. But you said you had two. So that was the first one, and what a good one. But what is your second blocker?
Speaker 2:So the second blocker is around Ruby documentation. Again, as I say, documentation requires efforts from the entire community. So first, on this side, I and the rest of the team need to find a way to motivate and encourage contributors to come in and start helping out, for example. But on the other hand, we currently don't have that many maintainers to have enough reviewing capacity to kind of testing, go through all the contributions from the community and a lot of times, as many people who contributed to open source projects may know it's very frustrating to spend a weekend on a PR and then not having feedback in two months or even one year. That's the things we don't want to see. But at the same time, if we don't have contributors, how can we raise maintainers? And also, raising maintainers means that not only do they need to have the technical skills and context about the codebase, they also need to learn trust from the rest of maintenance and then also the Ruby core in ways, and all of these take times.
Speaker 2:I have been trying hard to help out on both fronts. That's the current major block, but I will have to say at the RubyConf this month in Chicago we have made some progress. So right now new contributions are coming in and then we are talking about possible future maintenance candidates and hopefully next year we will be in very good shape in accepting community contributions. And then we can see the improvements on Ruby's official websites or Ruby's official documentation. The improvements pace will accelerate and then kind of match people's expectations more.
Speaker 1:That's an interesting little bit of chicken and egg problem. Like we want more contributors but you don't have a ton of maintainers to go through all the contributions. But in order to get more maintainers you need contributors. But in order to get happy contributors you need the maintainers. That's tough, but I guess you're also a solution to that. Blocker in a way is hoping that as much as it does stink to work on something on a weekend and then have to wait two months for feedback on it. Hopefully the folks in the Ruby community are understanding of that bit where it's hey, sorry, we've got a lot going on. I just had a PR from Rails Merge that I opened two years ago. It happens I get it. It's open source work, totally understand. Hopefully most people understand hey, I'm going to do this work. It's good work, it'll eventually go in. Just give it time. Do you have interesting blockers, sir? Neither of which I'm jealous of.
Speaker 2:I don't think I've ever been jealous of someone's blocker though.
Speaker 1:Yeah, that's true, good blockers though. And so I guess a solution to your second blocker, in a way, is if anybody is listening to the show and is thinking, hey, I would love to give back to the Ruby community in some capacity. A great way is to reach out to Mr Stan Lowe here and get on board with contributing to RDoC and the Ruby documentation in whatever capacity you're able to, and when you do that, give them a degree of patience.
Speaker 2:So that's my call to action for the Ruby community anyone listening that has the capacity, get on that, and speaking of contribution, if you have limited capacity, there's actually a certain amount of typos or grammar errors in this documentation source, directly inside the C Ruby itself, that you can just go find them manually and fix. Or I'm actually testing an approach which is to use LLMs to help correcting them in batch with less effort. So, yeah, you can use whatever tool and, based on my experiments, llms are very, very good at fixing those typos and errors. It takes me about half hour to go through the same document, like same files, for example tracepointrb, inside Ruby to find all these obvious errors and fix them and open a PR. So if that's what you want to do and then become a CRuby contributor there, you go.
Speaker 1:That's an easy way to get in. I tried to get in at Rubyshot Conf Chicago. While I was working on the game show. I found a bug in Ruby and it was cool. I'll be able to get a commit into CRuby. This will be great, Turns out. No, it's so much harder to do it via code. I'm definitely going to go the typo route. That's brilliant.
Speaker 2:I like that, Looking forward to see your PR. I mean, I don't review those PRs. It will be coming to a stoop, but yeah, I'm happy to see you contribute Still any kind of contribution.
Speaker 1:Typos can be super distracting. When you're reading and you're getting into something, you see it and it just takes your brain out of whatever you're learning and you're like that's a typo. So they can be very distracting. Definitely a worthwhile effort to fix typos. So the last question, my favorite question, is what is something cool, new or interesting that you've recently learned or discovered or built or did that you want to share?
Speaker 2:I mentioned that I started working on Sorbate and then learned C++. I've never written any C++ or C or ROS before that project, so I actually rely heavily on the cursor editor and O1 preview model, if I'm being very specific, and it's just so amazing how it is able to grasp the context and then also being super patient on teaching me all the things I need to know about C++ in order to make things compile and then not stack forth.
Speaker 1:In case you've never had to work with a language like C++ before, there's an extra step that we don't have to do in Ruby and that is compile your code. And I remember back in high school working with C and Java. It took forever even small programs, I felt like, and it was always such an anxiety-inducing. You hit, run and you're just please, don't error out, please don't error out, please don't error out. So I am every day very, very impressed by all the different AI tools that come out and how much better they get.
Speaker 1:I feel like when they first came out, they were just look at these AI tools and I was like they don't actually do that much for you. And now they're very impressive. Andrew Mason was teaching me how to use copilot edits in VS Code and how to tell it what files to use in context and what a difference it makes when you can say like hey, look at these files, this is how we write our code. Help me do X and the stuff it comes up with still not 100% perfect every time, but definitely can help you with the blank slate problem or just getting over that hump of hey, how do I even get started? Where should I start?
Speaker 2:it's wildly impressive so in my experience it's basically like a senior C++ developers just pair with me all the time, 24 hours, because sometimes I work in very weird hours and then it's always there and then so patient on explaining every dumb questions I have.
Speaker 1:What was the thing that got you to start using Cursor and what were you using before Cursor? I guess I don't mean to make the assumption that you were on VS Code before, but how did you get to Cursor when I first learned?
Speaker 2:Ruby, 10 years ago I used Veeam and then NeoVeam and then two years ago I switched to VS Code. So you were right, I was using VS Code.
Speaker 1:It was a pretty good assumption statistically speaking, but I just want to make sure.
Speaker 2:I think half of the community uses VS Code, according to the latest survey. Yeah, so I was using VS Code, but at the time I used it the copilot was not very good. But then we heard Cursor and AI is super good and as a developer working around DX, I kind of need to know how good it is and how in ways we could, for example, provide context about Ruby better into feeding these tools. So, yeah, I gave it a try and then at the beginning I also like writing Ruby. I assume maybe if you write Rails applications, it has enough database to kind of provide you good suggestions. If you are writing a LSP server, which is very few in the community, it's not always that smart. It's when I actually work on this project and learn a new language that is kind of blown away by its ability.
Speaker 1:Yeah, that makes a lot of sense that you're working in an established sort of mainstream code base but just in a language or maybe even a framework that you don't understand, where it kind of shines. I have not worked much with C++. Is there testing in C++ or is it all just hit the compile button? If it compiles rock and roll, you're good to go.
Speaker 2:There's definitely testing, but I would say Sorbet is a very unique project. It's a type checker, so it takes another language's file and then uses different ways to assert the expected result. So even if I were to write it in Ruby, most of the tests and expectations exist in a form of files. So it's very different from how we write tests in Rails applications, for example. You write actual test cases. In Sorbet, for example, tests are generated and then they will just grab the files with certain names and then run a result. Compare you to another file with certain names. I'm not sure if that's a representative answer that works.
Speaker 1:Yeah, no, I was just curious because it sprung to mind as we were sitting here talking about C++ and I was just hey, do you test in a language like that? Like I said, I haven't worked really much with compiled languages since high school, so it's been too many years. The other thing that I just wanted to publicly congratulate you on is your hanging parallel or whatever you call it that you recently posted on Blue Sky. That is, as someone who dabbles in climbing and gymnastics, stuff like that. That is impressive, sir, if anyone listening doesn't know what I'm talking about. Basically, stan hung from a pull-up bar and then got his whole body parallel to the ground while hanging For one second, which doesn't sound like a long time, but that is an impressive amount of work to get your core to be able to do that. Maybe if you're used to watching the Olympics gymnastics, you're like so what For someone who doesn't train as their day job? That is really hard work. So super big congratulations. Yeah, it's actually called Front Lever, front Lever Okay, I don't know names for things.
Speaker 2:Yeah, that's fair. So I think we climbed together once at last year's UB Conf in San Diego. And at that time I just climbed. And this year, for some reason, I started getting into the world of calisthenics I hope I pronounce it right, yeah, calisthenics. So it all started from one arm pull-ups and then I did right arm and then I feel, okay, fine, I did left arm and I could do muscle up. So I just keep adding things.
Speaker 1:Yeah, that's cool there's a lot of wild stuff you can do with calisthenics and gymnastics and stuff where it's just Olympians make it look so freaking easy. But if you're like the average Joe person, my gosh, anything on a pull-up bar muscle-ups, even just congratulations on doing muscle-ups. People work for years to get a muscle-up. In general, that's awesome and I'm very excited. I hope you will be in Philly for RailsConf. I hope yes, okay, cool.
Speaker 2:I'm hoping to. I will be at RubyKaigi. Cool, I will be Ruby Kaiki and then I will see how the schedule work out.
Speaker 1:Cool, cool. Well, I hope you'll come and there's an awesome gym in Philly. We will definitely go climbing when you come to Philly.
Speaker 2:Okay, fingers crossed that you come.
Speaker 1:Yeah, definitely climb together.
Speaker 2:Yes.
Speaker 1:Yeah, that'd be awesome, cool. Well, is there anything else you wanted to talk about, anything that you're working on that you didn't mention, or just want to dive back into Blockers? Anything before we wrap up, perhaps?
Speaker 2:not these two projects. Basically captures the recent three months of my life.
Speaker 1:You got a lot on your plate, but all of it is very good work that I know a lot of people are very appreciative of. So thank you on behalf of the people. I at least know that love the LSP and Sorbet and improving Ruby documentation.
Speaker 2:So thank you for the kind words.
Speaker 1:And thank you for coming on the show. I really appreciate you spending time to talk about all the cool stuff you're working on.
Speaker 2:No problem. Thank you for inviting me. It's been an honor.
Speaker 1:We'll definitely have you on in another couple of months, when you're inevitably on a new project and have a whole bunch of new cool things to talk about.
Speaker 2:Yeah, I can give you a one-year update about Ruby documentation, for example.
Speaker 1:Always something new, right? Yes, awesome. Well, thanks, stan. Thank you See you guys.
