 Hello So I'm very proud to announce the next one. Terence, who works for the Ruby team We'll talk about Rust and how to make how to use it with Amruby and Windows, and Yeah, you know, you come from a long way from Texas like Pecos and My friend, Terence. Thank you. Thank you, Kristoff Yeah, so I'm here to talk to you about Amruby, Rust, and Windows, probably all very niche things to probably many of you in this audience I recently got a Windows laptop at work, so I'm pretty big on a Windows high. I did half these slides on Windows Like Kristoff said, I'm Terence. I go by hone02 on Twitter I'm famously known for my blue hats. I have blue hat stickers here if you would like some I work at Heroku Work on Ruby stuff there as well as some other things I brought some shirts and stickers and stuff so come say hi be happy to give you some swag if you would like Come from Austin we have some amazing tacos if you ever in town Definitely hit me up and I'd be happy to take you out for some tacos. I think only like five people actually For all the talks I've given actually hit me up on this and I also run a conference in town called Keeper Be Weird, so Please submit the next time we open our CFP for that And that's kind of it for the intro. So let's actually get to the meat of the talk So today we're gonna cover Kind of the state of Windows and Ruby hint not a very good one Go through a quick intro of Emberby and Rust because I think many people here are probably not familiar with Either or both of those technologies talk about how to use Emberby with Rust And then kind of any future work and what we have going on with all that stuff going forward So with Ruby on Windows The Heroku CLI used to be actually written in Ruby and then we rewrote it and go and then we're looking at various plug-in systems and Ruby was on the table at one point But it got quickly moved off because of the fact that we have I think like 50% of the people that hit Dev Center Which is our documentation site or actually Windows users and so The fact that Ruby does not work very well on Windows Made it where it wasn't actually a viable option anymore even though we had a ton of people in the house who Didn't like JavaScript and that was kind of the technology that you went for there was actually this huge GitHub issue Internally that was talking about like why did we pick this thing? because like a ton of people hated writing plugins with it, but it was technology we picked because JavaScript on Windows is actually really good. So if you go to the Node.js page They actually have binary installers for all the major offering systems. You can download the source code tar ball But like most importantly you can actually just download a Windows installer and install Node and get it up and running through a wizard that like people on Windows or normally would expect In addition to that like Microsoft for the last like few years have been invested heavily With Node and JavaScript on the Windows platform to get it up and running working well making sure all the libraries and things Work out of the box as a great experience on Windows and if you have problems like they're definitely there to like try to fix that stuff So all those decisions help make it an obvious choice for us even if it wasn't the technology choice we would have liked to internally as a company and In addition to JavaScript like Python actually has pretty good Windows support. It has a fairly decent size Windows community and again like they have this pattern of having Windows installers right on the Python home page You can go and download it and just like install Python fairly easily And it's super popular in the academic community sci-pi and all that stuff Of course if you go and look at actually installing Ruby I think when most people get talked about like, okay, how do I set Ruby? I'm a new Ruby user I've never used Ruby for you probably get told to use one of these like Ruby version managers CHJ Ruby RVM and Ruby build, you know I use RVM myself and I know playing people that use all the other stuff But of course like all this stuff actually depends on bash So out of the box This doesn't even work on Windows and if you want to work on Windows You have to install like Sigwin and kind of go through all that stuff to get this GNU compatible shell system And then if you want to actually use something that is more similar to like a normal installer You can use Ruby installer, which is this fantastic project But this is a post from December, which wasn't even very long ago about how the current maintainer is looking for a new maintainer to help them out and They still don't even have like a Ruby 2.0 Install because it takes a bunch of time and effort and work to actually package up all this stuff to get it up and running And this isn't even like maintained or supported by the core team But it's not like the core team is actually against like any of this stuff It's just we don't package up any binaries for any operating systems We just provide the source tar ball and ensure that actually compiles and works So that's not great like the install experience not so good We're really pushing Windows people away Whereas I feel like the node in Python examples like they're really embracing the fact that it's really easy yet up and started on Windows for that particular ecosystem. I mean, there's a lot of Windows users out there So even if you go through all these hurdles to get all that stuff running Your experience of using Ruby on those platforms if you've ever tried it or worked at like a rails bridge or rails girls You well know that it's not great. So Nate talked a little bit about forking stuff and in last talk, but unicorn is Was least one of them is one of the more popular forking web servers out there And it blatantly just does not support anything on Windows And that's because I think the the Ruby source code does not actually work on Windows for being able to do forks You can't even do it so that doesn't work and then We have this whole like cross-platform Ruby gen ecosystem with architectures But like older versions of no kigiri. So if you're using no kigiri 1 4 2 1 It is a window specific version of the binary to fix bugs that were in 1 4 2. You can see that it was yanked But if you're debbing on Windows and use this version and then you try to deploy it on any other Unix system Like that deployment would fail because this version doesn't actually exist on any other architecture So there's problems that has been mostly solved But they do exist of just like different version numbers don't match the different architectures So potentially there are other problems of just like trying to use Windows as a development platform And so kind of the short is that we don't really have a very healthy Windows ecosystem if one at all It's kind of a best effort for like I think every gem author because most people just aren't using Windows as a primary development platform So Now that we've kind of set the stage about like how Windows isn't great for Ruby Let's talk a little bit about mruby. So for those of you who don't know mruby stands for embeddable Ruby And it's a implementation of the Ruby VM created by Matt's mainly catered towards kind of embeddable devices Where you can embed this language like Lua into other languages Commonly this is done with languages like C. It's very easy to interrupt with C with mruby And it supports kind of the main syntax and ISO standard stuff that you would expect from Ruby But as big caveat since it has to actually work with a bunch of different architectures and work on embeddable devices like Arduino's or Raspberry Pi's and other things that don't have necessarily a full like Unix operating system behind it None of the like operating system level standard library Things that you're used to having an MRI exist on mruby out of the box So you don't have stuff like file or socket or any IO built into mruby Things like threads or forking isn't in either because those are operating system level features But what you do get is you get this subset of the Ruby 2 1 syntax and language so it feels like Ruby because it is Ruby so you get prox blocks you can monkey patch you have hash literals like You can just write them in line or arrays which is not true and a lot of other languages like if you try to write a hash and Java you actually have to like can use a constructor and then actually like index into each one individually to do that Whereas in mruby you can just do it like it was in Ruby And Since we don't actually have all this stuff in Cinderlib You have to depend on some type of ecosystem to get a lot of these libraries, right? So the equivalent of Ruby gems is called An mrb gem so inside of mruby you have an mrb gem Which is this rake file that is basically just like a ruby gem rake file Specification gem specifications, so you have a name some metadata you can add some dependencies should look pretty familiar for anyone who's written a ruby gem and actually out of the mruby distribution there is in Core set of mrb gem, so since mruby is meant to be embedded a Lot of the stuff in standard lib is stripped down So you have like a smaller version of array if you want to access a lot of like extra fancy features Like slicing and other things you actually have to pull that in because you may not need that normally So you don't package the kitchen sink by default you actually slim it down to be as small as possible So people who do need that feature can actually just bundle in mrb array extension or like the numerator thing for things They actually need so you can actually bundle in just the things that you need and not like everything that is in standard library unlike MRI And there's actually this thing called mgem list Which is kind of the central repository on github that maintains a list of all the mgems that are kind of publicly accessible and There's over 400 last time I counted so not like a generous number, but it's not a miniscule number either So you can get access to things like socket XML parsing. There's a reddest client. There's a bunch of encryption stuff and so More often than not like a lot of the stuff I've actually been able to find for kind of day-to-day kind of things But there are definitely other things that I've needed that kind of just aren't available But what is kind of the state of Like we have this fresh ecosystem because you aren't just using ruby gems because you can't just use a ruby gem because most ruby gems expect Standard lib to exist. So like just taking the pure Code of ruby gems and trying to run that mrb doesn't really work super well if that library doesn't exist In mrb, so we kind of have this fresh start to be able to rebuild this ecosystem out there And so the support of mrb gems and windows today is not necessarily the best because most people who are writing mrb stuff come from ruby and That means you're taking existing ruby code and trying to port it into mrb So you're taking stuff from standard lib. You're probably building an interface like there's mrb. I owe which is actually just support of the IO module from standard lib as an mrb gem And of course, that's all kind of this POSIX Unix based format and so Making similar mistakes today in mrb gems So as an example with mrb mrb socket Zachary Scott last year basically added a patch so it could actually compile on windows last year And when I was talking to him on the phone about this He told me he actually just copying pasted this code from stack overflow and then submitted a pull request and it got merged in and like It's from some other library that made this bunch of the socket stuff work And so, you know, that's if this is like the save the art of like windows support. It's probably not like super great And like two years ago, I was doing some stuff with mrb emel so I took someone else's mrb emel forked it and I was trying to get it to cross-compile on windows and Liby emel by default like out of the box if you just take the seed library works on windows fine You can pile it with on visual studio. You can pile it with canoe and all this stuff and it works great But actually cross-compiling it took like many many Friday nights Which I'm sure could have been better spent doing other things, but you have to figure out the This like yamal declare static C flag that I need to pass to actually like compile it statically And because the dash-ax static flag that worked on unix just didn't work properly when I was cross-compiling Because the way it does like operating system level detection So in order to kind of like make all this stuff work You have to for even see livers that work out in windows You have to kind of dive in and figure all these pieces out and of course like Building inside of C is like a special place because like every C project decides like have their own different like build tool So you're either using C make autocom scones or something else and like you basically have to fight that system and learn this new Other make system every time so that wasn't super awesome and Kind of at the end of the day like I was saying before we're we're basically taking all these existing Ruby projects And we miss them because we want to be able to do productive things And we're just porting them over copying the same mistakes that we're making MRI for supporting Windows Which is not super awesome so That's kind of the short intro to M Ruby And so I want to take a quick tour of rust. I've been playing with rust a lot recently It's probably mostly you who does fault And for those of you who don't know it's a systems programming language So similar problem space as something like C or C plus plus So if you're writing native extensions and Ruby, you know, you're writing stuff in C Ruby the language itself is written in C And what makes it really compelling is that they make these safety guarantees about preventing seg faults And about threat safety and things that are readily relevant. I guess like in today's like multi CPU architecture stuff and One of the things that you who to really harps at me about with rust is that it's an enabler of a language And what I mean by that is that it enables people a lot of people now To pick up something like rust who may not have been Comfortable or familiar with picking up something like C and felt comfortable actually writing it not that these particularly Hard to pick up but it's not easy to become good at writing C Actually write system level programming code That works and you can feel safe about not leaking memory And so kind of to hit this point even home even more so no sugary I'm sure many of you used it if you're using any Rails app the XML parts that's built on top of lead XML to These are people who are pretty seasoned like C developers for maintaining the C extension on top of live XML to if you just search There are definitely like seg faults that happen. So like even people who do see On a regular basis can still make mistakes. I mean open SSL, right? Like there's just tons of stuff out in the wild where this happens all the time And these are people who program and see like every day and So I think one of the really compelling things that rust makes with regards to safety and with enablement is that if you can successfully Compile a rust program It will not seg fault at runtime. You may run to other problems But it actually won't seg fault and that's a really amazing guarantee to make as a systems program language And the way it she it achieves that is through this ownership model the fact that through compile time It can actually track how memory is being referenced and used so you have to write your programming in a different way but The guarantees you get are that the compiler is actually making sure that the way you write your code is Making sure you're not leaving any dangling pointers around And the next point that is really interesting is since it's a system for language it has to be fast And so if you've ever done any systems running language stuff You've probably written stuff that looks fairly similar to this. This is actual rust code And what I'm trying to do here is fairly simple. I have an array. I'm just trying to calculate the sum of it And so if you're doing this and like some intro programming class or probably you have this array You're going to iterate over through the thing using some for loop and then you're going to hold the sum and some variable And then we'll just print the value at the end. So this is a pretty Easy example, even if you don't know any rust you can easily read what this is doing So but this is probably more what you're akin to in Ruby So you have these like high level abstractions. This again is valid at rust And so you can make an iterator on this array and then you call fold which is like inject in Ruby and it even borrows thanks to you who the pipe syntax for specifying the variables and so with here We have a starting value of zero and we're folding over the addition of the starting the carryover accumulator sum and then each element value and then at the end of it we get the total sum value so this one line Looks much nicer in more Ruby like than this and this is a valid Rust syntax just built in the standard library and what's amazing about is you aren't actually making any trade-offs here on performance by using this Better abstraction right like using fold is actually faster than writing the for loop because in rust The compiler now knows about the bounds of that array because you're using the iterator So you can actually unfold the entire thing in assembly and not actually loop through it So you don't have any of these jump calls And the more information you give the rust compiler the more optimizations it can make so that's what rust Means by having a zero cost abstractions that by using these higher level abstractions You're not actually making performance trade-off like you would oftentimes in Ruby by using some of these other nicer functions to make your syntax look nicer So that's really awesome The next thing that made it really compelling for me to start looking at it seriously was that they have this Focus this over in 2016 on cross compilation and they're betting even more on it in 2017 And so as part of it there's this tool called rust up which is part of the rust toolchain That you can use to basically manage Your different versions of rust as well as kind of the different targets and architectures you want to compile for so on a single host you can actually Compile they provide 36 different architectures that you can compile to and for interest for me They provide a lot of the major ones that I care about so you have 32 and 64-bit OS X Windows on GNU and v visual studio As well as muscle and GNU versions of Linux so from my single Linux host OS I can cross compile to all these different versions of rust and make libraries and binaries that are compiled And one of the other things that were was really great for me was reading the rust up remean They have this line. They have a section called rust up on Windows and the first line is this thing right here where it says Rust up works the same on Windows as it does on Unix and so that means they're treating windows as a first-class citizen And Russ as a project Actually works on Windows and has to because Mozilla is deploying Rust as part of Firefox now so as of last year in Firefox 48 It was the first release of Firefox that actually ships with Production rust code and so the piece of code they extracted to rewrite and rust was the media media player so the media player is written using rust and they're able to kind of sandbox it with these safety guarantees and They have to actually make windows work because they're shipping it with the browser so So Mozilla who is the kind of main steward of rust is betting on rust working on Windows So I have a lot of confidence that using this as a base technology for getting all this stuff to work Will guarantee pretty good Windows support because it means all the low-level IO stuff has to work pretty well In addition, they have a bunch of r&d work. They're doing for browser stuff in servo that extends beyond just the Firefox stuff And of course as a person who's explored other languages one of the things I miss the most when visiting on the ecosystem is Bunder like having a good package manager is actually really crucial to being productive being able to kind of Have these guarantees of like does my code work and will it work on someone else's machine? And Having visited the sea world of autoconf and C make and all that stuff It was really nice to know that you who don't Carl helped create cargo as well as bundler so you see a lot of analogies in both the way it works in workflow and as Kind of the common paradigms were used in Ruby So in rust you have cargo dot Tom all which is equivalent to your gem file But it isn't just a dynamic DSL just uses the Tom will mark up and you can kind of just best file your dependencies that you want Like you wouldn't your jump file And then you have cargo build which is a command you can run on your machine locally And this goes like button stall goes in fetches and resolves all the dependencies you have So I only had two dependencies here, but it went and fetched all the dependencies of those dependencies and created a resolution graph for me and compiled The rust library for me So I don't have to do this thing and then figure out how to actually build my project cargo build actually does all that in one Step so like button on saw it's like the only thing I really need to know to actually get my code to a running state So if I'm cloning out in another rust project, it's very easy to get started once you have the tool chain And then beyond that you have cargo lock which is equivalent to your gem file lock And so it has the complete dependency resolution graph built into the file So it can be reproduced on any other person's machine So with that Knowledge like how do we combine this mruby ecosystem and technology with kind of all these nice things that rust brings to the table for writing systems level programming things so I think in order to kind of Appreciate some of the stuff that's happening we have to take a look at how what it looks like to write an mrb gem in C like just the default path and This is the typical directory structure of an mrb gem you have In this example just a very simple thing where I'm just trying to print hello To the screen so in my C source code. I'm just going to return the hello string That's generally in C and converted into mruby So we have this C file so inside the source directory You can put any number of C files and you can call them whatever you want and the mruby build tool actually go through and compile all that stuff for you So here isn't the mruby C file that I generated and You need these two classes a knit and final So gem a knit is basically where you kind of construct all the stuff at startup So you're going to define your modules and classes that you want to be able to work with in C So in this case, I am defining the hello module calling this mrb defined module That's part of the mrb C API and I can define any number of class or instance level methods on top of it I can define any other classes as well and I'm making it call this other C function as the Implementation and then you have to specify the number of arguments in this case I don't have any so I can use mrb args none In the final state since we're in C and we have to manage our own memory here You have to do any cleanup work That's not managed by the mruby VM because mruby is garbage collected Inside of here, so I don't really have any dangling pointers that aren't gonna be managed by mruby here So I really have to do anything here And then finally we just have the the C code that's actually being called when I call hello And this is just a very simple thing We're taking a C string and we're just converting it to an mruby string and then that way it's accessible inside the mruby vm And with that we can actually just call Hello. Hello inside of mruby like it was any other Ruby code So that's pretty nice and easy to do and that's kind of just how Native extensions or native mrb gems will work in mruby And so to make this work with Russ one of the nice things that Russ brings to tables it has a really nice ffi system It's able to at no cost actually just generate C compatible Code so when you're compiling a rust You set the property no mangle above the method that you want So rust doesn't try to make any optimizations and knows to leave this function in that address space And not mess with any of the names or anything and then you need to extern it to make it available as a public method So with this code Inside of any C object So if I have this rust library inside of any C code I can actually just call double input pass in a 32-bit integer and it will work like I wrote it in C But the nice thing is I actually get all the safety and other guarantees of the rust library from with inside a C because rust makes those Things that compile time So that's really nice And so if I were to take that same example and try to write it in rust I'm going to create a rust folder And I'm going to have a cargo dot Tom all but I don't have me Other things there, and I just have this lib dot rs for the source code for rust and so in here You see similar structures here, so I have the no mangle So these function names are just the same as they would be called in C And one of the reasons I have these unsafe blocks here is because in rust with the ownership model You have to be able to tell the compiler. Hey, I'm not actually responsible for the Lifecycle of these objects called inside this block since this is a C call like You're actually responsible or someone's responsible for managing life cycle of these objects and the compiler is not so you're telling The compiler. Hey, I know what I'm doing. Don't worry about it. The stuff will get cleaned up And you don't have to worry about this at compile time so since I'm making basically these C API calls from mrB the C API I need to wrap them in these unsafe blocks So similar to the C code. I'm just defining a module called rust I'm putting in this class and then I'm telling it to you use this function that is built in rust But we'll look like a C function when it's actually compiled So you have the init the final in the actual rust implementation and that will get you to hello world with rust and mrB In order to do that I actually had to create a wrapper library called M for Ruby to actually wrap parts of the mrB C API to make them available in rust And so what M for Ruby is is it's this rust binding around the mrB C API and it's actually split up into two crates where crates are basically the package of the name of the packaging in rust and one mrB gem And so the reason I did this is because I want to split up kind of low-level implementation and like kind of higher-level abstractions So there's live mrB sys, which is the low-level implementation And this defines basically all of the Kind of signatures that I want to be able to access inside of rust So if you notice in this lib.rs file There is no body like actual code implementation besides the function signatures So all the all the actual Implementation is in C and I'm just defining it in rust so rust knows about it And so for instance this mrB defined module is something that we called in that hello world example And it's the same signature as the C code because it's just calling the C code here So that's what lib mrB sys And then we have this other crate called M for Ruby, which is kind of the higher-level abstraction that sits on top of this And so the reason to create this is because you don't want to actually make all these method calls every time You're doing a bunch of things And so you can create these higher-level Function calls that actually wrap all the unsafe code and allow you to just call proper rust code so this function basically takes a mrB string from the mrB vm and Conversed into a rust string so we can use it with other rusts data structures methods and things like that And I didn't want to basically do all this slicing and kind of raw C pointer manipulation Every time I want to manipulate a string because that happens basically all the time And so well the nice thing is is since all this stuff all the unsafe code is here in this method here Inside of rust I know I don't actually have to when I'm using this library Wrap this function in an unsafe thing because that's handled inside of this method So over time I'll be pulling more things into the higher-level abstraction as I figure out the API that I want there And slowly removing like the manual calls to the mrB see API directly And then finally we need an mrB gem for the mrB gem to link against and This allows us to basically use the right version of mrB that you're using locally So it's using the right version of the API and the right headers and things and not just some random So if you ever done in the Ruby debugger stuff Like it actually bundles the entire like header stuff into the gem and every time a new version of Ruby comes out it like breaks the bugger because like some APIs and stuff change so the nice thing about this is that I'm actually linking against the Version of mrB that you have locally, so I don't actually have to vendor any of that stuff into my mrB gem and so inside of If you've ever dug into the mrB or the Ruby source code you've noticed that basically there's a ton of like C pound-defined like macros all over the place like Matt's uses this like everywhere So mrB is not unique in this like it basically does the same thing But unfortunately all these pound-defined preprocessors aren't actually available across ffi So it's not publicly available to me inside of Rust or any other language that wants to use the ffi interface so we actually have to wrap all the Macros that we want from C in actual C functions, so they're publicly available to Rust to actually map to so This and for Ruby runtime actually just takes all that stuff and wraps them in actual C code to be used So with that I can actually access this thing inside of the lib mrB sys Crate because now they're publicly available C methods And so I did that really simple hello world example But that's like really trivial to actually write and it doesn't do very much so one things I wanted to do was take a Library that wasn't super complicated But was actually a real-world practical thing to be done So if you're familiar with all the doc-op project that came out from the Python community And it looks something like this like cargo uses it For its option parsing so it's an option parsing library And one of the neat things it does is it actually allows you to define as a string The usage that you're gonna do and then you pass in your Array of arguments and then it'll actually then return an options hash or map of some sort for you based off of this Usage thing that you can print as help and then the argument list So it's really neat. So you don't have to kind of do all that stuff by hand And there's a bunch of different implementations of it across all all the languages The rust one is one of the most up-to-date ones and it's well maintained because cargo depends on it But when Chris often I actually were starting to implement it and looking at it There was a C1 that wasn't well maintained or up-to-date And there was a Ruby one that we were thinking about porting from but that I think hasn't there hasn't been commit to in Like three years, so there's a bunch of changes and it Wasn't actually didn't actually have a lot of the new features that were part of doc-op So we actually chose to use C++ as the initial implementation So we wrote a C++ wrapper in mr. V gems around it and Chris stuff at the time I think was doing still C++ as part of full-time and you can see like we actually just made a simple Mistake we missed this break And it's like for people who do this stuff. It's like still possible to make these mistakes In code and all we had to do was write a wrapper around the existing C++ library to make it available Inside of Ruby and we were still able to end the like less than a hundred lines like a simple Like forgot to put this break in and it caused seg faults So the rival implementation of mr. V doc op still today is in C++ and so Knowing all that I want to take this thing and try to use the doc op Rust library and see if I could build this mr. V doc op thing Based off the C++ implementation so in mr. V. This is how you use it you have a usage thing You just have a here doc and then you just call it right like so for the C++ implementation Just call doc opt as module it takes a class level has class a little method called parse Passing the usage and then you pass in kind of all the argv arguments that you're going to have on the command line And then once you do that you have access to kind of this options thing that you can index and to get See if it actually was used or not So if detect Ruby command was run this will return true if not it will return false And there'll be ones for all the other commands that I have So this is the parse implementation inside of with rust for that document and The way this works. You don't have to necessarily read it line by line Is that you kind of have to be able to parse out? So if you were to do this and see you would have to actually parse out the arguments So you have to get both the string in the array and then kind of assign them to These locations in memory and once you have that You can you have to basically convert this stuff into rust objects to be able to pass into the doc op Rust library So the first thing we're doing we're calling that high-level mruby string to rust thing to convert the mruby string to rust And then we need to create a coolant array slash vector list Object that will get passed to doc opt based off of the mruby array So we're calling a bunch of C level methods to actually extract these values With that we can actually then call so this actually calls the doc ops library and With that we take the usage and we take that thing we just created and we get kind of the data structure that rust gives back to actually See whether options are being Correct if what options have actually been passed properly and With that we can use the data object allocation. So this is allows us to basically store the rust since it's just a Allocation inside of memory it stores it inside of mruby and so it tells rust What does it tell us it tells mruby that hey we have this data structure? You don't know how to access this thing, but here keep this in memory And so the reason to do something like this is because you don't necessarily want to do this conversion back and forth between mruby to rust and back from rust to mruby all the time because there's a performance cost from doing that typecasting construction basically so in MRI there's there's plenty of C extensions that do similar things probably the most common one that comes in my mind is no kigiri So when you're parsing XML documents, it doesn't actually convert that whole thing back into a Ruby data structure It actually just provides C Functions that are accessible by a Ruby to actually access that data structure from your Ruby code So that's what I'm doing here. So I'm actually keeping this RV map a rust data structure around and then I can access it as if it was a normal Ruby data structure So if we look back at the recode That was the implementation of parse and so this actually just looks like a hash, but it actually isn't a Ruby hash at all So that's all we had to do to actually get that to work And then as a user like you don't actually have to know that you were using rust at all right like This is the code you're using it just looks like any other standard Ruby library could have been written Ruby for all you know And then to pull then you just add it in like any other dependency and it will build in the compile So it's kind of just like the whirlwind tour of like how to get all this stuff working and running And what's great is all this that stuff compiles and works on Linux OS X and Windows like out of the box Like the CLI it's native extension. I didn't have to write any Windows specific code to make it work like it just compiled and worked and so some of the stuff that I was talking about before so things that I still need to work on is The rust see Ruby wrapper. I need to add more of the mruby see API So currently I've only done stuff that I needed to actually get doc up to work because that was the only way I could actually test whether the API is work properly And then I need to also go through and abstract more and more of the higher level The low-level things into a high-level abstraction So you actually should be able to write an entire library without calling any unsafe blocks inside of your actual library Beyond that I think that where it starts to get more and more exciting is the fact that with all this stuff done We can now actually start to write mrb gems around low-level rust libraries so there's a project called Tokyo in rust and it's actually a Low-level networking library written in rust and one of the nice things is like unlike mrb socket If we were to write a wrapper around Tokyo, it would actually just work on Windows We wouldn't have to write in that stuff We can actually kind of delegate all that work into the rust ecosystem and they have a bunch of low-level libraries out there That we can do that with And so this is where all this gets promising So same thing with file IO, right? Like I don't want to use mrb IO if I can use another thing that actually just works super well on Windows and doesn't have any caveats And so that's kind of the future direction of where I want to take all this stuff is like we can build an entire ecosystem around using this expansive Existing low-level systems for me ecosystem of experts who've been doing this stuff because they have to make it work for Firefox and other things and If I don't know if any of you have heard of the helix project but It's a thing that you who don't got for you have been working on that basic is a lot of this similar stuff But all for MRI so being able to write native extensions for your MRI code inside of rust is what helix is about And so some great use cases would be you could take parts of rails or sold parts of your code base after you profiled it We write that in rust which is this scissors programming language that is higher level to work with and you're not segfaulting and Be able to do that add that into your gem file and make that work And so the reason that's important is mostly that we're hoping to integrate all my and for Ruby stuff into helix Eventually and have a single code base and have this kind of like common Ruby universal Ruby thing where matter of using Ruby or MRI You're able to kind of do all this rust up with the same abstractions with it So kind of in conclusion, I think we all know that Ruby doesn't have a great history of Windows We're pushing tons of Windows users away and there's a lot of them out there and it's really just unfortunate. I think for us Because it makes it hard to grow the ecosystem Potential people who should be using Ruby because it's a great language with great people and a great set of libraries and things to make you productive and Emory has an opportunity to Have a fresh start. It is a new ecosystem. It's only five years old There aren't a ton of people working on it and that means we don't have to fall in the same footsteps of MRI like at this point like to change the entire Ruby gems ecosystem would be really hard, right? like there's just so much stuff out there today and I think finally like with a lot of the stuff that Russ has cared about we can create a Ecosystem with this to make a Windows friendly ecosystem that is inclusive of everyone and not just people who are primarily users of Unix So if you're interested, I'd be happy to talk about this more Online or in person, but I'm very excited to hopefully make the Ruby ecosystem Better for everyone and not just people who are on Unix. Thank you Questions I have some minutes. Yes It's a written from the ground up so it doesn't One of the benefits of doing that Besides so you do you lose tons of backwards compatibility and But one of the benefits was that the mruby C API is simply Better cleaner and simpler than the Ruby C API so you don't have all the sacred cows that you do and Ruby today And but and that also means my work for them for Ruby stuff it's simply easier than you doing Godfrey's work for helix because the Ruby C API is Was built like 15 years ago and Emerby was given the chance like Matt's was like well if I could do it again How would I do it? And so there's some nice things that you see in the C code if you've looked at both of them where you're like Yeah, that kind of sucks that you can't change that So yeah to answer your question Yes Instead of a step set of Ruby at the base of Ruby Could so your question was could mruby come the The standard base for Ruby instead of a subset of it I mean I feel like if you were to do that you'd be basically replacing the entire ecosystem there and that doesn't mean it's impossible, but it like there's a lot of stuff that has happened in Ruby and You'd be throwing stuff like rails and rack and all that stuff out the door, but I mean in theory like if you had common Ruby stuff there is a potential I guess like vision where you could write code that works on both MRI and Emerby and in that state I think that would be simply easier But I that's nowhere near close to where it is today Yes There's no I think So to repeat the question is there Incentive to put more core features of mruby into Rust or just libraries and As far as I know today like there's no incentive on the core team for well, there's really a core team in mruby It's really just mats and people who are helping them But there's no like incentive because the whole team is like everything's built around see like it is for MRI Like I think all the core level stuff is going to maintain It's see nature and there aren't really plans to change that I'm hoping with some of the stuff if we're able to Deliver on half the things that I've talked about In that last part of my talk that there will be an interest in the ecosystem to embrace stuff Like rust and make it easier But yeah, there aren't really any incentives internally to kind of change where things are today So the question was can the mruby VM be compared to the MRI VM speed wise and other differences that Okay So there are definitely a lot less people working on mruby and since it's written from the ground up It's very different. I think by Intentionally since it's embedded it has different constraints Nate touched on this. I think in the Q&A about just like how ruby is kind of this very general purpose thing And you have very opposite kind of use cases right like you have the rails app Which I think like 8% of the people that probably do ruby are using it for right like whether it's rails or some other type of long-running Damon process that's very Java like right and those constraints and concerns have very different defaults than you want if you are a IMA scripts like at Heroku. We use as part of the bill pack like Ruby and it's a very short-lived process right like it runs Maybe 15 minutes max and then we kill it if it runs longer than that And so it definitely doesn't run nearly as long and it's not allocating. You know as much memory doesn't have kind of the same constraints Where things like in rails fast boot up time is nice, but it's not a hard requirement Whereas like fast boot up time for a scripting thing is actually super important. So I think mruby is not designed in nature to be run like it is for rails And so it makes a lot of trade-offs With even the data structures and stuff like data structures like when you allocate an array in mruby It allocates anything in less space and it takes up less space Because it has to be able to be run in our Arduino right like it has those kind of constraints the benefits of that is if you're using mruby for things like Tooling or scripting and things like that you get massive speed-ups because it takes In order of magnitude less time to boot up an mruby VM than does an MRI VM even before you pull ruby gems in right And not to mention the fact that since you can compile stuff down you to actually don't have the required load problem Which you do on MRI The flip side of that is the runtime doesn't have nearly as many optimizations in the garbage collector or other things So the MRI Garbage collector is way more mature It's been around a longer time, and it's it has to have adapted and evolved for the rails use case so There are I think Things where people are looking at like running mruby as long-running things, but it's for like IOT devices Which I only have totally different performance constraints than running them on like a bunch of racks right like to power like the next school or something right so Hope that answers your question Awesome. Yeah