 We are now recording so everyone should be on their best behavior. I want to welcome everyone to the November Houston functional programming group. Today we have Jeff Olson speaking. Well, he said he was speaking on functional programming and rust but apparently that was a lie. According to this title. So I'm very excited to welcome him. Rust is becoming increasingly popular. I want to mention next month. For December we traditionally do not have a talk we have a social hour, so that will be set up on zoom yet again for this year, and then starting in January. We can all talk about it if we're ready to start going back in hybrid mode or something like that. I'm looking for speakers for next year. So I'll be reaching out to a bunch of you if you have talks topics that you want to cover. Please let me know. I think that's all the sort of business that I have so I want to introduce Jeff Olson and I don't know he can introduce himself actually so go for it Jeff thank you so much for being here. Hi everybody, I'm Jeff Olson. I'm a senior solutions designer at disparity, which if you don't know it's a fortune 1000 company in the HR and co employment space, based in King with Texas. And this talk is titled functional programming and rust parenthetically a misnamed presentation. I think the reason for that will become obvious. As this wears on because I think just because of space and time constraints. I think it's a lot of time probably just unpacking kind of basic things about the language, and that ends up kind of, you know, cutting into the time for I mean and really like the stuff that's. I mean, yeah, it's we don't have the time to give like a workshop on you know basically functional patterns and practices and kind of you know how you would fit them in. I can do something a lot more hands on so really I can, what I can do though is kind of present a specific framing of functional programming. You know, based on certain frames of reference, mostly for you know Haskell and O camel programmers, and then pivot that and contrast it with rust and where things are strong and where things, you know will be able to be improved with time and where they're still pretty Forgive me if I sound under the weather I'm bouncing back from a recent illness so it's not because I'm not enthusiastic I promise you I am overflowing with enthusiasm I just feel like hot garbage. Jump in there very quickly. So if you're sort of partially out the functional programming aspect. One of the reasons that I was really excited about you coming in and presenting on rust is because I know almost nothing about rust. But what I do know is that it sort of it seems my understanding is it comes from the ML line when you're saying Haskell and O camel. Also standard ML, like it's sort of like the imperative cousin of those and it includes a lot of that. So I see you serve shaking your head but but that was one of the things that like has been interesting to me about this. So what I would say is I mean and I'll get into it in the in the talk. Like syntax wise there's a lot of the things that I would call kind of modern conveniences from the ML line. And like I said, I don't want to give away the whole talk before I've even jumped into my slides because I don't really be in trouble. But suffice to say. Yeah, no I think it's it's hard. I think with the experience it's hard to say that it really like it comes from the ML line but in the end there's a lot of there's a lot of like I call like critical betrayals of you know functional paradigms that you'll see kind of played out and those are because of the, you know on on certain places where you have to pick one or the other rust comes down on a certain side again and again and again and that'll become obvious as this talk goes on so without. Let's just jump into that. So I guess, like I said, I'm here today to talk about you know rest programming language in particular functional programming and rest, although you know to be honest that isn't the majority of the presentation, and I hope I'll still get some key ideas across. If not, if I will settle for not criminally misinforming you. And, you know, talking about rust itself I gathered, you know based on things I've heard before that there's a lot of buzz in this community. And I hope that what I have to share is useful. I also before I started want to give a thanks to David Lewis for extending the invitation to me to appear before all of you so I'm grateful for that opportunity. This is probably I mean like a lot of you you know I've kind of stopped engaging with the public community for a while and so you know and getting out and doing talks and stuff so it's good to get back in the saddle and I jumped at the opportunity when it was offered. So without further ado, in terms of the things that I'd like to cover overall in this talk. First of course I want to introduce the project. It's history and context which I hope will kind of clear up a lot of the questions that I made about kind of you know, where when there's these two kind of options where rust comes down on one side, I hope that I can I can kind of clarify some of that to give you an idea of what I mean. In particular, some of the participant pain points that organizations like Mozilla had to contend with in their code bases and why it led to the creation of rust, expanding upon, you know rust extent context. I want to talk about some of the key trade offs that rust makes and where it comes down on a number of issues, and while actually introducing you to the rust code and syntax project layout, basic tooling, etc. Also, for any of you who are actually already familiar with rust like if you're expecting to show up and you know shoot the breeze. And, you know, talk about a bunch of advanced rust stuff, you know that rust is a huge language. I really can't even cover like really even 40% of the languages actual features. I can kind of talk about what I think are kind of the most basis, basic structural things on top of which we can build enough knowledge to talk about the functional topics that I want to cover in this talk and that was kind of what I was going for. And if there's stuff that I miss or if there's topics that I introduced kind of out of nowhere, then that's my bad just stop and let me know and I'll do my best to expand upon that. One of the other courses to give you guys something useful that you can take away from this. Of course, you know, like I said, the promise thing in the title, a discussion of functional programming and rust itself I wanted to highlight it because it's actually it's funny it's actually just one part of the talk. And there's a bunch of other stuff, you know, that ends up kind of coming up and and overruling that. I want to also talk about, you know, in context for rust, I want to present some entry points for different kinds of programming where rust is popular for anybody you know who wants to do certain kinds of things whether it's game dev or embedded programming. You know just kind of provide some pointers for where you can go to find out more information. There's a couple of things I think that are really exciting about the future of, you know, stable rust I should say because there's all kinds of wild stuff in the nightly builds, but much of it never makes it out, or will stay in the nightly builds forever, just because of the nature of it. So that some of the things that are making it into, you know that the stable main branches are going to be really cool. So I'm excited about that. The first I want to just really really quickly kind of talk about rust in brief rust is multi paradigm, which is to say it accommodates a more object oriented style where data bearing structures manage their internal state via methods. And you know the way that we have kind of a concept of structures holding data matched forward to methods or you know, doing certain kinds of like inheritance based polymorphism is through what's called a trait system, which if you're familiar with basically like Haskell type classes where you specify a trait, and then you have to implement that trait you implement it kind of ends up being like a three way pivot between the specification of the trait, and then implement a concrete implementation of the trait for you know data structure, and where you actually will spell out methods and then you know you can have default methods and so on that are already defined. You know those are features that you're seeing that are leaking back up into like you know dotnet core with the default implementations on interfaces. So that's pretty exciting. As well as within rust accommodates more functional styles, you know that focus on things like immutability declarative patterns and purity in design. And the description of the project of course is that it pursues the trifecta of safety, I would say, in safety in terms of memory access that's a really important caveat that really needs to be emphasized emphasized performance. In this case chasing a C++ like performance profile and benchmarks which I think the project has been pretty good about doing and concurrency, which, which I would point out is subordinate to safety. So if you're interested in any amount of multi threaded programming and rest will tell you the compiler will get on you pretty quick, because it is a is a harsh taskmaster. Rust has a broadly see like syntax with some conveniences like the fact that many of the control flow structures like if else our expression style. So you can use them like you wouldn't like O cam only or an ML language where you can use if basically to you know do additional values where things that you would do in like see with the ternary expressions. So you have. But you know just more the idea that like, you know, like that that all blocks blocks naturally become expression based so you have things like return position becomes important and you know things that like, you don't really think about if you're programming in a see like language, but that language is like even like you know Scala F sharp and stuff like that to kind of like you know even if you're doing a more imperative style things that fall out pretty naturally. Sorry. There are also other nuances of the language that has an LLK grammar so some some things that fall out of that is that parentheses are optional in like control flow structures like around if you don't have to use parentheses, but brackets always end up being required for all blocks, except for like single expression closures or you know like in inline specified, you know functions. And so you know because there's always you know because there's always blocks for control flow structures and you don't have things like sentinel clauses or accidental fall through there's no case structures. Another O camel influence worth noting is the compiler default allowance of shadowing variables, which is you know redeclaring redeclaring the same variable over and over, even though it has a different backing type as you know it gets consumed and used. And that's something that you know is it seems to be like a more functional style and and it becomes pretty useful and Russ when you're dealing with linear types that you know you basically consume minute and excrete new values over and over. Rust is statically typed with a rich type system that's most often compared to Haskell but it's worth noting that includes a few features mostly because of the borrowing and like value moving systems. And that really, like, only, can you match or surpass when you get into dependently typed systems like coke or Agda. And so you know but that being said, of course, Haskell has you know out of the box like higher kind of types. You know that are expressible in language right now rust is coming about with a way to have the same level of expression but they're approaching it from a different angle I would say, because I mean if you look at HKT you understand that it requires basically run time like there's a lot of run time stuff happening under the cover. And so with rust you don't necessarily have that. A major goal of rust has also been to expose what's commonly called a see like memory model which is usually shorthand for something much closer to how a processor actually works although you don't you know get access to registers and stuff. This is most important when you compare rust against more pure functional languages, who by their very design kind of require pervasive uses of things like linked list and hidden heap allocations under the covers and garbage collection to kind of abstract away and you know give you like a more pure environment to work in. And for rust is to not compromise on any memory access functionality offered by C and C++ and, you know, because rust also includes a robust form function interface for consuming and exposing rust code to C and C++. You know, like those things being hard constraints, ultimately those are things that kind of chew away at a lot of, you know, like the functional conveniences that you see in other more pure languages. And above, you know, like the focus on, you know, performance, and, you know, transparent memory access rust focuses and you end up seeing it kind of blown out in a lot of the standard library types and of course, library types produced by vendors is the focus on Rust abstractions and a lot of RIAA mean like resource acquisition is initialization style patterns that arise as a result. So, you know, if you're familiar with me particularly in like C++ rust has got you there and it's still there. Rust also boast I would say what I think is the most robust developer tool chain out there. And perhaps that if there any dedicated Haskell or, you know, OCaml or go or no developers who feel otherwise then I'm sorry. Reasonable minds can disagree on this, I hope so don't flame me too hard. Moving on to talking about rust the project itself. It started out initially as a project of gentlemen named Graydon whore, a Canadian developer who I believe he did undergrad and math and then a masters in CS before moving on to industry work. Most of his work in his CV is around kind of compilers and what he calls industrial C++ so kind of working on that high performance, a high availability high availability, high availability systems that because of implementation needs need to move down, lower down the stack and away from, you know, virtual runtime environments. So that was kind of his experience and then he ended up landing at Mozilla where, you know, the major issue for them is basically they're, you know, at this at that point, I mean, 15 years old give or take depending on how you track the age of a Mozilla going back to you to be the biggest incarnations, you know, an old very mature very large C, C++ code base and them dealing with, you know, basically memory related issues. And you know as that being a major source of bugs and vulnerabilities and for them. And so for him the motivation to make rust would be summed up I guess like so and this is paraphrasing a 2019 Twitter exchange that he had. And I quote, like throwing C++ folks, including myself a life raft with regard to safety safety is the thing the C++ and we want to hit the C++ niche, but we want memory safe and including including race for three multi race free multi threading and that's hard. So, building kind of working on, you know, that project he started with, as if the original rust compiler was done in OCaml. And while he was working on it at Mozilla they began sponsoring the project, and they helped put together a team of researchers, particularly a gentleman named Nico Matzassis, who made what I would say are some pretty critical contributions that I'll get into a little bit later. So, you know, with that, you know, with the team together the core compiler was rewritten and became self hosting, you know, before the project was announced in 2010. And then between 2010 and it's 1.0 release they iterated on a lot of features including adding the like the borrowing system didn't exist at the time of the first alpha release, and the way that they were basically dealing with memory safety was kind of with like versions that separated heap allocated from like locally in thread reference counted things from pure value types. And they eventually iterated towards a system that ended up being more like C and C++ but had, you know, the borrowing system included which itself is kind of an extension of a cyclone, if you're familiar with that which was a C dialect kind of experimental dialect that had some early versions of what you know would become the borrowing, what you know becomes the borrowing system in Rust. So, like I said, you know, the, including the borrowing system, just making changes to the language to hue even closer to a true C++ memory and runtime model. The early version of the language actually had like a checked constraint or contracts feature like where you could put constraints on functions that was removed. You know, like I said, tool, you know retooling of syntax references boxes which are, you know, Rust is Rust, basically library type for dealing with heap, heap values, or you know, memory allocated on the heap. The introduction of mutability kind of as a core concept for when you like at the time of specifying a slot or a variable specifying mutability and kind of the things that fall out from that. All of that was done before reaching 1.0 in 2015 and since the 1.0 release changes to Rust have been organized into three rolling offerings there's a nightly version of Rust that's built and released, of course nightly, based on the state, the passing state of the trunk of the Git repository, you know, so if the main trunk is passing then, you know, they'll release. They have a rolling beta release that I believe it is updated every six weeks and things that quote unquote graduate out of the nightly they go into the beta release. And then they're there and they'll stay there for a while. And then finally there's a stable release that contains features graduating out of the beta on a rolling consistent six week basis. The latest releases one is Rust 1.56.1. This is a point release on the 1.56.0 to address a code formatting CVE. It's not like it's actually really interesting vulnerability. And if you go read the 1.56.1 announcement at points at them. Basically they introduced with 1.56.0, allowing you to use like arbitrary Unicode for identifiers, which wasn't a thing before. And so when you have arbitrary Unicode and identifiers there's ways to sneak in like basically empty identifiers that would mess up the code formatting based on whether it was right to left or left to right and so you could get the situation where somebody could maliciously basically pollute the identifier spaces so that basically code when you looked at it as a raw file versus when it was actually compiled. It would actually look different in different situations. And so they did a release to address that. And then finally Rust also periodically releases additions that represent basically breaking changes compared to previous additions. So when Rust 1.0 was released, Rust 2015 was the addition that was released at that time. In the rest of the version all prior additions will be supported in the compiler and individual crates opt into which addition they support. The latest Rust edition is 2021, which like I said, or if I had mentioned it, it actually was debuted at the same time as the most recent Rust release 1.56, which was at the in late October. As I said before, of course, Rust is an open source project and it's developed out in the open on GitHub. They developed a lot of really amazing build infrastructure and I'd say that it's a huge part of their project expenses, just running their build infrastructure considering the amount of stuff they're doing. And just talking about contributing to Rust, it could be its own discussion so that's something you're interested in or learning more about the project structure and kind of you know what all is there and how you can get involved. You can check out Rustlang.org to learn more. Of course, Rust was originally owned as a project within Mozilla but has since been spun out and is now governed by an independent nonprofit that manages trademarks and copyrights and provides a funding structure for sponsors. I also read after I made this slide actually the new batch of sponsors just joined this month, including ARM and Toyota or others. I don't know, are there any Misra C programmers here? Anybody know what I'm talking about? Any embedded folks tonight? No, okay. Yeah, so it's interesting that auto manufacturers coming on because what they have right now for the state of the art for auto programming is pretty gnarly. If you're curious, like I said, look up Misra C, M-I-S-R-A. And so, since before the 1.0 release, the Rust team has been doing most of their feature development out in the open through a public RFC process where the community members suggest features kind of as in a standardized essay format. And they have a place to kind of discuss and debate about that. And then also, you know, the RFCs themselves kind of become tagged and numbered so that they can be referenced explicitly in a subsequent pull request. The Rust government governance structure features a core team that oversees the directions of the project and then sub team leadership, leadership of sub teams and then cross cutting concerns. Sub teams cover everything from the compiler infrastructure, language features, Crate.io management, Crate.io is the website for kind of the backing package system for Rust. I don't have a lot of time to get into the developer tooling, but you know, Bear's mentioning that Rust ships an official supported package repository akin to NPM, but with many features that are more appropriate to the fact that it's shipping native code and a lot of, you know, like dealing with different platforms and so on. And of course, like I said, dev tooling community moderation releases, etc. So for next I want to dive into talking about the key trade offs of Rust, but first, let's actually show some code. So what I'm going to do here is I'm going to go and actually just use the Rust tooling. Everybody can see my that's not too small is it my PowerShell window. So I'm going to go ahead. It's pretty small. Okay. So, what I'm doing here is, is that a little better. Yeah. What I'm doing here is really quickly just spinning up a new. You chip in by Claude a bigger screen. Well, that that is true. That is true. So really just for I use cargo, which is on rust basically package and project management tool to initialize a new project and so what it did was it spun up this library and also it made it a valid get repository. So it's in place for us and then I just opened a visual studio window. First class rust tooling is available in VS code if you want to do that I would just install it recommend just getting the rust extension. So what we get here is of course like I said this is a get repository so they give us kind of a get style. And then this Tommel file is basically the manifest and if you're familiar with you know npm or you know applications or package roots this is equivalent to you know the package JSON. And so you can specify a lot of the same stuff although it has a lot more stuff that is you know germane just a rust. The actual source itself we actually have the library and so what they gave us here was just this little actually just a bit of test code so really quickly what we have here is this is a basically a compiler directive that says to only compile this code when we're compiling for tests and so the compiler will know whether it's compiling for a build debug production or you know test and it does basically you know that affects the size of the binary by convention rust. They don't have separate libraries or even separate files. Usually the tests are in line as freestanding functions alongside where actual implementation is that's just kind of by convention that's the way that you know they've done it. So really quick though I just want to go ahead and make a make a function that does a thing. And go ahead and then, oh, whoops. Excuse me use it. So here just really here really quick within this function. We can go, we can see. Once again I can use the cargo tooling and it'll go ahead and it runs this one out of the box test. So, want to go ahead and just use this, and I want to go, and I want to run it. Whoops, I did not save. Whoa, what's this about it's complaining it says it can't find this function and scope what's that about well, it turns out that what I need to do. So in order to make use of this is I actually have to import this thing in. And so in order to get that to work. So that kind of brings us to the first lesson of rust, which is that rust really favors explosion over succinctness. That is the rust compiler will almost always push you towards explicitly spelling out your expectations it does it assumes very little. And most of the stuff where it does assumptions is for convenience around managing references and values, but for almost everything else. They, you know, the compiler will make you pay if you, if you don't spell it all out. And I'd say, you know, as part of that rust already has a reputation, rightly earned for having a really dense syntax with a lot of gotchas from the compiler, and this is I mean of course part of the design of the language. I don't like it. I mean this is kind of where it's at I doubt it's going to get much simpler, your alternatives are probably swift, or maybe Haskell. I don't know so have at it. I'm kidding of course I know there are lots of there actually are lots of other platforms, like your guy gave the presentation a couple months back talking about Elm, and his platform he was working on you know so there's a lot of people are kind of tackling. You know what rust is doing from different angles, although I would say that that link that that platform was a lot more loosely typed than rest so. Next, none of the next key trade offs with rust of course and I'm in it at this a lot is that performance over convenience and so rust by its nature really really cares about performance, its history as a Mozilla project meant that you know for them to be able to replace parts of the most Mozilla browser which itself, as I mentioned is a massive C++ code base. That's what they wanted to do with it. And so what they had to be able to do was you know have transparent memory access and give developers tools to reason about how intensive their programs will be, which, you know, almost 95% of the time comes down to really just being able to remember reason about memory allocations. And if you can get that down and you can tighten that up. That's where you know the lion's share of optimizations and code bases come. And this is of course is because rust doesn't do much magic under the hood with memory allocation and so kind of to demonstrate this this table that I have here. I've included it from the embedded rust book, which is actually really cool if you go out and Google it rust embedded. I believe is or just yeah rust embedded or the rust embedded book they've they've got an online document for it. And this this table outlines the impact of marking your crate and so that's when I talk about marking the crate that would be within that cargo Tamil file which I mentioned is the manifest spec specifying no STD and so what that means is basically building this the crate your dependency whether it's an application or library without any dependencies on the rust standard library. And so what you can see here what you get when you when you do know STD is you basically you lose heap allocated types. And so things that build on top of heap allocation so specifically there's some mem alloc a method within there that does you know for doing heap allocations. The things that build upon that in the library like vectors which is basically you use like a link list you know just an infinitely expanding list although there the implementation is different from the link list so it's not fair to call it that but you use it basically in the same way or hash maps which is like their equivalent of a dictionary type. You basically don't have access to any of that. You can see stack overflow protection gets stripped out. There's some there's certain way certain libraries or dependencies where you can specify initialization code which will actually be ran before the main entry point of the program that goes away. And then of course the standard library which is you know the majority of you know the officially supported code is within there but there's a smaller library called lib core that has basically all stack allocated types and abstractions that is still available and what you get when you strip away the standard library is a massively smaller binary that is appropriate for using when you're writing firmwares doing firmware code or kernels or or boot loader stuff. So, you know the fact that that's possible and rust is kind of a testament to kind of where you know they're going because we take it for granted that languages like see just do that out of the box because they were purpose built for that because of the era in which they were built in the abstractions that were you know at the time of C's debut is considered incredibly high level, but nowadays what C considers high level is actually really low level for what us as application developers deal with so to come back and actually approach that and take that problem on to be able to meet it there. And that requires a lot of stuff that you know you have to think about and deal with that you know doesn't isn't obvious at first you think oh this would be easy I could I could do, you know, you know, like anything more complicated than a than a fourth interpreter basically it gets really hard. So, the next item, of course, I mentioned, you know, with key trade offs and rust is memory safety memory safety is really really important. And so, pretty much when anybody's talking about safety and rust really they're just talking about memory safety. And so that and that's, it's pretty important to kind of grasp that. And you know there's some things kind of that I'll hang out and and and talk about in this talk that I gloss over but I just want to re emphasize so things like move types value consumptions they they constitute what's called a linear type like in type theory, which is basically like a thing that's there or not, and you know it specifies that like as part of a types life cycle you include the concept of it being consumed and being destroyed. And so, with that, and how it complements the borrowing lifetime system and rust. Natural patterns arise that kind of allow developers to design systems that I think, you know, include that kind of safety. And then also examples that I show in this talk with closures and like, you know, Lambda methods basically they allied a lot with how rust distinguishes the difference between pure functions and closures within code and you know the difference between a pure function and closure is closures capture values out of their enclosing lexical environment, and then incorporate that as part of their value for their lifetime so that has implications for you in a in a in a language where you do manual memory management that don't come up and garbage collected languages. If any of you I don't know if any or there's C plus or modern C plus plus developers here, and you know that when they introduced the Lambda syntax there's also a pretty heavy syntax for captures and how captures happen. And so rest also has to account for some of that stuff. But anyway, the important thing is that the, because of memory safety because of the borrowing system. There's a subtle and difficult to reason about issues that can arise. Particularly when working with higher order functions and I will get into some of that. I do have a question about the bar system. If I remember correctly. So only, you can have multiple writers and one reader. Is that the, is that the situation you're talking about for referencing for mutable versus immutable references. Yeah, it's the so it'll be the other way around and it depends on what's happening. So if there are mutable references held, then you can't take a mutable reference because you might mutate it out from somebody but when, excuse me, it's the other way around so you can hold you can hold multiple immutable references but only a single mutator at a time. And then, if immutable references held the new immutable references won't be allowed. I guess wrapping up on this with the trade offs. And, you know, if you imagine a continuum with the land of calculus on the left hand side and machine instructions on the right. For me rust comes down somewhere in the center right. Like I said it includes and talk and a lot of stuff in its type system and conveniences that are obviously descended from the ML line of languages. And as I mentioned, besides C++ grade and horror himself as a big O camel guy. But in the end again and again where it has to rest always goes on the side of basically coming down more towards C and C++ as it as it has to do with memory management. And so for that reason there's a bunch of kind of you know you kind of end up kicking the box out from underneath a bunch of functional stuff that you'd have otherwise. So, next, I'm going to go ahead and do a whirlwind tour of rust syntax and features. And so, I'm going to talk about all these items. I'm just going to kind of blow through a source code file that I have kind of set aside for this to talk about these things. So, first we have control flow. And so, as you see here, you know, ifs, the blocks are always there but there's no friends that are necessary. And, you know, basically C style if if and else we, we have here is basically expression style use of if and else to capture value out of it. And Tyler will look and verify you know it does all the type, the type stuff to make sure you don't return you know, you know, type type f out of another one and type T out of the other you know so you have to match all that stuff up you get all that for free. Of course because this is a statically type language, you know, all of these things even though you don't specify explicit type. You get pretty far in rust without having to specify the type at the point of a new where you define variables, but occasionally, and it becomes the thing if there's you know enough ambiguity, and what it is that's being done. Next we want to talk about closures of course so this is the syntax right here for just a basic closure you can see that has multiple statements. It doesn't emit any return values. And it has no input so if there was values in here like this would be, you know, this would become an input value that we need to be provided. But what it does show is it shows capturing out of the environment. And so this is a closure this isn't a pure function, because it doesn't take any inputs it doesn't return any output so it's kind of a black box what it does I mean by that by there kind of you know questions where it's not here, but it also is capturing this value out of here and it's doing this by taking a mutable reference to this already stored mutable value. And of course in terms of stuff that rust us for free, if that mute went away from after the let keyword then suddenly this is an immutable value and we can't take a mutable reference to that. So this kind of gives a hint to kind of how rust deals with mutability at the point of slot definition. So like if you have a structure that has values within it. Those values themselves don't have their mutability specified it's always at the point of the, the exterior storage of the enclosing type. You know you can have basically cascading, you know hierarchies arise out of that. There are some library types that are meant kind of to do, or to allow you to have that kind of by their nature and design, allow basically side effects to leak out of what looks like an immutable type. And that mostly happens with like unsafe code under the cover under the covers and it's kind of in, you know, limited circumstances. So like I said here with this example you can see, this is a closure capturing a value, and then doing a mutation on it, it has to this right here is it de referencing the value because this is a reference of course. And then so that it can mutate it and then coming down here actually, you know, executing that that type, or that that you know function that was specified here this closure, and then being able to look at you know it's value before and after. I want to talk really briefly about kind of array types. So one of the things that's notable about them is that their length is a part of their value specification, and I guess also speaking really briefly I didn't I mean talking about basic syntax so let is of course you know familiar with okay when you're not specifying a type. This is the variable name. If you're specifying the explicit type it follows after with the colon, like so. And then this of course is initialization. This is you know one of those languages the one that you initialize empty values there's no concept of a null value within the core link within the safe core language itself. So everything needs to be initialized and it validates that. Here you can see this is basically different syntax for initialization like if you wanted to just, you know, build out an empty 500 element array, you can see how you can do that, or you can specify each individual item or of course you know, at runtime of course you're going to have you know they're going to be dynamically constructed. But it's interesting to note that like I said that I'm length is a part of array type specification and so this right here this is a this is a stack allocated type is what that is. So, of course we have normal indexing into arrays, and then we have typical, you know, types, or you know, basically convenience helper functions out of the standard library. You can see that the arrays are stack allocated so we can basically look at the memory footprint of it and actually see that it's going to be size event 32 times 500 or whatever. And then we get into kind of a basic example of borrowing. So I mentioned this before up here with this, you know, this constitutes a borrow taking a reference to this thing. And so borrowing refers to the system of the compiler. And it's referencing system, but it's accounting for all references taken and it's making making sure that any reference taken doesn't violate mutability constraints placed upon the type it makes sure that any references taken that the value where the reference is taken isn't taken while a reference is held, you know, a bunch of things that ensure kind of the soundness and memory safety guarantees of the language. So what this ends up being is a slice which, you know, a reference referring to, and so this is a special type annotation that looks like the array but it doesn't have the length specification as part of the type signature, and it just has this to specify so this is just it just lets you know that this is some amount of elements of type I 32. And then it's able to work upon them here. Another thing that's interesting of course is that because array types are static at the time of definition you can see that this particular definition of this type excess. This is invalid because, you know, it only has five elements so with a zero based array index this is a beyond. So, that's kind of just you know, showing what it is there. Next, I want to talk about enums it's funny kind of enums popped up before talking about structs and so you can kind of construct more constant, you know, more complex types out of complex combinations of the two. Enums of course are, you know, algebraic data types, if you're familiar with them from, you know, F sharp O camel, and Haskell, you know, they're there it's, these are kind of basic enums but of course enums can be have like arbitrary density or complexity. This is an example. So I mean really quick you can see, you know, kind of the ways that you can do pattern matching that arises off of enums that's kind of really the interest, you know, exhaustive pattern matching is really is probably one of the main things and the destructuring that you're allowed to do out of that. And, you know, you want and of course enums are also like in memory they're similar to a tagged unions and see so basically what they carry is you know, a region that's the size of the largest enum variant and then a tag. And then it knows basically to swap out the contents based on what the current variant is. But in memory, you know, they look basically like see unions with an additional tag. This is an example of a slightly more complex list that pretty much mimics like a cons style, you know, linked list, where the, the enum can have two possible values it's either this contents of itself which is its current value, and then a box which can keep allocated value pointing to the next item in the linked list. And that thing itself can either be another one of these, or it can be a nil value specifying the end of the list. So that's kind of an example, you know how, you know, ways that you can be used I mean really like enums arise in systems like you'll see a lot of like I don't know error types that are manifested as enums so that each variant can carry custom information. You know, if you have a, you know, TC, you know, TCP packet processor, the variants might be different kinds of high, you know, packet packet protocols built on top of TCP, you know, the disguise the limit and so, of course, if you guys come from a functional background, particularly in Haskell or F sharp or O camel, and that is nothing new. Moving on of course we have structs as well which are pretty much more C style memory layout data structures. So, those are really straightforward you can also have what are called unit structs which basically function as like atoms they have no value except for themselves or like a, or like an enum with only a single variant is another way to think about them. And then you can also have tuple values where you don't care about the names or identifiers of them you just care about them as basically, you know, ordered combinations of values which will destructure at some point in the future. I haven't shown it really here but rust includes robust destructuring syntax like you would do in Haskell or O camel or F sharp. So, you know, taking apart values and then all of the destructuring capability exists in the pattern matching system itself. And as time goes on rust seems to get, they're actually putting a lot of work into kind of making the pattern matching system itself more robust and more convenient to use. But that stuff is totally like I don't, I don't have time to cover that unfortunately I'm already over time. And moving on to the next item. I wanted to talk about the bar kind of give a practical example of the borrowing system itself. So this function itself kind of constitutes kind of a discussion of kind of gotchas with the borrowing system. So when we start out with this for creating two values, one of them is a boxed value that just contains an integer. So if you're, I guess, you know, F sharp and O camel style kind of annotations you can also do stuff like, excuse me, you know, like that and sit to have instead of commas for breaking up large numeric values. And then but rust has for its type literals basically, you know, I 32 you 32 and 64 etc. And the things are, you know, they come out naturally and the expressions of the types there's no, you know, there's no platform dependent like whatever the platform says a number is like that thing how there isn't see where you can have 16 or 32 or 64 bit integers, depending on the platform standard. So here we lay out these two values one is boxed and once placed on the stack. And this these this all these methods do is basically just exist to kind of demonstrate what they would do with these things so with the with the function signature of this, this borrowed I 32 value. It is a reference that's been taken to this thing. And contrast that against this eat box I 32. What it does is it takes this by value and so it says this function takes ownership of the box, because of the way that this is annotated it's taking the box by value so whenever this is called that value goes away. So here we have some examples of how we can see we can borrow and work on these values. Maybe do them use them for subordinate, you know, calculations or whatever. You know, these, these methods save memory because they just do pointer access to this thing that lives on a higher level higher frame of the stack, instead of having to pass it by value and copy it into their own stack or something like that. So you know there's that convenience there. And then within this nested block, we see doing some things like here that boxed value, which you know, it represents a heap allocated value but it exists as a value. It's a reference taken to it. And so that reference can be used within here. But if we did something like this, like I'm commenting this method right here and eat it. Then what happens is this boxed value, it would be destroyed at this point or it be consumed and not not, you know, emitted out. And so this breaks right now because that subsequent call to try and borrow it, but it becomes this becomes legal. You know, that's commented out also subsequently because of that this call now is no longer valid because the, this boxed value is already eaten up here. So these are all things that are basically happening just because of them. Oops, and commented the wrong line. These are things that are happening because of Russ borrow checking system and pretty much all it's doing is, you know, validating that what you're doing with variable what you're doing with, you know, values and their variables and how you're referring to them that all of it basically ties out within the current context. And it's able, you know, to do this across functions and you know across function call boundaries and then you know, basically, to the entire boundaries within a crate and then doing whole program processes when it actually links a program together to, you know, enforce these constraints. Next, I want to talk briefly about traits. Like I said, this is how you kind of, this is how you do like inheritance polymorphism, and what you would do with classes and C sharp or with type classes which that you're almost exactly like, you're able to basically specify the trait and say here's the behavior I want implemented you can provide default implementations these can also be you know, overridden and implementers. The rust provides the ability to do like a bear implementation just against a structure itself so these will be basically type these will be methods that will be available when you're interacting with the concrete type itself. If this was cast or type into, you know, cast or boxed into just the trait, then there would be basically those things aren't available, you know, so this is, you know, kind of, you know, encapsulation and hiding functionality. And then finally we have the implementation of the animal trait for a sheep, basically with the defining of methods that do things on the sheep itself. All of this is kind of, you know, really noisy but just to kind of demonstrate like I said they're kind of this three way pivot. And so it's interesting where, you know, you either have to own a concrete type or the trade itself in order to do anything useful. So if you have like a library type, and you have the end, you know, you and there's a trait that you wanted to have it implement, like, you know, the challenge to be able to do that. It kind of becomes tricky based on where things are. And so it's, you know, you're expected to be able to have like, you know, interior ownership of either a trait or a concrete type. And finally, oh no, excuse me, that was just the thing for that. Okay. Ready to move on. So that was kind of like I said just kind of a quick overview of other syntax was there anything here that was like really puzzling or weird to anybody I know I'm covering a whole bunch of stuff and I'm moving really fast. So any questions for anyone. Just a real quick question. Can the implementations. I mean, do they have to, I guess, you said you had to own either the trait or the class. So can implementations occur in like other files so if I import, like, type animal from a from a carpet from a, you know, a package. Yeah. Or I could implement or I could import sheep and then implement animal in my. No, it's at the crate boundary. And so you can't pull in someone else's, you know, create, and then, you know, because it's like, if there's like a library that you want that has a trait and then some some other, you know, library that you want to implement that trait for like you don't know these are those things. So you have to ask one or the other basically, you know, to. Yeah. Alright, finally. So we can talk about functional rest now and we're here we're here to the meat of it last. So in order to talk about functional rest we have to kind of set some boundaries around what exactly is functional, functional. So for this I'm going to kind of give the hand wavy answer of saying that there are certain principles which make code more functional. Some languages make this easier or harder to adhere to, and generally speaking languages that make it easier to adhere to functional principles are considered functional languages and even if they do that though, they often, they make it harder to violate these functional principles but however, you know, almost always there's some way for you to do it to break, you know, functional principle principle encapsulation or whatever you want to call it, if the situation demands it. In general we have these things that we say if a language or a system is more like this where it supports this then we consider it more functional. And so those things are I guess really briefly I would say mutability. You know having to do with kind of how you treat values and how they're changed and how you know they are applied within functions, I would say recursion is an important part of it. And then also of course I would say higher order functions and kind of function pipelining become, you know, are things that are kind of like, you know, they really play out a lot in functional languages and kind of become core things. So with that in mind. I would say talking about mutability. I mean just looking at excuse me some of the previous examples like where we talked about with the borrowing system. I think that it's pretty self evident that you know rust has strong controls around mutability. Of course it allows you to break those, you know rules or just to make things mutable. And so out of the box and the behavior, you know it's perfectly possible to write pure functions and pure programs in rust, you know, because of just, you know, the, the, the basic building blocks are there. Next when I talk about recursion I'll just say really quick rust doesn't have any tail call optimization. So if you want to do a system where you're going to where you would have something like some, you know, infinite recursion, you will, you can and will very much get stack overflows like this example here shows you absolutely, you know, will blow up in this case because it doesn't just recurse until it runs out of stack. You know, and you don't really need to implement your own trampoline, which is the way you know that like you kind of do a recursion like system functionality and systems that don't have it. So if you have rust has what are called iterators which is pretty much a trait and language support feature for doing iteration over, you know, values that are that are amenable to be iterated over. And the way that it's implemented it allows you to kind of have like dynamic infinite objects or objects that block the next time you try to go to an iteration or something like that. So you're doing a lot of the things that you would when you use recursion as a control flow mechanism in functional programming. And then of course talking again about a higher order functions. You know this is kind of the idea right that where you pretty much just compose pipelines of functions working on values and mutating them until eventually you get the thing you want. And so this is kind of an idiomatic example of how you know you would take, you know, create creative value from zero to 100, and then, you know, double those, and then sum them back together. And so you can kind of see I just I had just kind of the Haskell golf parlor trick version of this to put it alongside what you would do and rust to show that while it is a bit more verbose. You know pretty close and that being said, I'll say that a lot of the cool stuff that you're used to if you're doing a lot of hardcore, like statically typed functional program and also says as a Haskell baby. I'm pretty new to Haskell. I mostly come to it through Elm, and I've wanted to do more. I'm still, I'm still on that journey, but a lot of stuff that you you know would do idiomatically in those languages like currying doesn't exist. Like point free style, like, like pipelining doesn't exist in rust so you do kind of, you know, they're the same tools aren't there kind of to use higher order functions in, in like really, you know, I guess like intention revealing in more declarative ways, because rust makes you do a lot more gate bookkeeping. And also, the thing I mentioned earlier about memory safety enclosures. It's really easy when you're working with closures so these are these are all just pure functions these are like these are reified as function pointers at runtime. They don't have any any additional state with them because they don't capture anything out of enclosing context. But as soon as you start having things where like it really makes sense to do that and you start capturing stuff, it becomes really hard to actually use a closure. And so you have to kind of fall back to a couple of things like generic traits and methods that consume them. And it kind of, you know, it gets complicated and it limits utility and this kind of plays into the memory safety and especially once you get into like multi threaded programming because almost any like, you know, like, like and see your people like ultimately in any language, you know, or any asynchronous backend when you want to spawn a new thread or some kind of background process, you say run this function pointer basically is what it always comes down to. And so in rust at the point where you have to pass that function pointer, if it's not, you know, just a bare function pointer than things get complicated. So that's where you know like if you're trying to capture anything, you know useful. That's a that's a situation that rises in rust where you know I think developers end up having their hands tied. And then last, like I said, kind of, you know, because recursion isn't there what we see instead is iterators and so this right here is just the declaration of a vector so this is a special shorthand form for declaring a vector which is just named for like a linked list or a dynamically expanding list with what they would be in other languages. And so then this is kind of the natural way to iterate over them but what's happening here actually is this is all de sugared syntax for basically doing this. And so if you if you you know, kind of this stuff right here, this is kind of what it actually looks like at runtime and so what we're doing here with this vector is we're turning it into an iterator. And we're you know making it mutable of course in the process, and then you have to iterate over it in that process. And so this while is pretty much simulating that process this next returns an option. And so this let some is actually kind is is a is a sort of. It's a sort of conditional expression that saying, while the result of this next call is a sum value because this actually returns an option which is a sum or a none of T. And so this says while, while this iterator next call is returning a sum and this is the value that's bound for use within this block. And so this is a while loop, but once this next reaches the end it'll return a none, and then this, this loop would break out. So that's kind of that's kind of like what this boils down to. And so just looking at that and seeing that you can kind of see that you know, taking this syntax and kind of boiling it down to just this is a win. You can also see that within this natural form, a lot of opportunities to do kind of neat tricky stuff arise where you know the iterator is actually like something that's blocking on external input, or you know incoming packets and a server, or stuff like that like there's a lot of you know stuff and this is the same places where you would see like, like lazy evaluation used in high school. All right, so that was functional rest. All right, so with that out of the way I wanted to talk a bit about kind of like how you would, how people are using rust and different contexts. So I'm rust is really I mean popular and I think a lot of people come to it in the context of like back end that are doing a lot of like data work low level IO or lots of like, you know, like DSP type stuff. And these are things that I think a lot of people before now we're doing a node JS but kind of they hit the limits performance wise particularly around like DSP work that, you know, you see where naturally if they wanted to go away from, you know, a high level async IO engine like node, they would have to move their next place to go would basically be to see, you know, so now like rust is becoming more popular in that space. Of course there's a lot of like if you got anybody here is into like blockchain technology rest is you know a lot of the newer like I'd say like post ethereum or the Ethereum killer blockchains are coming out a lot of them like a Solana are having you know rust support as kind of a first class things that's pretty exciting. Other places where it's rough, more rough, like some of the tooling, especially for like using rust is web services are kind of like more like you know application level web services the tooling is there but it's rough so like if you want to use rust to stand up a restfully API with jot authentication, you'll have a lot of stuff that you're going to have to, you know, stumble over, especially once you come into dealing with you know, integrating with your actual, you know, security or your actual authentication provider, whatever that is. It's a robust modern infrastructure you're not, you know, the way that we do authentication a lot of that tooling is still not great, in my opinion, and for raw web application work I mean rust itself doesn't have a lot to offer over something like engine x serving up, you know, you know, like an angular application. So, you know, it's, it's not a big win there in that space in my opinion but some people insist on using it that way. And hopefully once the tooling gets better, particularly around web services. I hope that you know rest will become a good option, especially because of how expressive the type system is rust is, on the other hand seeing a lot of uptake and developer tooling, especially in the web application infrastructure space. And that is, you know, really into web application development next JS has rewritten their pretty much their tooling stack on top of rust command line tools, Rome, which is the successor to the Babel transpiler if you're familiar with that you know it's kind of one of the first type transpilers, or excuse me like ES 2015 transpilers that was out there you know that was providing ways to kind of you know write more modern versions of JavaScript and then spit them out and you know more browser consumable forms. And then the successor successor to Babel, written by the same author he is using rust for that. And there's a lot of others Deno SWC and parcel. A lot of like, I believe, Google, not or excuse me not Google but a cloud flare and Amazon both have quick parsers when you're like HTT HTT 3.0 parsers written in rust. If you want to learn more about that there's a really good pretty recent blog post on the topic called rust is the future of JavaScript infrastructure that you can look at to learn more. Of course rust has a lot of interest in buzz and also hate I would say in the game dev community. There really aren't any like big triple A games that have shipped written in rust, but it definitely has a lot of interest and there's some great tooling that's there I like to play around with engines, and there's tons of engines and stuff like that to play with and rust. If you want to check out one in that you can look at the bevy engine be v why. And it's a really interesting kind of a vented architecture. Rust game early like data oriented like an ECS system. Of course embedded programming is a is a popular location thing I talked about that earlier with the no STD annotation and kind of the applications that you can get with the impact of that is. And of course while rust is a challenge and more and you know more space constrained like eight bit processors you know where it's hard to even you see and you probably, you know you probably have fourth or just straight up machine code. So finding uptake on you know platforms that have more head room. All the tooling and design is there to embed rust in a way that just isn't possible in most other languages like I talked about because they're really grasping with the consequences of trying to have a really see memory compatible language and dovetailing with the above of course, the Linux kernel itself is starting to make space and the recently they've done some things to make it possible to basically write drivers and Linux kernel modules in rust. And chances are there won't ever be rust itself in the Linux kernel tree, because they're, you know, GPL three people and rust is an MIT code base but I mean, you know the rust code itself or whatever you know that I my understanding is that they're just not super the idea of starting to take on rust but vendors will be able to start writing kernel modules and shipping them with their products or you know, or individual companies that you know if you're a company that's a big enough deal to have your own you know custom kernel modules, think Facebook, Google, etc. They have the tools to be able to use this. Very quickly talking about the future of rust some really cool things that are coming down the pike. So this is stabilization of a feature called GATs, which is generic associated types. And so this is an exciting addition that extends associated types, which is a, it's a feature that I didn't even talk about in this talk. Just to show, I barely even, I didn't even really talk about poly more, you know, like real type polymorphism that is available in rust, but I'm associated types are a way to kind of specify like a type slot on a trade, separate from like a generic constraint itself, and it just means that the implementers have to specify that type, and then they can reference that type within, you know their implementation. So, this is an extension to associated types that will allow you to have additional generic annotations on top of that, which kind of gets us pretty close to the idea of types that are abstracted over their type. You know, a thing that can deal with a type that is an abstraction over other extractions itself so kind of you know like a way to chip at higher kind of types within rust, and then combining that with what are what feature that's a const generics, which refers specifically to allow the embedding of const information within a type as a dynamic parameter. And so, and really quickly kind of to demonstrate what that is, like, in the example. Here where I was talking about the use of arrays. So this is of this is a feature or you know, basically a part of the type itself. And so that comes out as like, you know, item of T with, you know, a length of K. And so there are T items, and they have a kid they have a length of K. And so within within these right here within arrays that the type is a as a part of their, their type definition but you can't specify a generic type, or, or like set a generic constraint where you can say, you have a type of T and that, you know, the the the length of the tone in itself is a generic is a generic thing that can be deferred until further on. And so this isn't really the greatest explanation for but the idea is that they're making it so that you can have, you know, generic. So you can make things that would be, that would be size fixed at compile time, like into generic constraints so you can have like, basically, a type that represents, like a fixed length of something and so that it'll be pretty interesting for like what's possible in the future and I think these two things put together are going to kind of be what gets the community towards you know being able to have the expressiveness that a lot of folks are looking for with higher kind of types. It's pretty exciting. And this stuff is kind of coming down the pike, hopefully like in the next year we'll see it on the main branches. Is there a concept of like generic constraints on those where you say it's an implementation of this. You can say T yeah I, I don't think I have an example but yes they're they're generic constraints as as robust as you know. So with GT could you for example say this say this function operates on an X of T where X is a Yeah, so the with GT itself this is going to manifest that the annotation for for associated types it appears within traits themselves. So what it will allow you to do is write traits that abstract over a type that itself abstracts over an additional type. And you can place well and so additionally so the kind of the thing as well and something that I completely didn't cover it because like I said there's just the space is too large in the time that we have. You can also place generic constraints around lifetimes so you can set constraints and you can carry lifetimes as generic parameters themselves. You can see like a lower case letter preceded by a dash within a within a generic definition that's a that's basically a lifetime constraint. And so it's about being able to put lifetimes and within a thing and so you can specify a trait that is like a T that has a lifetime associated with it that's some outside type because that's mostly where like how like within the borrowing system. That's kind of where lifetimes appear within type annotations is so you can say the type that I'm creating it's going to carry it's going to contain this other thing and I'm going to guarantee that my type lives as long at least as long as this thing does and you kind of you're giving the compiler that information. And so that's a lot of like what it's going to be used for but I mean yeah you wouldn't write a function that way you basically would write a trait. They would have that GT specification and then it's going to have methods on specified on it that do those things and then a concrete type comes along and implements that and kind of fills it fills the rest out, although it might still be generic for its T right so you know because that's the higher kindness of it. Until it's actually applied at runtime until it's applied by a consumer, you know who actually fills out the inner the inner type. Yeah I guess so that that gets into question so this is the end. If I had any recommendations it would be to check out the rustling.org website. It's incredibly incredibly robust and a great gateway. If you want to actually interact with the community the first place I would recommend going and maybe this is a generational thing I don't know but I would recommend going to the discord. There's a huge community there there's like, like it's like it's like a like a mass like an IRC network level, you know, in terms of how many people are there and active. And, you know, a lot of the, a lot of the core team are there and you know, I don't know if actual development work happens there I believe that the rust organization itself maintains a separate chat system off of discord I forget the name. But there's a lot of a lot of stuff there and that's a great entryway there's of course there's a Reddit community that's really active. You know if you spend any time on Stack Overflow there's a lot of rust activity there, a very popular language on Stack Overflow. And so there's a lot of opportunities of course to interact and get involved with the community. There's also a Slack that's fairly active. Oh really. Yeah, I see. I want to ask a quick question. So one of the things I really like the trait system and rust but I also was intrigued by the macro system. And like it seems like there's a lot of macros that help with quality of life in encoding like the back macro and the the print macro. Like, are there a lot of people writing macros these days or do people sort of just, you know, use old macros that that exists. Now there's a lot of I mean like most so diesel, which is a ORM library makes pervasive use of macros kind of for specifying like ORM models, and then basically, you know, based on like how you specify within the macro it's out all the trade implementations and the actual, you know, underlying structures, and then you know by convention how to utilize it. Surday, which is kind of the major de facto serialization framework makes use of macros. And so macros and rust is kind of a tricky thing because there's multiple things that are called macros. Like there's things that look like attribute annotations that are actually macros. And then there's actual like inline code macros like where you do where you're basically doing like hygienic code substitution. So the exclamation point. Yeah, exactly. So that's kind of what I was thinking about. And I think like hygienic code substitution. It actually gets you a long way to get DSLs. Yeah, implementing higher kind of types as well. Like just, you know, you can do a lot of sort of interesting parameters and functions on, especially like with the VEC macro, right? You don't have to specify the link, the array to create a to VEC in your code. Yeah, it's, it's, it seemed like something that was really kind of a neat feature, but Yeah, I don't know if the macro on your own. What's that also challenging to write on your own. Yeah. Yeah, no, I mean, it's, yeah, that's, I mean, it's easier than machine code. I'll say that. Oh yeah. Well, I mean the macros, not the rust, rust is, rust is nice. I guess that was it. I was just kind of curious what the status was on macros these days. I mean, they're, they're available at my hygienic macros in the main language you can, you know, they're in stable rust. So I'm a little disappointed Paul McWhorter didn't show up today. He's, he's a mostly does CNC plus plus development for like video streaming type. So, yeah, I was, I was really hoping to show up just just for the questions. Yeah, that's a sweet spot that you know, rest is there for and I mean it's you know, I think the proof is in the pudding with you know the folks that are using and I think that if you follow or if you saw what Mozilla was doing with you know they're kind of experimental browser project. They're doing some really interesting stuff and kind of, you know, just be experimenting with different layout engines, because you know, I mean, HTML HTML display is a hard problem it turns out to companies that maintain browsers put a lot of effort into making them fast so it's a major you know kind of desktop optimization problem. So, I found myself thinking through your whole presentation about the talking head song what's in a lifetime. You know, you may find yourself. Right. It's like, I don't see rust as something I do, like in my neural day to day stuff. I found myself, like, doing an embedded IOT sort of thing or you know, there's, it has these like use cases that are beyond things that I would use by normal languages, which is like F sharp or C sharp or whatever right. Yeah. There are clearly things where this would be interesting. And it has the things that I find necessary. Like, I want discriminated unions. I want record types. I want to be able to do things in a reasonable fashion. Like, I'm not really crazy about the city columns and brackets sort of thing, but you know, I can deal with that. Yeah. Yeah, I mean I would, I would, I guess the goal of the rust compiler is to not have you go where is my beautiful wife this isn't my this isn't my beautiful house. Nobody's nobody's going to come out there and free it from under you, you know, that's that's the goal. So that is how it is. Rust is like a talking head song for sure. I just watched that video the other day too. I kind of want to just stop the recording now. That's perfect. So I want to ask a question that is is probably totally unfair about sort of like the longevity stability and future of rust and the idea that I have here is so the sequel light and tickle conference was today. The creator of sequel light gave a keynote, basically on the state of sequel light. And one of the things that he was talking about is that one he's, there's a sort of interest, not just from people but also from apparently companies in like, would you rewrite sequel light and rust. And he's like, I don't know about that. But he also has the sense that like within the next 1020 years contracts are going to be like your software has to be memory safe. It just has to be and that through contracts see is just not going to be acceptable anymore. And so he was sort of putting it out there to the conference of like, what do you think about this and what do you like rust is the obvious choice right now today of like trying to occupy this sea area, but being memory safe. And, and you have a sequel and tickle people and they're like, well, you know, it hasn't been around for 30 years so we don't know. And it's worth mentioning that like, I believe sequel light is written in and cc and is very portable. So like there's a certain perspective and also like a major historical inertia to that code base also it's like, isn't it like the zealib license like it has like, I know it doesn't have like a typical open source license. He talked about that. No, it wasn't he didn't talk about it was another presentation. It apparently has a blessing license, which is use this for whatever you wish with our blessing. Like, but yeah, it's anyone can use it for basically anything. There's like, maybe 10 or 20 people I would trust with see. And he's one of them, right. And I think that the point about like, yeah, at some point see is not going to be acceptable. Like, we're going to have to do the stuff that we didn't see in some other language. Because I don't trust very many people. I mean, most shops that are doing they're already beyond that though and they're on to like C++ with like static analysis suites like a lot of places that are, you know, doing industrial C++. And also, you know, I mean, there's no C++ defenders here, you know, so we can we can kick them while they're down. But um, you know, see the C language itself has come a long ways. We're still being recorded. If you want me to stop the recording. No, I mean, I would say the C language itself and I think that you know they really are trying to iterate on it to make it more durable but I mean that might just be about the longevity of existing code bases. But if you ask a lot of really experienced C++ people, they really they're they're like big mad about Russ because a lot of it is you know the way that the compiler, you know ties their hands and kind of discourages certain approaches. So I think that it'll be a while, and that you know a certain generation will just have to move on, but that a new generation who would normally turn to see and this is already happening I mean you know AWS you know they're, you know, in the process basically of, you know, standing up like you can see it with firecracker if you're familiar with that. Kind of like, you know, an alternative, like thinner leaner, you know, virtualization infrastructure running on something less than a full operating system, but still a fully virtualized machine. You know, they're, when they're starting for those, you know, basically new architectures from the ground up the language that you know organizations are turning to again and again and again for high throughput critical, you know you stuff is always going to be it seemed to be rust. That's why I mentioned it back on the previous slide, when you know during the pandemic, you know Mozilla laid off a quarter of their workforce, and including most of the rust team. You know they went and they formed a foundation, and the you know founding members who was it it was Amazon it was Google it was Microsoft, you know and since then a whole bunch of other companies are joined because I mean the value proposition is out there. And you know right now that value proposition is basically like large distributed consensus systems, you know things that are, you know way past C 10k stuff like that, you know, I mean there's a niche for it. I was going to just jump in that you brought up something I actually work with a couple of C++ developers in sort of the CAD side of things of my company. And man, I would love it if they could use rust. And do you know if rust is trying to move into like the sort of the CAD market or, you know, sort of the media algebra processing kind of visual. I mean the math libraries are all there in terms of like there's nothing like, I forget the name of the one big Fortran library there's nothing that good but that being said rust can directly consume those because rust can rust has a clean CFFI. You know, you can you can consume all of those big CMath libraries if you need to. But also everyone does. Python and see and everything. Yeah, there's a five to four trade people. Yeah, really quick I was going to say though Chris is that if what you're doing is building, if you have to in order to extend your for your CAD practice to extend it. If you ship C++ libraries basically or you know C++ bins, then what there is is there is a library project within rust within the rest community called CXX all caps. And what, and what CXX is because what rust provides is the C ABI and CFFI and so they have a library, there's an official or not an official but a pretty blessed library. That's the C++ side because you know like C++ itself doesn't have a stable ABI at the, at the platform level so like you know it's all down to individual implementations. And so they do most of the work for that so I believe that if you know it is you know if you wanted to say hey if you guys you know wanted to use rust to ship these kinds of libraries, you know to put, put a shim around it so it could be invoked and consumed by the C++ program. I think that the path is there, but of course you know most of your hurdles to that are going to be bureaucratic and institutional. Yeah and personnel, I mean, you know they know C++ they're not going to, but I would, I mean, I feel so much better if, if they could use, they could use rust. That's, that's me. I love the language I think it's a great language so thumbs up. You touched a little bit on rust in the JavaScript space, as far as the back end stuff. Do you see a future in the front end, like the WSL. Yes. I forgot to mention I actually had a note but I blew past it to talk about rust and wasm. So, you know, there is, there is you know really pretty good tooling both LLVM has a wasm target, and then also rust has an experimental called crane lift that was actually written as an extension to trace monkey which is kind of like you know Mozilla's most recent iteration of their JavaScript engine what's called script monkey. And so, crane lift is kind of meant to be like a modular extension to that which they're using to do all of their wasm interpretation. And so incidentally what they also have is like you know in the process of building a thing that can do like live JIT of that is you basically get a machine code interpreter in wasm format. So there's a you can basically run rust C and then have it spit out wasm and that's there. And there's you know there's pretty good shims and tooling there like people are able to you know do like 3D games and various platforms and then ship them on the on the client and stuff like that. And that's that's another really strong space for it of course you know because that's, I mean what wasm is making possible is basically to have, you know, really tight compilers without GC to spit out you know interpreted code that can just run, you know, and so so it'll it'll definitely have a space there for you know high performance front end applications. And then the back end as well. I was recently listening to an interview with Martin Klepman, the guy who's writing the auto merge, and one of the things we're talking about doing is rewriting auto merge in rust. So because it's got that wasm back end. Yeah, that makes.