The BEAM-Rust Sandwich - Julian Köpke | Code BEAM Europe 2025

[music] [music] [applause] Good morning everyone. Um, yeah, my talk is about the beam rust sandwich. Before we get started, let's do some housekeeping. You can scan this code if you want to follow the slides on your phone. There will also be some links. Um let's hope you don't dodo my server when you open it now. Um you can also access the slides after the talk. There also we will have a lot of uh code on the slides. So if you cannot read the the code up here, please come a bit closer. If you look like this trying to to make out the the code. Um there there are always cats on on the slides. So I I thought I I just put my guinea pig on there uh to to counter uh the the imbalance here. Um a bit about myself. I'm Julian Kapka. I'm a software engineer from Munich. I've been coding for over 20 years, but I'm relatively new to the beam. So, I just discovered Elixia like three and a half years ago. Um, but I'm happy that I found it. And yeah, you can follow me on Blue Sky or you can also subscribe to my RSS feed if you're old school. Um, there we already go with the um DOS. I see I have 10 visitors. [snorts] Everything is a bit slower now. Um yeah, two years ago I started a new job on a startup uh yeah exciting startup and we built an app for pausing, rendering and analyzing PCB layouts. That's what you can see here. Um we used Rust mostly for performance and safety. And because everything is SAS nowadays, we also had to bring it to the web. So I created a live view application and tried to integrate it somehow and what I learned there some of the things I want to share with you today. [snorts] Um we will have four parts in this talk. First I'll do a bit of general comparison of Elixia and Rust. Then we will look into Rust on the beam. In the third part we will look into uh how we can use Rust in the browser. And in the fourth part, how we can put everything together to a nice sandwich. Um, let me know a bit about you. Um, let's do a show of hands. Um, so please raise your hand if you have coded a Phoenix live view app before. It's amazing. So almost all of you. Um, oops, that was one too far. What? Hand up if you have written code in Rust. That's around half of you. And if you have compiled something to web assembly. Okay, that's even even less. Great. So I I think I've prepared the the right talk for you. Let's let's look into uh Elixia and Rust first. There are uh some similarities. Maybe it's coincidence that both languages appeared in 2012 at least according to Wikipedia. I wasn't sure Elixia some some sources said 2011 but um let's just say they are the same age um they both built on a great tooling and ecosystem um because they're modern languages and they are both built with safety in mind even though they have very different approaches of uh yeah reaching this safety and my favorite feature of both languages is that they have a very effective way of not having to manage shared mutable state which is great even though they have completely different ways of doing this. And talking about different ways um the differences between elixir and rust are pretty grave. So elixir compiles to the beam obviously rust goes directly to machine code. Um the beam is garbage collected and uh the Rust has a borrow checker which basically makes sure during compile time that all your memory is uh allocated and deallocated and yeah everything can be baked into your binary. So nothing during runtime. The typing in Elixia we heard it today is work in progress. Um I'm actually looking forward to to having more support there but um it's not a a statically typed language and Rust is everything is uh super strict. Um and mutability on uh on the beam as we all know is not not a thing in Rust. You can do mutability even though it is explicit. So you have to um yeah mark everything you want to mutate as mutable and then the borrow checker will make sure that everything that is mutable cannot be read by anything else. So you only can have one write access or multiple read access to to any variable. And elixia of course is functional. That's why we love it. Um the uh the rust is is not very functional. Some people say it has some functional traits even though I think um the most important uh features of functional programming languages are not there in Rust. So I would call it imperative. But what makes this integration so great then? Um Rust is actually the butter on our beam sandwich. makes uh it fills the gaps and um makes it possible to use the beam in areas where we maybe not have a good way to uh to reach otherwise. So first of all it can compile directly to web assembly. So we can actually run it in the browser which we cannot with elixia and it's blazingly fast. Um there this was I think in 2019 already um there was an article by Discord how they uh used Rust to scale their Elixir server to 11 million concurrent users which is pretty impressive. So, um, yeah, it's, uh, it's a nice way to, um, to fill the gaps when you maybe notice that the beam is not fast enough anymore or when, uh, when when you want to reach a like a target that, uh, you cannot with with Elixia. So, let's look into Rust on the beam. This is our Phoenix life view server. Just a little overview. It runs on the beam and we want to place a little nif and natively implemented function inside of our application. So we can call it from our live view and yeah that should be written in rust. To do that first of all we have to add a dependency. There's a nice package called rustler which uh gives us everything we need. So we add this to our um mix.exs EXS in Elixia and then we can get started. Um we will have a shell command called mix rustler new which generates the the rust um boiler plate the the project inside of our application and in rust you will have a cargo file which is basically defining the dependencies um similar to the mixs file and there you have your name and you also have a dependency on rustler. So basically the the other direction. Um next up we will implement a tiny function the add function. It takes uh two integers and returns an integer which is just the sum of those two. [snorts] And above that function, we will annotate it with a rustler n um which tells our compiler that this will um yeah will be used from our beam directly. And below we we call rustler.init. So we can bind this to an elixia module. So um we also know the other direction how to um how to call it. And then of course on the on the elixir side we have to uh to hook this up similarly. So we we create a module in the elixir side and we just use rustler magic happens. Um we define our add function with the same um shape and we just implement a n error which uh will return by default if the n is not loaded. But if it gets loaded, this will be replaced by the actual call to our Rust function. And now we are already almost done. We just have to hook this up. So as an example, I um I just dropped it right into the he template. We call uh sandwich.backend. 1 comma 2 and we will get a return value of three which is calculated by our rust code which is great. So back end is already done. It was really simple and uh I'm actually surprised how uh how easy it is already. If you want to learn more about ns, the next talk is for you. Um I I think Ricardo will use C for um uh for his talk but in general most of the um the things you have to be aware of when you are implementing ns um generally apply also to rust. Let's look at rust in the browser next. This is the harder part. So um let's look at a little overview. We have our browser. In our browser in a Fenix live application, you have your JavaScript um with the live view client running. And what we want to do from there is we want to call a web assembly module which we will also deliver to the browser. Um and this module we want to implement in Rust. Let's have a little overview of Web Assembly in general. Web assembly is a platform agnostic uh virtual assembly format. It reaches near native uh performance um and it can be targeted by many languages for example Rust, C, C++, Cotlin, Dart or Camel. There are many compilers that um that can compile to web assembly. Um it's completely sandboxed and the specification is formally verified which means you cannot call anything outside of your web assembly. So everything you want to call you have to pass in and they're pretty sure that you cannot escape the sandbox. There was recently um there were a few um security issues found in the specification um but they were fixed quickly and um should uh should be pretty pretty safe in general. Um but because you don't have a um like a standard library, there are um standards to to use this in a in a useful setting. For example, the web assembly system interface wii is a standard to build system applications using web assembly. And one example that implements the standard is uh wasn't time. It's a runtime which is written in rust. And um for browser applications usually we need uh some JavaScript glue code. So we can call a JavaScript function from our JS code and that will pass this call into the web assembly. And to generate this clue in Rust, we use W bindch that basically looks at our annotations in the Rust code and just generates all the JS we we need and then we we can import this from from JavaScript. I will show it to you later. We web assembly is actually uh yeah used by a few quite big projects already. So um for example the Unity game engine um is one of the the big users. They basically can run their games in the browser using web assembly. Figma um they started I think with C++ um and with mcript and they compile everything to web assembly. Flutter can already build um your your Flutter apps to target the browser. They also recently switched to to web assembly [snorts] and the set editor uses it for its plugins which is actually a quite interesting way to uh to make use of this. So how do we get our code uh our Rust code to to web assembly? Um here on the on the right you see the the first um use case we had before the beam calls into our uh target function um and we do something but now we we want to have some shared functionality. So we need to pull out the the shared functionality into a shared module which is in the middle here. Um and then we we add another shim on the left which we can call from from our browser. So basically those two functions will on the one side be implemented um to be called from JS and the other one from the beam and they both call into the same function to run our business logic. And then the right box will be packaged as a uh on Linux as a SO file. So it can be uh linked by our beam and on the left it will generate a WM file and some JavaScript um so we can deliver to the browser. To do this um in in Rust we have to uh define our targets. So in every dependency you can specify for which targets it should be used and our rustler dependency when we are running on Linux of course this should only be compiled on Linux because rustler will not work in web assembly in the browser because there's no beam and our binden dependency which should only be used for web assembly this should not be compiled for the beam so we target it only for the web assembly 32 two dependency. Um yeah, then we pull our add function into this shared module and this is basically unchanged just with a um with a new module here. In general, you can or you would pull out complete modules or libraries and have a shared module for uh for your business application that is compiled for all target platforms and then have one library for web assembly, one library for for Rustler. But to keep it simple here, I basically inlined everything. It's all in one file, but uh it still targets different um platforms in in the code directly function by function. So the next step we um we implement this shim function. So the at function will just pass the call to to the shared ad. And here also we have the target OS Linux and we have our rustler n annotation. So um rustler knows this is something I can call and we also annotate the rustler init call with a Linux only because if you try to run this on web assembly will just explode [snorts] and then um to to actually call something out of our web assembly um we will hook up the alert function from from the browser. So we we will tell uh the Rust compiler, please generate a um a function I can call from outside which should be hooked up to the alert function. So when we call this from inside of web assembly, we will be able to to generate a browser alert and actually get something out of uh out of our web assembly. Um yeah, then uh next step we would use this function. So we implement the add function for web assembly. Um again we call our shared ad function store the sum in a um in a variable and then we call the alert function with a nice format call here. So we have um a bit more meat um that we actually know what's going on. And with this penion hook yeah this this will generate the um the hook we can import from from JavaScript. And before we can go to JavaScript, we want to build all of this because in JavaScript, we want to import this. And right now there's no um there's no JavaScript code and we don't want to handwrite this. So we just write a small um mix task. I called it WM. And it will just call to uh the WOM pack um executable on our platform. um it will generate all of the JavaScript files and the web assembly packet and then we just copy this to our Phoenix assets. So in the assets we can um link it in our JavaScript app.js and we can also access it um later from the browser by downloading it by by querying the um the web server to give us the the web assembly packet. And now we are ready to use this in our JavaScript. In the first line you see the import. This is the generated file we import. And from the import we get two functions. The add function that is what we defined. And in it sync is a function to initialize your um your web assembly module. And then we implement a load function that yeah downloads the web assembly packet and uh calls the init function with this um downloaded [snorts] packet. There are different ways to do this. Um actually you could also use um build directly in Phoenix to generate all of this and it will bundle everything into your app.js JS, but the web assembly will be base 64 encoded and it will have to regenerate this huge thing every time you you make a change. And I noticed during development this is can be quite inconvenient because if you have a big web assembly bundle, your hot reload will take seconds and everything becomes a bit sluggish. So I preferred this um yeah this way of initializing it and I put a link here there's an interesting article um about the different ways of initializing um [clears throat] web assembly. Yeah. And then in the last line we add an event listener so we can actually call our add function from the browser. [snorts] And here you can also see we we have to convert our types because in JavaScript everything is a float and in Rust we defined this as an integer. So we we converted to big int which will be then represented as a 64-bit integer in in our Rust code. And now we can run this. Click our button um which we implement here that dispatches our click event and will go through the web assembly code and uh call this alert function with our addition. Now we also have a working front end. I hope you're not uh asleep yet. I hope this didn't bore you. [snorts] Um, now let's uh get to the integration of all of this. Um, finally we have the sandwich. Um, on the bottom we have our uh we have our Fenix live view as before and on the top we layer the browser and what we added now is um the nice sandwich in the middle the the web assembly um the websocket connection on the left. Um so basically our live view client will connect through a web socket to our Phoenix um application and they will communicate over this socket and we want to make use of this because we don't want to have a separate overhead communicating from web assembly and it's actually quite nice to uh to use this event driven style. So yeah, the Fenix live view provides both the app.js and the web assembly and then it um it will it will serve as a as a server for um for both and we will just pass through the events from the web assembly call uh code to um to the server. So we want to keep the JavaScript glue lean. So we don't want to have additional logic in there. we just pass events through in both directions. In Phoenix, we can use the handle event and the push event functions to um to deal with this. And depending on the framework on or the um yeah the libraries you use for generating your uh your web assembly. Uh in our example, we used um bevy ECS. There you have a nice event writer and reader. Um so you can treat those events in a similar way. Okay, now let's get to the even more interesting part. Um, I have prepared a live demo. Um, we will replace the add function now with a a fully functioning L interpreter. Um, so we have a bit uh to to play around and Everything else is uh pretty similar. So what you can see here is the our text input field where we write the the L source code and when we press execute we will do two things. We will send this as an event to our back end. It will be executed by the rustler um implementation of our um lure VM and it will return the um resulting string back to our front end as um as a heek template string and it will print here as rasla output. At the same time we will also call our web assembly code and do the same thing run the same interpreter um and execute uh in the browser. So now when I implement my main function hello code beam and I press execute you can see this comes immediately from from our browser implementation and you can also see the um the response from the back end. [applause] Wait, wait. Becomes more interesting now. I um I kill my Phoenix. You can see the terrifying uh red box in the corner. So, um our server is dead. The connection is not there anymore. And now um when I do something and press execute, it will still execute the code in the browser. Um but you can see the uh the Rustler output does not refresh anymore. So you can still run things in the front end without the connection. There's no latency. There's no overhead. Um yeah, so you can actually implement things that that are heavy in the browser um and do not always have to rely on on the round trip to the server. Now you can clap. [laughter] [applause] So to conclude what we have learned so far, let me switch back to my slides. >> [snorts] >> before you go and rewrite everything in Rust. Um, this is useful when you have existing Rust code because you can just drop it into your beam or you can just drop it into your browser. Um, you can also use it when Rustler is um a way to to speed up what you have to process. for example, when the beam is too slow because you have to do some heavy number crunching. Um, you can use it when the performance matters and you want to be really responsive in the browser and you don't want to implement your stuff in JavaScript. For example, when you implement a game, this would be a nice way to to just deliver the the game client as a web assembly packet to uh to your browser and you still can run the the game logic in the back end to verify that everything that your clients are doing is is valid. Um you could also use it to load share. So if you want to mine bitcoins on your homepage visitors uh browsers, you can yeah you can just uh send them a heavy uh package and they they can they can process things there. Or you can use it for for security. For example, if you um want to encrypt stuff in the browser um and then send encrypted data to your back end, you don't have to um to deal with uh the raw data anymore. you don't have to worry about um yeah about encryption there. So you can basically implement end to end encryption with the browser. This is where where this approach works really well. Um but there are also drawbacks. So let's look into the ergonomics. um not that type of ergonomics um but speaking about how easy it is to use the language um there's a quote by Jonathan Blow he said rust makes the assumption that all code is production code and this resonates very well with me because it's you you can feel it um there's no way around um the borrow checker it will always get So um it will make sure that your program is memory safe when it passes but until then you have to make sure that um yeah that you write valid code. It's just a checker. It doesn't um it doesn't do the memory management for you. So you always have the in in the back of your head you have the the memory management and you will have to think about it especially when you're used to writing GC languages like Elixia. And then there's concurrency. I found this amazing um post by Haley on Blue Sky [snorts] where there was a post from from some Rust community about fearless concurrency. Um but we all know concurrency um should be done on the beam. um and it can be quite challenging to do in Rust. Um yeah so I fully agree with this sentiment and then there are also um a lot of reports in the internet um where people started doing things in rust but actually they were not happy with it and maybe few years later they they decided this is not the right language for me. One um very prominent example is Richard Feldman, the creator of the rock language. He started everything with Rust and at some point he decided to switch things over to sik because it just suits what he's doing better because some sometimes it's it's not the the best language to to use everything. And yeah, I I linked a few other articles here that are pretty interesting. And um for me, this is proof that if you fail during Rust, it's it doesn't have to be a skill issue. You don't have to be worried that um you're you're just not good enough. Uh you you're just a bad developer. It's just it doesn't fit everywhere and you should be aware of it when you uh when you pick it. So what are alternatives we have? Um, one [snorts] popcorn. I think we will have a talk about this in the afternoon. Um, it's a nice uh implementation of the beam, the atom VM, like a reimplementation of the beam. Um, but it's compiled to web assembly and it runs in your browser. So, you can actually execute the Elixia code in the browser. So it does not give you all the the speed up benefits, but it's a an another interesting way of uh of shipping and running code in the browser. Everything that I showed you, you can do with Sik 2. So there's also um a back end called Sigler, which is basically doing the same as Rustler, and you can also compile SIG to web assembly, so you can run it in the front end. And then yes, Westmax that's a integration of um of a web assembly runtime that is embedded in Elixia. So it also uses Rustler. Um but you can actually execute your web assembly code in the back end. So basically every language that compiles to web assembly you can call from your elixia back end by using westmax. [snorts] This is a um interesting approach. You will lose a bit of performance there um but you will also gain some um portability and um it's definitely worth a look um if if you're interested in in those things. Yeah. And then before I let you leave, whatever road you take, um, I have this slightly altered quote. The reasonable developer adapts himself to the world. The unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable developer. Um you can scan this QR code to get to the example project that I showed. So you can uh also run it. There will be also a link to to the slides. Um should be public since today. And that's it. I would be happy if you can provide some feedback for this talk and thank you for your attention. [applause] That was a super cool demo. Thanks. Questions. So when you show that example that you are compiling to web assembly but uh also compiling it directly and running it with rustler aren't you worried about the floating point operations if you do that that they will not be the same result for for example that's why Rust doesn't let you do constant expressions with like I don't know square roots or trigonometry. >> Mhm. Um yeah I mean you're you're targeting a different architecture so it could be but I think uh since you are using the same uh it e standard the the operations itself should return the same result but don't quote me on that. Yeah, I'm not sure either. That's why I was asking. >> Yeah. Yeah. Um I I actually I have a question for you. Someone wrote me on blue sky um asking if I can uh mention this and I really liked it. I don't have a name for this stack yet. And he he said in in his team they are also doing this and he suggested the name Runix. So Rust plus Phoenix equals Runix. What do you think? >> I think that's >> it's a tricky one. Not the workshop. That hallway hallway track. >> Yeah. >> More questions. Thank you for your talk. Uh when you explain how to put in assets file, there was one JavaScript file but didn't explain what is in this file. >> Um very good question. Um it's the the file which gets generated by um by our um let me show the slide again. Um, that's the wrong one. There we go. Um, the the western bind. So, this generates the glue code. So you can call the function uh from from your JavaScript and it will translate this call um into something that is understood in web assembly. So it will transform all of the the stuff, copy the um the variables you pass in uh into a format that can be used in web assembly and all of that is autogenerated. It's not very readable. So it it it works with like arrays of integers and and does uh very uh interesting things. Um but you don't have to worry about it. >> You have 64 and 32. >> Yeah, the worm 32 is basically the standard that that is used everywhere in the browser right now. Um uh but that's the size of the um like the the operations and you can still have bigger uh bigger numbers. >> Yeah, it has more to do with the memory uh that you can address. Uh there is WOM 64 but it's not something you'd see in browsers right now. >> Any more questions? Have you seen any attempt to bring more wy type features like the Wom component model >> um specifically for for Rust or >> for Rustler or any other sorts of integrations? >> None that I can think of. No >> context being that you see these are integers passing back and forth. You can you can do more data types >> but you have to define an AI because WOM internally is just integers. So you map it to something that's what bind genen does and that's also what uh the wom component model does and wy to some extent [music]

✨ This talk was recorded at Code BEAM Europe in November 2025. If you're curious about our upcoming event, check https://codebebeameurope.com ✨ --- The BEAM is the perfect tool for building distributed systems that are resilient, maintainable and fun to implement. However, there are certain areas where the BEAM lacks, like computation heavy and graphically intensive applications. In this talk I will demonstrate why Rust is a great match to fill those gaps. You will learn how to build a Phoenix LiveView application that is extended with Rust, in the browser using WebAssembly, and in the backend using NIFs. Whether you're planning to build a browser game with 3d graphics, a weather simulation or just want to calculate the last digit of Pi, there is no excuse not to run the BEAM anymore. --- Let's keep in touch! Follow us on: 💥 Bluesky: / codebeam.bsky.social 💥 Twitter: / codebeamio 💥 LinkedIn: / code-sync