 So hello, good morning. I'm Jesse cook. I'm working with Thunderbolt Labs, and I'm here to talk about maglev I'm a little nervous. So if I throw up like that guy just Take pictures and tweet to ruby friends That'll make me feel a lot better point and laugh also So there's this guy obby Bryant and back in 2006 before sorry in 2007 before rails cough He wrote this really cool article called ruby and other gems and in it he talked about this Small talk product called gemstone, which I had never heard of And he likened it to rails what he said was that rails is this framework that does all this kind of cool Persistent stuff, but there are these other products out there Specifically gemstone that do a lot of stuff for you Of course my slide is kind of cut off So as he he compared basically the storage engine the memory cache and the worker processes And likened how we use you know a relational database to store objects We might use like memcache back then or read us nowadays to do some type of Shared memory caching and then we have our actual app servers and He thought that it would be really interesting To try to get this working in ruby and so He ends his art his little blog post saying so there you have it gemstone It's like rails, but faster and easier if only it ran ruby and this sparked a really interesting conversation That ended up with this product called maglev, which I'm here to talk about today So what is maglev maglev is a ruby implementation? Just like there's MRI Rubinius j ruby But it is built on top of a small talk product called gemstone s and Gemstone the company has been around for 30 some years now gemstone s has been around for 2025 almost 30 years It's a very solid product and it offers some really interesting features that make Our lives as ruby is a lot easier in terms of persisting our objects And there are some other really cool things inside of maglev itself that I hope to talk about today so gemstone s the product is Basically a small talk VM that has a built-in object database and It's a used in in mission critical applications all across the world UBS uses it Jack in the box uses it, which I think is mission critical Oocl a shipping container company uses it to manage all of their Shipping containers millions of shipping containers worldwide But the the reason why I think it's so special Is it has this thing built in called transparent object persistence, and that's the object database that's Available via the small talk product So there's this great quote by obdi grimm. He was One of the rogues and he said I've often wished that I could just do something Or I just change a bunch of models and at the end of the request cycle something magical happened Some something magical goes through and collects up all the models that I have changed and persist them I haven't really gotten to that level yet Sometimes I feel like active record is holding me back from that of course talking about a typical rails app this was on a ruby rogues episode with David Larraby talking about domain-driven design and David chimed in with a punchline where you can have that you just have to switch to Java or net and I was driving and that made me really sad Because that's not actually true We've had this awesome maglev product But it doesn't quite have a lot of knowledge or adoption yet, so The other interesting thing is right after I heard that as I was driving up to Seattle I Was passed by an OOCL truck So they are all over the place. It's a pretty neat. So gemstones everywhere. They they It's a great product So Sorry, the P is cut off Thing that we deal with on a day-to-day basis is basically that persisting objects is hard I Think that when we come to the relational model There's and I'll talk about a little bit in impedance mismatch between what we have in our Ruby application and then how we store our data and the you know relational databases do a very good job of this You know people use the document databases people use Redis all sorts of cool products, but To an extent it starts to fall apart You have to split up your data you have to have parts of your data stored over here and we all we all know this right we all build Applications we use Postgres or MySQL or whatever But with maglev you don't have to do that because your objects As you design them in your Ruby application can be persisted and used anywhere So persistence in OO Going back to small talk was supposed to be simple It basically was something you didn't have to think about you could create objects in your running program And then you could close your program and you could open your program back up and your objects would still be there It seemed like a really nice world to live in And so, you know small talk has that and that seems to be fantastic and it's it's Enabled by this thing called the image and that's basically how I think of this kind of like fusion Plasma ball where you have all your objects floating around And they can all their relations and everything is just connected So currently, you know as I said we store objects as rows in databases You know relational maybe we store them as documents and something like Mongo or React As they're marshaled to some other data format Or even as strings and redis Which is kind of a little bit of a shame because we're ripping apart our objects and we're ripping apart the relations and I think from a Holistic point of view that's kind of a mean thing to do your objects But we have to for most most of things we want to get done But the other thing that does is there's kind of a It's a shift in the way we have to think about Retrieving our objects even so you know we have the the typical find by name finder in Rails Or we the user create is a bit more simple, but you know This is basically the API that we use to talk to our database But it gets thrown down into some query language. It's transferred across the wire via strings Which is a pretty primitive way to talk about this rich world that we live in with objects And the other thing that happens with these other storage systems is that they start leaking into our code And so you can think of SQL as being like a the leaky abstraction with object-oriented programming where you have finders that are You know need valid SQL in order to Find the things you that you need to find so One of the the terms that really bugs me is poro plain old Ruby object And that's one of the things that we kind of tend not to deal with too much in our in like a typical Rails app, let's say because What developers usually think about is the the storage mechanism And so, you know, it's not that I have a post and post is just a normal class It's that a post is an active record object and in order to solve a bunch of problems or to Avoid a bunch of problems you have to generally think about The object as an instance of an active record object not as just a plain old Ruby object So this kind of speaks to the object relational impedance mismatch, which is this fancy term for You know, you've got your objects over here, and then you have the way to store them Over over there and over there could be who knows where right like it's kind of nice That's a bit of a black box, but it's only a black box to an extent. There's You know, you still have to to to know enough about it and there's really there's some great articles you know the the Cunningham and Cunningham the C2 wiki is a Fantastic resource to read more about this So getting back to Abbey back in 2007 he gave the keynote at RailsConf and He was kind of talking about this gemstone product a little bit and he said, you know The future of Ruby is here It's just that we have it over in the small talk world and you guys should come and get it and he was mainly talking about having a fast VM and having a Nice persistence model that you essentially don't really have to think about And so we have that with maglev So I'll kind of start with a simple example to show you what it's like to work with maglev So first let me kill this for a sec. So maglev is a a Ruby implementation right now. It's 187 that's targeting 187 there's a team working in Germany to get it up to 193 and then hopefully ruby 2.0 soon But it's a it's basically ruby except it's got what you could think of as an object database built into it So I'll go through some examples to hopefully get you a familiar with What it's like to work with maglev so the first thing Is there's this there's this notion of a persistent route and Make sure I don't get too close. So the persistent route is Where you want to stick anything that you want to persist? And so what I mean by that is let's say I've got a class And I create an instance of the class my cat Pierre Now I go through and I kind of add the persistence the persistent route is essentially kind of like a hash Or actually it is a hash and so when I add Pierre Into the hash and then I run this thing commit transaction My the the instance is just basically magically saved right so there's a bunch of stuff that happens on the back end the VM Stores it in memory, but then it also takes a Representation the same representation that's in memory and it writes it to disk And then this is available in any other instance of Maglev that you boot up. So let me let me say that again. So I can persist An object in one running VM and then I can pull it up and have that in the same instance of the object in another VM I don't have to go out to a database It's just there And so you can see that here Basically, you know, I this little example is me just showing you that Pulling up another VM. Oh, and by the way, I call it prute because having persistent route everywhere is kind of long So it's a very simple mechanism and that's what's really nice about it. It's very easy to understand. There's no save There's there's not necessarily any validations though there could be it's just a very simple notion of transactions So the maglev VM the gemstone VM basically has two modes it has the default transient mode and a persistent mode and so the transient mode basically Being the default means that when you start running it any instance that you Create won't necessarily it won't be necessarily saved To the stone which is kind of the database That everything shares and so what I mean by that is you can still Have things kind of local to the VM, but there's still It won't be saved off and then available to other VMs that connect So you can run in a persistent mode and the persistent mode actually Allows you to Essentially save like whatever It they both start what's like a transaction. So maglev is transaction based But the persistent mode basically wraps your whole program in this persistent block and anything that's Required any classes that are defined are then you're able to persist them so transactions right so Transactions are pretty simple to understand you begin a transaction you Might abort a transaction if you don't want the stuff anymore, and then you commit a transaction And kind of a simple way to think about Persistence So when you start up a maglev VM, there's an implicit begin transaction If you want to throw things away and start over you can abort a transaction And what that does both begin transaction and abort transactions kind of grab a fresh view which I'll explain in a second So maglev works by having this gemstone VM Kind of running Wherever doesn't doesn't necessarily matter where it's running and then in the gemstone parlance, but we'll call it they call them gems, which is a running instance which is the Little blocks at the bottom So what happens is when you abort a transaction? The running gemstone or sorry the running Ruby program essentially grabs a fresh copy from the stone So anything that has changed in any other VM is then available locally to your VM to your gem so you get essentially like a snapshot of the database and On the flip side when you commit the transaction Things are basically pushed back up to the stone so it's a You know, there's there's It's kind of like, you know active record save to an extent But it happens across anything that's changed in your in your program since the last time you boarded So one thing that gemstone has that's really powerful is what's called persistence by reachability and As the example kind of shows which I'll explain Is it basically you don't have to stick everything into that persistent route? Anything that is inside the persistent route Anything that is attached to something that's inside the persistent route can be persistent So the example here is that I have an array Oh, and by the way all like the like normal classes like strings Arrays hashes those things are all persistable kind of by default You know anything special with those So I have you know an array and I put an instance of a cat in it and I'm actually persisting the array I'm not persisting the instance of the cat itself and When I start up another VM I can pull that out and it's the same object so notice I'm actually comparing the instance of the cat that's in the array not the two arrays So that's essentially persistence by reachability and it goes all the way down the graph, right? So if my cat Pierre has an array or whatever of toys and I append a Ball of yarn to it When I go to get that back out later. It is the same object So it's just they're the same objects all the way down the graph So what are things we can easily persist today? With you know active record or any type of ORM. We've got arrays lists essentially we have Sets which is basically an array with some type of constraint on it Hashes either with like a redis or you know mongo or H store or whatever And then counters which get a little tricky because you you know you might have to do some locking if you're using a relational or You know use something like redis. These are all things that we have in Ruby yet. We have to translate out into our Datastore And also sorted sets which is you know something that I've used in red a several times and it's a it's a wonderful feature But the common theme among all of these is I have to manage serialization somehow It's More expensive than dealing with just the objects themselves because I have to decompose the object Put it in some type of form that I send across to something else Or get back from something else and then build up the object again And I may want to use some other type of data structure that is more exotic than You know an array so something like a KD tree if you're doing some type of mapping program Yeah guys KD trees or a bloom filter Or a Judy array or something that Google told me was a leftist tree So the the point that I'm trying to make with this is that going back to kind of the mismatch is that It's not always just about our the objects themselves, but it's about the relations And it's the it's the graph that we build up like that's the that's the fun part of Programming that's the part that you know Gets me going and that you know you kind of design these systems and you you design the way that components interact with each other So closure right closure is kind of like the new hotness and and a lot of those guys tend to not Necessarily agree with a lot of the ways that we do things over in the world But there was this really interesting talk that I'm blanking on his name and my notes aren't working that one of the guys at relevance did about closure called the impedance mismatch is our fault and The one the one nice thing he had to say about oh was essentially transactions that transactions are awesome And so if you think about the way you normally do You know your rails app or your You know your ruby script whatever your Sinatra app You're not really using transactions like it's a very simple way to think about Persisting data and so I thought that this was a really interesting quote So the only nice thing I'll say about databases as they exist today or about job or other o languages The only nice thing I'll say is about transactions Transactions are awesome Transactions are composable we can understand how to reason about them, which is very important And they're part of what give databases their greatness so I've got no qualms with transactions and I thought this was really interesting because I talked to some of the implementers of maglev and I was talking with them about Datomic the new kind of closure Database they use like facts and kind of stores everything like the state And gemstone has basically done that for a really long time Like you may not be able to go back and get all of the history at each commit, but it's basically Something that they you know did 20 30 years ago that's now making its way out to other languages, which is which is great But I would like to see people kind of also use that in ruby Um, so We'll run through another quick example There's the kind of the typical blog example in in the rails world and What was really fun about this? It's just a simple Sinatra app But I was just dealing with classes like I didn't have any migrations I didn't have to set up like sequel light or Postgres. There were no dependencies So there were no drivers As long as like maglev installs like you will be able to persist your objects Which can be really fun to use So, yeah, so this very simple Sinatra app, you know, I basically load up posts and blogs If I want to get a post I just use an actual detect Right like I'm not I'm not doing like a fine by or using find ID or anything Like I'm not having to necessarily worry about You know the representation out in the other world like I just want to find Just like I would in any other like typical ruby program On the create side It's very simple, right like I just create and then I append the post to the the list of blog posts Do some redirects and like that's essentially it But what enables this is kind of going back to what Abdi had asked for which was something that kind of magically collected up all the changes and persisted them and so if we This is something that Peter on the maglev team had kind of whipped up. It's a basic rack middleware and so if you think about the request response lifecycle like you can abort on the way in and then You want to figure out if you at the end where this kind of commit if cool Method basically on the status like, you know, we want to figure out how we're gonna. Sorry if we're going to Commit the changes that have happened in this request And the commit of cool basically says well if the status is like something that's like relatively successful Then commit Otherwise abort and like that's that's it right any changes that have been made are persisted and Any other VM that connects will see that and it's a very simple paradigm And then I'll kind of whip through these they're not really that important but basically my Classes were just normal Ruby classes, right like the Initializing the the blog itself like I'm just dealing with normal arrays The post, you know I've got like just it's all just normal just normal Ruby the authors just a normal class and It's really easy to kind of get going with it, right? So if I have like what I call a bootstrap script I Can load the classes inside a persistent block and I Can set things up and then I basically just commit so there's this kind of dash M commit thing Which is the same thing as saying maglev commit at the end of the script and that's it like objects are created and they will stick around until you delete them and After I gave so I set up I kind of did this example for Cascadia Ruby and I whipped this thing up like in the morning. I thought it'd be a nice little demo I made the objects. I want to make sure it worked, right? It's like I don't know a couple weeks ago like I was kind of poking around in my in my maglev Looking around the persistent route and like there were my there was my blog and There was like the post that I the example post I'd put in there and What what kind of struck me was that they were they were the objects themselves like they were the instances I didn't have to like, you know my program contained them. I didn't have to go out and get them So it's interesting little Realization that that was a very it was very pleasant. It was Kind of a nice way to interact with my program So another example that I've talked about before is something simple like a worker queue So we have these things, right? We've got sidekick and rescue and and those are like absolutely great libraries But you can write something very similar in like 35 ish lines of code So if you think about What these worker queues do is basically you want to put something like a proc in right you want to be able to Run like a call method or something and the work will get done So an example that you could use in Something like maglev is that basically you can just you know, keep on adding jobs, right? Like let's just add jobs forever and Then we'll commit and they'll be available to be pulled off this array at some point But now the interesting thing to see here is that I'm persisting a proc So procs aren't per you can't mark Technically you can marshal procs in other implementations, but The implementers don't recommend you doing it So this is an interesting example because in maglev you can persist any object like you can persist a proc if you want You can persist threads through continuations Which people do to debug things in small talk and there's some examples in Ruby world But These continuations and I don't understand those things So on the worker side You know, we've got basically this loop that aborts a transaction. So it grabs a fresh view of the repository it Pops off Some unit of work to do and immediately commits so that That instance that worker has that job and nobody else has that job and then it calls it so One thing I haven't talked about is like a commit failure. So what happens if two VMs try to pop off the same thing? So maglev has a notion of a failed commit exception But the retry logic is really simple like it's for this is just redo Like there's there's no there's there's no other queue to manage It's you know, just a one-line change and like you're kind of good to go So on the worker side, you know, we may have a failed transaction because Sorry, this was this one on the producer side, so maybe two VMs tried to lock that queue array at the same time Or sorry append to that queue array at like exactly the same time And then on the worker side, you know, same thing with popping it off So the code is up there, but the point of this Exercise was that it was like 34 line. It might be a liner more or less now But it was like 34 lines of Ruby code just Ruby code No tests of course, but it's pretty simple to understand and so I was like, okay Well, like what is that, you know, I'd never used slow count before and I was like I just want to know how many lines of code it is and I don't want to have to count them myself And then he came out with this dollar amount. I was like well first of all 56 grand a year seems a little low So let's let's assume we get we get paid. All right, and we double that So this you know 776 bucks. Let's say it's like two grand right like two grand implement a Distributed worker queue system in 35 ish lines of Ruby That's a that's a very powerful mechanism to have so it shows that we can do very What would be complex things very simply because we don't have to worry about our persistence model So one of the other examples that I want to share is a leaderboard It's one of the things that Redis is supposedly great a great with and I have some friends that I've I'll be using as examples But Essentially, you know, let's say the the competition is the You know we want to get to a hundred points so I've got some users in my system and You know me and Sprout are at 99 and Shawn is at 98 points and The approaches that we can take to persist this on a you know normal like In any other Ruby implementation would be to use something like Redis So the sorted set to come up with a way to use a relational database or come up with some way to use like Ruby sorted set which Contrary to popular belief as I was flying here. I was watching a presentation. He was like, yeah sorted sets They're great. Ruby doesn't have that. It's not true. Ruby does have Sorted set you require set you'll get the sorted set like we have these data structures So we don't necessarily have to go out to these other systems to use them So it's like, okay for this instance like let's use let's use Redis This is the sorted set seem like a great tool to use for this application But the problem I ran into was that Two people could have a score of 100 but that doesn't mean that they both won Like I had another How do you how do you figure out if you know who won only one person can win this competition How do I know if it was me or how do I know if it was sprout And so the idea in a normal So kind of how you use that with a the spaceship operator Would just be to simply compare their scores, right? And this kind of you know gives us a nice simple way to compare to leaderboard items But a better winner criteria is the first person to a hundred points and I Actually contacted Peter that works on Redis and I was like hey like is there a way to See who got to a certain number of points first and unfortunately there wasn't Which kind of put a big damper on this new somewhat simple criteria Because in Ruby it's like just you know one more kind of set of Comparisons right so first I see like two people are Similar or sorry first we compare on score and then if the scores are the same then we compare on the time stamp of the score And so using Redis You know the the advantages were that it was always sorted on insert, which was great and Redis is super fast but the Cons were that it only sorted on one score criteria, which was essentially like useless for for this application when a new requirement came in And the Redis driver always returns an array It'd actually be kind of nice for sort of first sets if it did return an actual set, but it doesn't So, you know, we could have done this with a relational database So one nice thing is that it can sort over any field So we could have gotten the score and the time stamp But and it's relatively fast, you know the my sequel and Postgres are pretty quick, but The the downsides are that it always sorts at query time So you are constantly figuring this thing out every time you request this you're you're figuring out What the what the ranking is and again and it returns this I could make it return like a sorted set But the driver itself just returns a list, which is not necessarily what I want to deal with So the nice thing about using the sorted set in Ruby was that it was a richer data structure Like it actually made sense to to use this thing. We already have It was composed of Ruby objects like instances of the leaderboard item class, which was which was really nice Like, you know Ruby's a programming language. It has objects like let's use them it does sort on insertion and I could sort over any criteria with the spaceship operator The only weird thing I found is that if things depending on how you set it up if you you might have to sort before you iterate If you change things, but it was kind of a minor thing and Not really that big a deal performance wise like it didn't matter so the moral of the story was that You know, I was able to keep the logic when I when I did this this Example I was able to keep the logic in the app itself like in my Ruby code. I didn't have to Figure out what was going on the database itself And I was able to use data structures that we have in Ruby and If I didn't have exactly what I wanted I could build them myself like it's you know Ruby's awesome I'd build whatever I want. So if I wanted to build a data structure, I could use it The reason why I included this example is because with maglev it would have been absolutely trivial to do this and persist this across any number of You know app servers Or any anything that could basically connect to the VM those things would already be there the sorting would work everything would just work So the one thing that I really wanted to do not like a live demo, but well kind of a live demo and I Heard that's risky So I didn't do it, but the fantastic thing about maglev is that it's distributed and so What I what I mean by that is So if I have a stone Running on this computer and I start up any number of those little gems like you know maglev ruby run some code It will connect to this local machine and it will have all those objects and that's cool But where it's really powerful is when you distribute it over servers Anywhere so these objects the stone is really smart about how it moves these objects around and Since the transaction approach is very simple any Computer that can connect to a stone Can see the objects that it's allowed to see because there's all these crazy Security policy things that you can do in the VM And so what I wanted to do and I Didn't Was to get you all to help me with this Because it's actually quite simple for you all to see what I have on my stone You basically, you know use rake to kind of interface with maglev So you start up this thing called net LDI and then on the stone So that this could be my slice up and up in the cloud or whatever You start maglev right and so I have this object repository up there in the cloud and as long as you can connect to it You would be able to see objects and you would be able to make changes and write new objects and So on my laptop all I would really need to do is Start net LDI which basically does like starts a demon and then connects or make sure ports are set up and stuff and Oh, I totally forgot That looks like crap Anyway, so I would connect to the stone host Which would basically say which would connect the maglev running on my laptop to maglev the stone up wherever and I would be able to see Sorry, it looks bad the exact same objects. So that's what I mean by like a distributed object persistence You don't have to have like active record code over here and active record code over here You don't have to build up a gem as long as things are in both Sorry, as long as the instances are persisted to the stone. They're available everywhere And so, you know, one would think that the killer feature of this is the transparent object persistence But I maintain that it's the distributed transparent object persistence And that's that's what will allow people when they when you start playing with this to do some really interesting things much quicker much Easier than you would if you were to use, you know a relational database or some other data store so Mott's talked about motivation and I'd like to share Some motivation as to why you might want to play with maglev So first of all, you will only ever deal with objects. You won't deal with rows You won't deal with documents. You won't deal with like however Redis store stuff I mean, it's keys, right? Essentially keys as They're sorry strings is keys, but You will only deal with objects. That's a really nice world to be in You get to learn from the past like I'm just now learning how Okay, small talk people are of course smart, right? but like they've done so much and They've like the history is so rich with so much to learn from them in Terms of implementing, you know VMs, which you know Rubinius did with its C++ VM in terms of best practices You know all this kind of stuff like it's it's a really great way for us to become Better programmers And it makes your life easier like you don't have to worry about You know like is your database server down because with maglev either Your program runs or it doesn't and if it doesn't run that means it can't connect to the stone and like that's really simple You don't have all these dependencies out there everywhere that you have to keep track of So I think I've only got a couple minutes left I want to say I'd love to actually try out the distributed thing on a larger scale I've really only just tried the distributed thing like on my laptop But I'd love to get a bunch of people together and see if we can't get it working On a little bit of a larger scale. So if you're interested in that come find me I'll take questions if anybody has questions for a couple minutes. This is gonna hurt isn't it Josh? I think SQL queries Yeah, I haven't looked into so the question was you know Does gemstone have like this or it does have this SQL type query language? I actually haven't really looked into that too much It does have built-in indexing So if you're you can if you're I guess worried about Performance to an extent like maybe you don't want to pull everything down I mean everything pretty much comes down anyway like the VM handles most of that for you So it's kind of nice. You don't really have to think about it But there's indexing stuff that's built in that helps with some of the performances of queries if you if you need it Let's go Okay, so sharding there's no sharding because there's basically the stone There could be some I guess Thank you, so As long as you can like network attached storage you can grow the size of your repository So it's basically limited there the actual stone the number the number of objects essentially unlimited You can store whatever you want to store what you may be able to have Like the VM will push stuff off to disk when necessary and it'll pull stuff off of disk when it needs it But in terms of like the number of objects you can store It's unlimited because you just need more disk space. You basically tell the the stone to like use another extent and It can grow so as long as you have like network attached storage or some way to add capacity That just sounds what you're describing those sounds like for certain types of applications where you want to have a bunch of servers with like data in memory Because you just your data set is of such a nature that you can't really You can't wait to swap like Google search for example Yeah, so I don't think Google would use would you would I mean that's a I guess that's a different problem for normal applications Like this for something, maybe not exactly So OOC L like they've got a global Network of offices People are creating objects all the time And you know, I'm sure there are things deep down in the VM that you can I think I know there are things deep down the VM that you can kind of tune But the kind of the whole point is that like you get whatever like you get what you need Like the VM kind of gives you and if it can't find it Locally it will go find it kind of up the tree like the network tree to wherever the stone is Yes other instances so the question was does maglev persist the class definition so classes are objects, so it persists them and Yes, so if you do add a method it will get picked up and there aren't strategies for like migrations Which haven't been thought about a lot in the in like the ruby version But in small talk they kind of have that figured out there hasn't been a lot of work done quite yet I don't I don't know if we actually have more time. I mean kind of much time as we want because we're at lunch Let's take a look. Yes. What version of Ruby does it run? so Maglev right now runs 187 it runs most of 187 and They're working on one nine support right now. Yes So the question was about reporting or data analysis, so There are things built into the VM itself that kind of give you a lot of like the analytics you might want but you know You have objects and they're just there so you could kind of like build up whatever type of reporting you want And that's something that oh Oocl chose gemstone Back in like the 90s because you know, they've got offices everywhere and they have each office has different reporting Requirements and so it allowed them to you know do massive reporting stuff Right so So the I guess the statement was that you know redis is cool because it's oh How do you so you don't I mean so the same thing you would right now like if you have a JavaScript app But your back end is in Ruby. You're gonna use JSON. So the same thing in using Maglev essentially but the the power is that if you need to Build up some other component of your application in Ruby. You don't have to duplicate Code you don't have to like the objects are just there Like I know I kind of like wave my hand when I say that but I swear to God like that's that's how it works Like they're just they're just there like it's great And when you start playing with it, you'll see that and hopefully it will blow your mind Yes So the queue is something I one thing about the queue I whipped it up and like five minutes like before a talk so it is not It is not great, but it yes, so Okay, I think that's it. Let's go to lunch