Rust & WebAssembly

Welcome to Cloudflare TV How's it going? It's been a long day, eh? Yeah? Wow, that was not a lot of energy at all. I mean, I feel you. I feel you. I've also been here all day, and I got here pretty early. All right, so this is the last of those, like, breakaway sessions. So, like, it's the final countdown. Let's get through this. And I'm really excited because we've heard a lot about Cloudflare today, right? This talk is, like, a little bit about Cloudflare, but it's mostly just about two technologies that I'm super excited about. And so if you've kind of heard enough about the POPs and the global network and that kind of thing, you can shake your head kind of out of that space, because I am here to talk to you about Rust and WebAssembly. So I had no idea what the audience was going to be at this event, and so just by a show of hands, raise your hand if you have heard of Rust. Keep them up if you have written something. Keep them up if you have it in production. All right, well, Berlin is the epicenter of global Rust. It's awesome, so shout out to Berlin. Cool, and then WebAssembly, heard of it? Written something? Have it in production. All right, so basically these technologies kind of have the same hype curve, which is to say we all have heard of it, maybe we've basically done a hello world, but not many people have it running in production. And so as I said, the only tiny little bit of Cloudflare stuff I'm going to talk to you about today, which I'm going to demo at the very end, is that I think that your first Rust and WebAssembly in production should be on a Cloudflare worker. But before I can convince you of that, I kind of have to answer the question, what the heck are these technologies? So to start, first off, my name is Ashley Williams. You might know me from Twitter as AGdubs, and I am an engineer at Cloudflare. And recently, you may have heard that we made a bunch of announcements at JSConf EU. I announced the Cloudflare Pizza Kitchen. It's a really popular product. No, I'm just kidding. When you give presentations to JavaScript people, you've got to put, like, emoji and jokes in it. So I made the edge all about pizza. And so if you've been wondering how to explain the edge to maybe your 5-year-old son, you can check out that presentation. It's got pizza. Very exciting. But one of the things we announced was the fact that we have zoneless workers, which means that you don't need to have a domain registered. They're free. We also announced a whole bunch of developer experience improvements, including a CLI. That's what I worked on. I joined Cloudflare. I was like, I don't like cutting and pasting curl commands, and I don't know anyone else who does. So let's make a CLI. And that's how that was born. But, yeah, so my background is pretty varied. Before joining Cloudflare, I spent a year working for Mozilla. I'm on the Rust core team. And I spent that year working on building out the Rust WebAssembly tool chain. And then before that, I worked at a small company called NPM, who here is a JavaScript developer. And I'm usually talking to all JavaScript developers. JavaScript's cool. I worked at the JavaScript around the world company. And I was on the board of directors of Node.js. As I said, I'm on the Rust core team. And then I also am on the core of the Rust WASM working group. And so a lot of the stuff I'm going to show you today, a lot of the WebAssembly story that Cloudflare has, is powered by tool chains that I have worked on, which is super fun. So, yeah, the arc of this talk is going to be kind of simple. We're going to talk about what is Rust, what is WebAssembly, and why you should care. And then hopefully at the end, assuming they don't kick me out, I'm going to do a demo. Where I'm going to very quickly write some Rust, generate it to WebAssembly, throw it on all those pops you've been hearing so much about. Yeah, so first, what is Rust? So Rust is a programming language, but it's also a culture. And so how many people have ever seen this little icon before? All right, if you haven't, it's worth knowing that I only work on programming languages that have cute logos. And this is one of them. This is Ferris, the unofficial mascot of Rust. And Ferris is our unofficial mascot because people who write Rust are called Rustations. And the pun is bad. Ferris also means over pertaining to iron. We can keep going with that. But anyways, got to love puns, right? So Rust often defines itself as a programming language designed to empower everyone to build reliable and efficient software. And that might sound a little milquetoast, like a little banal, like, oh, cool, like reliable, efficient. Most programming languages want that. But the thing I want everyone to focus on is this idea of empowerment. Rust is kind of written as a C++ replacement. It is a system, low-level language. It gives you a lot of control. But the idea is that it's going to give you all of that control, maybe without, you know, the really epic ability to shoot yourself in the foot that many people may be aware of. How many people here heard of Heartbleed or Cloudbleed? Yeah, if that had been written in Rust, it wouldn't have compiled. In Rust, we like to say the safest program is one that doesn't compile at all. Which is to say our compiler has some very strict guidelines and does a fair amount of static analysis on your program so that it can check for many of the classic memory safety bugs that you may otherwise run into with a different compiler. So I'm going to talk kind of about two different types of memory safety. And this is from a blog post by someone named Will Cretton. And I thought he did a really great job of separating it out. So the first type is memory safety. And that is the property of a program where memory pointers used always to point to valid memory. All right, this is the idea of a correctness issue. So a memory unsafe program can crash, produce non-deterministic output, depending on the kind of memory safe bug. And so Rust's compiler is going to be able to look and find memory safety bugs surrounding that correctness. And then additionally, we're also able to look for things like memory containment. Fundamentally, this is the do you leak memory. And so I only saw so many JavaScript people. How many people have a Node process running right now? Are you on pager duty? Sorry. We ran a lot of Node processes when I worked at NPM. And memory can be a really big issue. And so this is something that the Rust compiler is specifically going to check for. And make sure that you don't run into these types of problems. Now, you might say, wow, like, you must have some sort of tradeoff. You can't just magically give me all of this. I've heard that people have to fight the Rust compiler, right? They have to fight the borrow checker. Borrow checker is often what the memory safety portion of the Rust compiler is called. And that's true. But remember that goal of empowerment. We care about ergonomics. And so this is what a classic error message might look like. We spend a lot of time caring a lot about error messages. Here you can see it's asking for a lifetime parameter. If you've ever written any Rust, you've probably run into an error like this. This is just another example. But, again, it's the idea that we want to give you great power. But we also want to make it not super painful. That being said, learning these types of things is difficult. There's certainly a learning curve for Rust. But we'll talk a little bit about why I think that learning curve is worth it. So on the Rust Lang website, we talk about our three main values. Performance, reliability, and productivity. Let's walk through a couple of those. So first on performance, sometimes I'll say that Rust has no run time. But Kenton Varda, the architect of the worker's run time, wanted to tell me that, like, you know, if you're allocating any memory whatsoever, that is actually a very slight run time. And so now I say we have an extremely small run time. And then additionally, we don't have a garbage collector. This does not necessarily mean that you have to manually manage memory. The way I like to describe it in Rust is that you make a blood pact with the Rust compiler where you promise that you will write your code in a specific way. And then the compiler will do that memory management for you. There's been talk that that could be considered a static garbage collector, which is both a cool idea and a super good way to get a bunch of dudes on the Internet really mad at you. So go ahead. If you love hacker news, like, shout that one out and see how that works for you. So a case study of using Rust is Mozilla, where the Rust project was originally born. They recently parallelized their CSS engine and replaced around 160 lines of C with 85,000 lines of Rust. And fundamentally, that was allowing them to do a 30% speedup of Amazon's landing page. So one of the questions you can often get is, like, oh, you know, like, should I write it in Rust or should I write it in C? And people will often assume that C is faster. And there's different benchmarks. Benchmark game is not a game that I like to play. But Rust was able to help parallelize the CSS engine in a way that C was completely unable to. Because of the guarantees that Rust allowed, they were able to parallelize the engine with confidence in a way that they had tried multiple times in C and C++, and it had failed. But because of that kind of concurrency that came from the thread and memory safety guarantees, they were able to parallelize it. So it didn't really matter if Rust or C was faster, because in Rust, you could do it in parallel. So you were going to beat C no matter what. Additionally, this is a state map benchmark between C compiled with GCC and Clang. Those are these two up here. And then the Rust-based state map using slightly different hash maps. Fundamentally, what you can see here is this is a blog post written by someone named Brian Cantrell, who is originally of Sun, Oracle, and now is the CTO of Joyent. But he was benchmarking his C and Rust. This is a super fun deep dive. But again, we're seeing that Rust is performing better than C. But I think the conclusions he draws in this quote really bring the message home. When she says, all of this adds up to the existential win of Rust. Powerful abstractions without sacrificing performance. Does this mean that Rust will always outperform C? No, of course not. But what it does mean is that you shouldn't be surprised when it does, and that if you care about performance and you're implementing new software, it's probably past time to give Rust a very serious look. So again, if you like to go fast, and I assume that you do if you're here at Cloudflare Connect, Rust is a great tool to put in your pocket. So in addition to being fast, though, we care a lot about reliability. I mentioned before about static typing, but we also have memory safety and thread safety. I could dive super deep into this. There's probably, like, eight talks hidden in here. But I like to stick with this quote, which is from Dyad Hossfeld, who is a research engineer working on the Servo engine at Mozilla, which is another engine. You can see it vaguely as a replacement for Gecko, but it's currently going to be the engine that's powering their augmented and virtual reality efforts. And when she was working on this project, she does a fair amount of security research, and she did a fascinating audit of the old C codebase and the new Rust codebase. And what she was able to point out was that nearly 75% of the security-related bugs in the original C codebase would have been prevented by default were it written in Rust. And that is a pretty serious number. Lastly, of course, we talk about having all of this speed, having all of this reliability, and generally what this means is that you are going to have some developer experience pains. However, as I said, Rust really wants to empower you, and so we've put a lot of effort into making you productive. So we have a first -class package manager. Again, if you're not familiar with NPM, maybe this isn't something you'd like, but we have one called Cargo. We have a package registry called crates.io, and I'll be showing you a couple of those in a few minutes. But we also have linters and formatters out of the box, IDE support, a lot of stuff that you would not necessarily expect from a systems-level language. We additionally have a really nice community, which is sometimes not a sell for some people, but it's a pretty big sell for me. Again, we literally have a little cute crab as our logo. And so when I was working at NPM, CJ Silverio was the CTO there, and I got us to rewrite a fair number of our services in Rust. Remember those stories I was saying about being on pager duty? And CJ said one of my favorite things ever, which was that my biggest compliment to Rust is that it is boring. Again, you spend a lot of time fighting a compiler to get it to compile, but once it compiles, you're pretty good. Now, Rust cannot prevent logic errors. I wish it could. But it's certainly going to get you out of a lot of the problems that you would otherwise run into in, say, like a dynamic language where potentially you're leaking memory or something like that. You can kind of put these services into production, and they stay there, and they are super happy. So before I hop into WebAssembly, these are just some of the small companies that are using Rust in production today. I remember when I originally gave this presentation many years ago, and we did not have all these big names, but it's pretty exciting. And, of course, it goes to say that Cloudflare is now a huge user of Rust as well. All right, so let's hop into WebAssembly. So WebAssembly is the new hotness invented at Mozilla around 2017. Not really exclusively of Mozilla, but kind of a group of representatives of all of the browsers wrote a white paper on this. And one of the things that people love to talk about with WebAssembly is that it is neither really based on the web or an assembly language at all, because naming things is hard. So WebAssembly is actually a compact binary format, and what you can largely understand is that it is a compilation target. You don't want to be writing WebAssembly from scratch. But you can if you want to, much like many other assemblies. But there's a couple of... Ooh, fascinating. There's a couple of human-readable formats. So if you did want to debug it from the source, you absolutely can. But largely speaking, you should be thinking about WebAssembly as something that you're going to take a language that you usually write in, and it is going to compile to it. It is based on an open web standard, and it's currently governed by the W3C. And this is actually super important, because raise your hand if you remember Adobe Flash. Yeah. It's kind of this, except none of most of it, including the proprietary you-must-update -your-Adobe-Flash-now warnings. Yeah, so this is an open web standard and supported by all modern browsers greater than IE11, and we are working incredibly hard on polyfills so that you can really confidently use WebAssembly everywhere. All right, so oftentimes when we talk about WebAssembly, we talk about its values, and so we can say it is small, it is fast, and it is predictable. And my favorite graph to show is this one. So Mozilla rewrote their source maps implementation for the Firefox browser in Rust-generated WebAssembly. Let's break down this graph a little, because I know it is super small in the back. So we have some red and some blue. The red is JavaScript. The blue is WebAssembly. They come in pairs. The first two are Chrome. The second two are Firefox. The last two are Safari. Now, the very first thing that you might notice about the graph is that the red is taking a heck of a whole lot longer than the blue. Cool. But I don't think that's the most interesting thing about this graph. Does anyone have any guess as to what I think is the most interesting thing about this graph? That standard deviation. Look at that. Oh, my gosh, this is so much more predictable. Again, I'm guessing many people are not on pager duty right now, but I feel a lot more confident about a service where the standard deviation of how long it's going to take to run is this, as opposed to, man, Firefox, that's a mess. It's way too big. But, yeah, so we talked about WebAssembly being small. Again, that compact binary specification. Fast. I mean, running less code with less complicated instruction is going to be faster. But it's this predictability that I think is incredibly exciting. And part of the reason that I think WebAssembly is going to help open up the web as a platform for significantly more applications than we've ever seen previously distributed on the web. So when we talk about WebAssembly, why should we care? Right? So a lot of people talk about it like this is a great way to deliver large existing web applications or applications now over the web. And they also will often say, do you hate JavaScript? Develop in your language of choice. Right? I don't like that one. I don't think that's good. And part of the reason I'm going to tell you right now is because WebAssembly is small, fast, and predictable because it doesn't know that much. It's pretty small. How many people here like having a string abstraction in their programming language? No one? Do you use strings when you program? All right. So I like to call web development fancy string concatenation because fundamentally that is what it is. But WebAssembly doesn't understand that. WebAssembly mostly understands numbers. And so if you want to talk to WebAssembly as if it is a full-fledged programming language, you're going to need some JavaScript shims. So WebAssembly is here to do a lot of heavy lifting for you, but it is not a JavaScript killer. And so one of the ways I like to free phrase that idea of developing for the web in your own language is that we're now able to open up package ecosystems from other languages to the web. So maybe there's a super cool Unity library written in C. Like, that would be super cool to use on the web. Does that mean that in the next ten years I expect that people will be writing full C applications and deploying them to the web? I mean, they will, but I don't think that's the killer use case. I think that we're going to see a lot more incremental heavy lifting hot pads from JavaScript moved into WebAssembly for this more kind of final one, which is improving the performance of your JavaScript code. So if you wanted to come here to herald the death of JavaScript, you have come to the wrong party, and I don't think that party is ever really going to happen. All right. So just to talk a little bit about what are people actually using this for today. So WebAssembly 2017, that is pretty new, but the hype is real. So one of the first demos when Google wanted to show a proof of concept for WebAssembly was with Autodesk. They put AutoCAD in the browser. I'm not sure if you are all familiar with AutoCAD, but that is an extremely heavy -duty application. I remember when I was a kid, my dad is an architect. I think we were on some sort of sun flame machine running AutoCAD in, like, 1992. So it has changed a lot that we can now put that in the browser. Additionally, we're seeing a lot of stuff from Unity and a lot of other game companies that are doing fantastic stuff with WebAssembly. And then just recently, this is a name that we should probably know, eBay is also doing a fair amount of WebAssembly now. So WebAssembly is a super cool thing that is coming, and, again, I want to empower you to use it now. So as I said before, I cannot reiterate this enough. We are not here to kill JavaScript. We are here to augment JavaScript. Super important, because in order to really develop with WebAssembly today, you're going to have to realize that you are going to still have to write some JavaScript in order to get it to work. So before I get into my demo, one of the final questions I always get is, what about support for my favorite language? So today, the tool chains for WebAssembly are very immature. And I say that having spent, like, the last two years working on it. I still don't think it's terribly great. The best support currently exists for Rust, C, and C++. C and C++ largely use something called Emscripten as their tool chain, and Rust uses something called the Rust WebAssembly tool chain. But I get questions about these all the time. And so one of the things, can anyone notice anything kind of, like, maybe not specific? There's a big difference, maybe vaguely, between these languages and these ones. Does anyone note what that might be? A garbage collector, yeah. Or maybe, you know, any sort of runtime. So if it's a runtime garbage collector, that's totally it. And so one of the things to note is that WebAssembly does not have a garbage collector at the moment. There are questions about it getting one. And it doesn't have that runtime support. And so whenever you want to take one of these languages and compile it to WebAssembly. And remember, with the power of compilers, you can compile literally anything to anything else. They're going to be significantly larger because they're going to have to include those dynamic runtimes with them. And that is pretty big. However, at Cloudflare, we know that this is very, very exciting, and people would really like to use these to leverage our workers' platform. Our workers' platform gets WebAssembly out of the box because we're using V8. So that's cool. So I have some fun plans for how we're going to get around this runtime situation. So if you'd like to talk more about that, come find me afterwards. But know that we have our eyes on expanding that WebAssembly thing, the WebAssembly support on workers. And we hope to kind of, like, lead the industry in making that, like, a more successful thing for more languages. So the future is bright. It's just not quite here yet. But we get to write it, which is really, really exciting. And so one of the questions you might be asking is, why the heck is this presentation even happening at this conference? Which I was, like, also asking the same question. But fundamentally, it's like, why would Cloudflare care about these programming languages? And I think it's because fundamentally we want to be the next cloud compute platform, which means we want to be the place you deploy your software. And so that means we need to support how you want to write your software. And so by choosing a web platform, and again, with the WebAssembly target, we're going to be able to accommodate more people in a fast and efficient way than we would otherwise be if we were trying to run VMs of every single possible language's runtime that's out there. So these values are also the same as Cloudflare's. And so I think it is no surprise that Rust and WebAssembly are some of the things that we are targeting first, because they kind of share that same ideology of making the web faster, more reliable. So without further ado, let's write some code. I don't even know how much time I have left, but let's see. All right. So in addition to releasing our CLI tool, I also helped build out this documentation. And this is a template gallery, which means if you do not like—who likes writing boilerplate? I can tell you're sleeping. Everyone in this room likes writing boilerplate? Yeah, no, boilerplate is terrible. Let's not write it. So I'm going to just grab this Hello World Rust template right here, click to copy. Pop up and open my terminal. All right. So I'm going to be using a tool called Wrangler. You may have heard about it in the developer's lounge. I called it Wrangler because for Cloudflare, I moved to Texas, and so it felt only necessary to name it some sort of Texas-y situation. So you can use the Wrangler template as a template. It's just going to take a little bit of substitution. So I'm just going to pull down this Rust WebAssembly template, and we can take a look at it. Pulling it down right here. Cool. And so we'll go into my app. There we go. If it's up top, we can see. So just a bunch of boilerplate here. If you're not familiar with Rust, cargo.toml is JSON. It's like a manifest file. And wrangler.toml is the file for your Cloudflare. So what we can do here is just run Wrangler preview and see what this gives us. And if you come from a language that doesn't have a compilation, you have all of the fun things you can do while it is compiling. It's super great. Super good opportunity to go get some water, walk around. But, yeah, a lot of people. Also, is my mic not working? This is a really finicky mic. All right. Awesome. So that's just going to pop open a worker for me right here. Just generated. So this is calling a very simple greet function that I have written in Rust WebAssembly. So let's pop this open. Everyone hear me? The greet function just takes a string. Give me a hand. That's going to take a minute. Okay. What would you like? All right. Are we back? Cool. I'm just going to do this. It's fine. All right. Cool. Oh, I have to type. Shit. I cursed. All right. So what we can do now is I think this would be a much cooler demo if we were doing something other than, like, printing a string. Let's, like, use something from Rust. So how many people here have an application that parses something? Maybe a config file? Markdown? At least how many people use a service that parses something or parses markdown? All right. Some people. I spend so much time parsing markdown. Maybe it's just me. So what I'm going to do is I would like to create a worker that is going to do some parsing for me. Parsing is often, like, a performance, like, bottleneck. So this could be a good opportunity to do that. So I'm going to add the dependency to my cargo toml. All right. Okay. And then what I'm going to do is just I'm going to take this example from this crates repo, and I'm just going to dump it in my worker. So what I just did there was I added the dependency to my Rust project, and now I'm just going to pop open lib.rs. And we are going to take this example right here. We'll just take all of the code in the example. Some really classic cut and paste programming right here. And we can get rid of these. We don't need those. All right. Just paste that in here. And we don't need this line or this line. We're not going to test if we get the right output. We are just going to return our HTML output. In Rust, you don't have to use the keyword return. If it is the last logical thing in your function body, you can just omit a semicolon, and it does it. People either hate this or love this. All right. And then finally I'm just going to pull a couple things from this library into namespace so that we can actually use them. All right. And we'll see if this compiles. I'll run Wrangler build. It's going to pull down my dependency. Cool. Just a little warning. That's fine. And then the last thing I'm going to do is we called this a greet function, but that doesn't make a ton of sense. Let's call it parse. Cool. And then I am going to open up my worker JS, which is just in here. And here what we're doing is we're loading the WebAssembly. You might notice this word WASM bind gen here. That is a Rust tool that is not only helping to compile your Rust code to WebAssembly, but it is also generating JavaScript bindings so that you can talk to your WebAssembly as if it were JavaScript by using the function signatures of your Rust. It's compilers. Super fun. All right. So we're going to grab that parse function, and then we will do this here. And we can call it a greeting. Sure. But we're going to want to update the headers on our worker. So I'm going to take this response and store it in a variable, and then I'm going to set the headers so that we get our content type to be text HTML so that it will actually render. And we'll return that res. And let's pray that I copied everything to work. Let's see. Wrangler preview. See if it's working. Boom. So we've taken some of the string that we passed, and we've parsed the markdown into HTML. But this is not really all that exciting. I hardcoded some markdown. That's kind of cheating. Right? But let's try it in a different way. So because watching me code an HTML form is probably the most boring thing possible for both you and me, I'm not going to make you watch that. I already wrote one. So let's open up this index.html. And so earlier today, if any of you follow me on Twitter, you'll notice I was like, send me your biggest markdown file ever, because I want to show you how performant this is by both doing it in WebAssembly and on the edge. We're taking two super edgy technologies, slamming them together, and getting, like, an explosion of awesome performance. And so I got a couple of interesting options. So one of the first ones I thought of was Moby Dick. So I was like, cool, let's try Moby Dick out. We'll parse that. Parse it. Boom. Done. That was incredibly quick. But kind of boring. So then I found a stack overflow question where someone was like, this markdown parser is, like, choking because of my super freaking huge markdown file. And I was like, perfect. This is what I'm looking for. So for what it's worth, I believe it is in Spanish, and I have no idea what the content is all about. But one of my favorite things about this content is that it takes almost longer to actually paste it into the form than it does to actually parse it, which is brilliant. So let's do this. We'll parse this in here. You'll see it's, like, taking its time. I don't know if anyone saw that blink. This is a big one. Oh, I don't know. I'll send you the file. But one of my favorite things about this is that it is now completely rendered, but it's still loading because it's loading avatars from GitHub. So we actually parsed the entire file and the markdown significantly faster than I don't know if anyone here uses GitHub as much as I do, but they cache things incredibly aggressively, so the fact that we're beating them is still pretty awesome. And then finally, someone sent me what I believe is the user guide to Final Fantasy 7. I don't know where they got this, and apparently it's in multi -markdown, so the parsing still... I mean, it'll parse it, but it doesn't matter if it parses it correctly. The time still takes the same amount, so we can stick that in there and say parse it a little longer, but again, still incredibly quickly. So again, by combining the power of WebAssembly and the power of our Edge, we can do this task, which at least I know a fair number of web applications have to do, a ton of the time. So yeah, all of these demos exist. I can send out the links to folks who want, but let's finish this out. So the last thing is why should you, Cloudflare Connect attendees, care about programming languages? In particular, these programming languages. So in order to write this part, I had to make a couple assumptions about you, and so now I'm going to find out if those were true. How many people here own a company? All right. How many people here manage people who write code? All right, a little bit more. How many people here write code? Okay. All right. So not entirely off. All right. So one of the things I find when people, like, think about programming languages is that they feel so natural to us, almost like human languages, that we don't realize that they're actually tools. Like, those things exist to help us solve a problem to get things done. And so it turns out that people can have really strong feelings about those tools, and those are often related to how well those tools help solve their problems and how good it feels to use those tools. So how many people have seen the Stack Overflow survey for 2019? All right. So they've been doing this survey for a really long time, and I am very pleased to say that Rust has always been the number one most loved programming language, which is totally ridiculous in my opinion because there's so few people who I feel like who are actually using it, though that number is changing. But this year, something that I thought was super fascinating, what is WebAssembly doing right here? What? Fifth most loved programming language? I found that very surprising. But fundamentally I think it is because a lot of people, particularly developers, see the promise of these technologies and see them both as technologies that are, you know, cool and edgy and doing something super fun, but also things that are empowering people to solve problems in a faster, safer way. So additionally, we look at the most popular technologies, and you'll note first that WebAssembly and Rust are nowhere to be seen, but what we see up here is JavaScript at the top. So when workers was first architected, we made this decision to we're not going to do containers, we're not going to do VMs, we're going to make a bet on V8 and to leverage web technologies. And I think fundamentally that's going to be a really big part of our success because lots and lots and lots of people write JavaScript, and lots of people write JavaScript for the browser, which means that our decision for this type of, like, ops product is incredibly accessible to people who are already doing this basically in their day-to-day life. They're front-end JavaScript engineers, and there's a lot of them. And so when you're thinking about hiring and you're thinking about your ops team versus your development team, like, you know, 10 years ago, Ryan Dahl announced Node.js, and Node .js kind of had this promise of unifying the server and the client so that anybody who wrote JavaScript could do either of those. Now, you could have differing feelings about how that history played out, but I think with what we're doing with our architecture on workers that we are getting closer to unifying those types of ideas. So fundamentally, you can actually be doing all aspects of your software's lifecycle in a very specific stack that is very approachable to many, many people. And so when I think about this, I say you want to give your team the tools they want to use. I don't usually hear most people go, I want a container. Like, most people don't want a container. But here, I mean, people really, really love Rust, people love WebAssembly, and lots and lots of people write JavaScript. And so this is a platform that's literally designed based on what people want to use and what people already do, which I think is incredibly compelling. So if you're interested in using that tool that I showed you, you can install it using NPM here. You can also install it using Cargo, but you'll note that it will have to compile on your machine. So the NPM version is just a really nice precompiled binary delivery service. So you can use that, and it'll be a lot faster. But additionally, what I wanted to shout out was I saw a lot of people had played with Rust, but maybe had not really, you know, tried out too much of it. Wrangler is a CLI tool. I'm the primary author. It is written in Rust, and it has been open source since, like, the third week I was working at Cloudflare. If you are a customer, and if you are using workers, and if you want a feature, or you want to talk about how you use workers and how it can fit into your software development lifecycle, come show up on our issue tracker and tell me what you want to get done, and we can work together to get it built. And with that, thank you very much. There's a QR code. I don't know what it does. But you can find me on the Internet, and thank you very much. And I'm definitely over time, but I don't know. Questions? Afternoon break. Or, I mean, I'll stand up here and answer questions if people want. Until the Sun guys kick me off. They're in charge. Yeah? Yeah, absolutely. So there's no additional size. If you, like, I guess I should clarify. The question was, is there additional size if you're using WebAssembly? You don't get more size, but it's worth noting that if you write it in WebAssembly, you can probably jam a lot more business logic into something like a WebAssembly format than you could actually write in JavaScript. So the size of the WebAssembly is largely why some of the more dynamic languages compiling to WebAssembly currently don't work with our limits. But I have the intention of so our entire architecture is based on the fact that the vast majority of workers can share a ton of things. You can share the operating system. You can share everything up to the process, right? And so instead of having every WebAssembly worker that everyone pushes up have to have its own compiled version of a runtime or even its own compiled version of the Rust standard library, it's my goal in the next year or so to kind of create a dynamic linker for WebAssembly that will be able to make it so that you can share those things and so that the WebAssembly will be much smaller and fit. But lots of fun plans. Yes? Whenever I play WebAssembly or look spin, my concern is that JavaScript ends up not being that much logic. It ends up being other things. It becomes fetch or it's copyright. It interacts with the DOM or whatever else. If I want to make new fetch or interact with the DOM or whatever else it is or the date type or anything like that, do I then have to go back to JavaScript or do I get to the Chrome run? The proposal you'll want to keep an eye on is the Web IDL bindings proposal, which is on its way. However, there's two crates. One is called JSYS and the other is called WebSYS that are part of the Rust WebAssembly tool chain, and they build those abstractions out for you so that you can write them all entirely in Rust. A follow-up question. Do you see in the future most people ending up writing WebAssembly via another language, or do you see tools like React being built with WebAssembly to speed up the bottlenecks and then most end users still writing JavaScript, or how do you see it working? I think it's going to depend on what type of application you're building. We're already seeing a huge explosion in the diversity of applications that people are putting on the web. We've been kind of seeing it since JIT compilers kind of came about in the browsers and we were like, oh, my God, look at all the cool things we can do in here. I think that there will always be a universe where people are just going to write JavaScript, and I think that's a really great universe. I definitely think major frameworks are going to speed up hot paths using WebAssembly. I say this because I know they are doing it. So that's absolutely going to happen. One of the things I often tell people is for at least a large segment of the audience, WebAssembly will be successful when everyone is using it and no one knows. That being said, as large application developers who care about performance, like, you want to be a part of that, and there are certainly parts of your application and your business logic that you probably could be writing in WebAssembly today. Though framework authors will probably do a lot of the heavy lifting. Yes? For someone getting started with Cloudfire Workers, would you recommend doing JavaScript or Rust? I think it depends on where you come from and what is exciting to you. When I talk about ergonomics, it's usually 80% familiarity, 10% ambition, 10% laziness. So it really first depends on what you're familiar with. Like, if you're a C++ developer, if I was like, get started with Workers by writing JavaScript, that might not be compelling to you. But for some people that's like, oh, that's my native language, that would be great. I would say start with the thing you want to build and then look for, you know, what excites you. And then doing it in Rust versus doing it in JavaScript, I think you could probably go either way. The first Worker I wrote was in Rust, which was interesting and surprising since there had not been really a template before. That being said, like, when you're writing the Worker, like, it's going to pop up. Like, you can see right here, this is the JavaScript that my Rust wrote for me. Oh, oh, look at this. Look at all this JavaScript. No, yeah, there we go. All of this JavaScript right here, which is, like, definitely not written for a human to read, this was written by my Rust. So if you're worried about, you know, leaving JavaScript behind, like, there will be JavaScript for you to find later. So, yeah, mostly just find what is exciting to you. You already asked one, so I'll go to him and then you. Yes? My biggest pet peeves was Rust. Whew. Oh, I mean, it goes without saying I'm incredibly biased. I really love Rust. So I am a big person who learns by example. The person who wrote the Rust book, by the way, is sitting in the audience at the back. And when I was learning Rust, he found it very frustrating that I would be like, I don't understand this. What's going on? He was like, well, there's a chapter in book, like, six, paragraph eight. And I was like, no, I want to look at examples. And so learning Rust when it was so young meant that there wasn't a ton of, like, great example code to, like, go just look out and find. But that's changing super rapidly, and so I really like that. I think probably the thing that I dislike the most, and it is subtle and potentially not very applicable to many people in this room, but maybe it's worthwhile to hear, is Rust is a very new language that has a ton of hype. And it's new, and its governance is based on consensus, which means we listen to everybody, for better or worse. And so there's kind of a land grab right now around who gets to decide the future of Rust. And it can be very painful to get everyone to play nicely together and to kind of, like, lose the ego and work towards a greater good. And so while I think it is super exciting that we have a very egalitarian process, it can be very hard to get involved nowadays based on the sheer number of people who both want to and are allowed to participate in the conversation. Do you still have your question? So, I mean, yeah, most things, like, the reason things succeed is often because of luck, right? So Rust came out of Mozilla, WebAssembly came out of Mozilla, that was very fortuitous. There's also just, like, several features of Rust that make it just super well suited for WebAssembly as a target. As I said, the incredibly minimal runtime, no garbage collection, a ton of developers who have a knack for static analysis and compilers also means that having those people around who want to build that tooling, like, they were all just right there. And so it was like, oh, WebAssembly has to happen, let's do this. I think the other reason that Rust, I think, is doing quite well these days in the WebAssembly tooling department is because we actually weren't first. It's a lot easier to go second. So the Emscripten tool chain was originally something known as Asm.js, which was a very interesting flavor of incredibly easy-to-optimize JavaScript code. And so it started there and then it slowly became what WebAssembly is. It was, like, the original proof of concept for WebAssembly for compiling C and C++ to this target. And I have a ton of respect for that project, but I just have very little patience for, like, make files. And I would just say that the experience is just, like, a little bit rougher. But it's also hard to do really the right thing when you're doing it first and you're even trying to figure out if it's possible. And so that's kind of the tool chain with C and C++, and they're, like, working on trying to polish that out now. But we had the benefit of going, hmm, what are they doing over there? What should we do and what should we not do? And then kind of picking and choosing and then getting to build our own. Other questions? All right. I'm just curious, like, selfishly, how many people are going to, like, actually try to write any Rust or WebAssembly? Not even if it's related to workers. Has anyone become convinced? All right. How many people have become unconvinced? All right. That's a great sign. Didn't super botch it. All right. Well, I don't know. I've got to assume there's probably some good snacks in there and, like, there's probably, like, no oxygen left in this room. So let's go have a little bit of a break. Thanks for listening to me. I'll be outside if you have any more questions. Thank you so much for listening. I'll be outside if you have any more questions. I'll be outside if you have any more questions. I'll be outside if you have any more questions. I'll be outside if you have any more questions. I'll be outside if you have any more questions. I'll be outside if you have any more questions. I'll be outside if you have any more questions. I'll be outside if you have any more questions. I'll be outside if you have any more questions. I'll be outside if you have any more questions. We have three C2C e-commerce marketplaces in the Southeast Asia region. The marketplace mainly consists of preloved items. And we have categories such as electronics, fashion, property verticals, autos. More than a quarter of the whole population of Singapore is on Carousel. Our end-user traffic is close to 10,000 to 15,000 queries per second. Carousel started working with Cloudflare to address their immediate DNS needs, but quickly expanded their usage in order to continue serving web content quickly as their user base grew. It started off as a solution for our DNS and SSL termination requirements. And then we sort of explored the product further and our usage grew after that. We started exploring the ability to cache our assets at Cloudflare, which we found quite good. In the past three years, we have moved all our caching requirements to Cloudflare. Carousel also adopted Cloudflare security features like the web application firewall after noticing vulnerabilities in their existing firewall. As someone who would run a public property on the Internet, there is a constant threat of adversaries targeting you for DDoS attacks for various purposes. The firewall which we had existed at that time was, there were a few lacunas and we wanted to have a solution which was much more comprehensive in nature. We explored the web application firewall offered by Cloudflare and it ticked all our boxes. It had the basic OWSP security related rules as well as various other specialized rules that Cloudflare themselves added. And we also had the ability to add custom rules. So all of these features essentially made it a perfect fit for our need. As a thriving e-commerce platform, Carousel understands that its Internet security and performance must work hand-in-hand. The company cannot allow its security posture to impact site speed and availability, especially when flash sales attract sudden influxes of valuable traffic. One of the biggest benefits that we get out of Cloudflare is that the security is nearly free of cost when it comes to performance. So user experience doesn't degrade with all these checks that are put in place before a particular request is served from our origin. So that is one of the benefits that we definitely see. In the past three and a half years of using Cloudflare, they have solved our problems around the various areas of handling traffic, in caching, in security. Reliability, Cloudflare is very key for the experience that we offer to our users. With customers like Carousel and over 25 million other Internet properties that trust Cloudflare with their security and performance, we're making the Internet secure, fast, and reliable for everyone. Cloudflare, helping build a better Internet. Hi, we're Cloudflare. We're building one of the world's largest global cloud networks to help make the Internet faster, more secure, and more reliable. Meet our customer, Findlaw. Findlaw is a Thomson Reuters company. They're a digital marketing agency for law firms. Their primary goal is to provide cost-effective marketing solutions for their customers. My name's Teresa Jurisch. I'm a lead security engineer at Thomson Reuters. Hello, my name is Jesse Haraldson. I'm a senior architect for Findlaw, a Thomson Reuters business. So, as the lead security engineer, I get to do anything and everything related to security, which is interesting. Findlaw's primary challenge was to be able to maintain the scale and volume needed to onboard thousands of customers and their individual websites. So, the major challenge that led us to using Cloudflare is Google was making some noises around emphasizing SSL sites. They were going to modify the Chrome browser to mark sites that weren't SSL as non-secure. We wanted to find a way to, at scale, move 8,500 sites to SSL reasonably quickly. And doing that to scale up to speed with our operations, it needed to be something that was seamless. It needed to be something that just happened. We had tried a few different things previously, and it was not going well. And we tried out Cloudflare, and it worked, just kind of out of the gate. Like us, Findlaw cares about making security and performance a priority, not only for their customers, but for their customers' customers. Faster web performance means having customers who actually continue to sites. It means having customers who maintain and go with the sites. 65% of our customers are seeing faster network performance due to Argo. So, that's an extremely important thing. The performance, the accuracy, the speed of that site fronted by Cloudflare is super essential in getting that connection made. I like the continued innovation and push that Cloudflare brings. Cloudflare is amazing. Cloudflare is such a relief. With customers like Thomson Reuters, Findlaw, and over 10 million other domains that trust Cloudflare with their security and performance, we're making the Internet fast, secure, and reliable for everyone. Cloudflare, helping build a better Internet. Cloudflare offers world-class security solutions that are easy to use. This video gives you the basics on HTTP and HTTPS and shows you how to quickly secure and protect your site using the Cloudflare SSL TLS tab. Hypertext Transfer Protocol, or HTTP, is the standard process in which data is transferred for presenting information over the Internet. But HTTP has a major weakness. HTTP requests and responses are in plain text, which makes it easy for snoopers to intercept and read. Thankfully, HTTPS resolves this issue. The S stands for secure. HTTPS uses Transport Layer Security, or TLS, to encrypt HTTP requests and responses. Instead of plain text, an attacker would see a bunch of undecipherable random characters. You may want to consider enabling the Always Use HTTPS option, which forces all content to be served through the secure HTTPS protocol. Here's how you can enable Always Use HTTPS for your site traffic. Go to the TLS SSL tab in your dashboard. Hit Edge Certificates. Scroll down to Always Use HTTPS and simply enable the feature. Now that we've enabled HTTPS, let's make sure our website's security certificates are properly configured. Ensuring end-to-end encryption of your site traffic is simple with Cloudflare Edge Certificates. SSL certificates make it possible for your website to move from HTTP to HTTPS, which is more secure. Cloudflare is able to offer universal SSL at no cost because of our highly efficient, globally distributed network. Let's take a quick look at how universal SSL certificates and dedicated SSL certificates can help secure visitor traffic to your website. Universal SSL certificates uses one cryptographically secure locking mechanism to encrypt many websites, some of which you may not own. It's highly robust and secure, and a good option for many Internet properties. Businesses that handle more sensitive data, like finance and healthcare, will be interested in Cloudflare's dedicated certificates, which are not shared with any other host names and fulfill certain key business security requirements. Both universal and dedicated SSL certificates are managed, maintained, and auto-renewed by Cloudflare. The Cloudflare Universal SSL Certificate is the default certificate automatically supplied when a domain becomes active on Cloudflare. No further configuration is required for encrypting visitor traffic to Cloudflare. If a dedicated SSL certificate is appropriate for your business, contact Cloudflare Sales to configure for your site. If you already have the feature entitled, go to the TLS SSL tab in your dashboard, select Edge Certificates, then select Order SSL Certificate. Click Dedicated SSL. Next, add host names, and Next again to complete the order. We also provide you with the option to secure your traffic end-to-end, with three different SSL modes. Flexible. Full. Full Strict. Flexible encrypts your traffic between the Cloudflare Edge network and the client browser. No encryption exists between Cloudflare and the origin. In other words, visitors access your site over HTTPS, but connections to your origin happen over HTTP. Full and Full Strict is when the connection between the user, Cloudflare, and your origin server are over HTTPS. The main difference between Full and Full Strict is that self-signed certificates cannot be used for Full Strict. There are only a handful of certificate authorities in the world that are widely recognized as the root of trust. Cloudflare is a certificate authority. Depending on your business needs, and whether your site contains sensitive, personal, identifiable information, determine which SSL setting works best for you. To read more on when to best use the SSL settings, Flexible, Full, or Full Strict, visit our Cloudflare Help Center and search SSL Options. To ensure your site is optimally protected and secured, head over to your Cloudflare Dashboard SSL TLS tab today. For more information on how to use the SSL settings, head over to the Cloudflare Dashboard SSL tab. For more information on how to use the SSL settings, head over to the Cloudflare Dashboard SSL tab.