Before I get started here, I wanted to write a bit about why the blog post for this month is late. First of all, I did not really feel like I had any good material to write about. I haven’t really make any progress with mini-rando recently, and have actually been working on a new game starring a cactus, tentatively titled Stay Sharp!. I never felt like I had good direction with mini-rando as a game, especially since I still didn’t even have a proper title or setting for the game. I want to come back to it at some point, but I don’t know if I’ll be starting over with it or just using parts of it for another game. Next month, I’ll write a bit more about Stay Sharp! and the future of mini-rando, but I think that’s a bit too much to write about here. Secondly, I have been spending a lot of time just reading and trying to improve my understanding about Rust and other various programming related things, like Unicode. As a result, I haven’t really found a lot of time to devote to personal projects as a whole, but I’m hoping that will change soon. Lastly, I signed up for the Rust Essentials workshop that was part of LambdaConf 2019, which I wanted to write about here. This workshop didn’t run until just last weekend and I work a full-time job, so today is the first breather day where I actually have the time to write about it.
About My Rust Background
If you only care about the workshop, you can skip to the next section.
I guess I haven’t written or spoken much about my Rust experience, but I’ve actually been using the language on and off for the last 4 or 5 years, since approximately 1 year after the language had stabilized. I’ve witnessed many of the changes that the language and its community have gone through as well as the evolution of the Amethyst project since its humble beginnings when it had less than 100 stars on GitHub (it’s at over 3000 as of this writing, by the way). I first learned about the language at a talk from Mozilla way back in 2014/2015 (I can’t even remember), but never really looked into it, since the speaker mentioned that the language was horribly unstable at the time. I only picked up the language much later when I was looking for good alternatives to Scala for game development, because the Scala ecosystem didn’t really seem to have many gamedev libraries at the time. I figure there was an expectation that you just didn’t use Scala for gamedev or you took advantage of its Java interop to use Java gamedev libraries instead. Either way, I remembered hearing about Rust and started learning it, expecting it to become a nice secondary language to use while I primarily worked with Scala. For a time, that was indeed the case. However, as I learned more about the language, I really started to appreciate the amount of thought that went into the design of the language. For context, I have worked professionally with Scala developers who just abused language features, such as null, which is only supposed to exist for Java interop. I felt like they were almost entirely defeating the purpose of using the language. Rust’s usage of the Option type for representing optional values just made so much more sense to me. For the record, I haven’t run into a single seg fault in all my days using Rust, but ran into plenty of NullPointerExceptions during the time I spent writing Scala professionally. One might argue that this is more of a problem of coworkers not exercising proper discipline, but I don’t like blaming people for problems that a better designed programming language could have solved and so I can’t help but at least partially blame Scala for making null a little too easy to reach for. Also, Rust doesn’t have implicits, which I have always disliked, although I have heard that Scala is going to improve them soon when Dotty eventually rolls out. Needless to say, with its the zero-cost abstractions and memory safety guarantees, Rust has quickly became my most used programming language for all of my personal projects.
By the way, before I move on here, I would like to say that I don’t hate Scala. To me, it is still quite far ahead of its time (I’m looking at you C#) and I still like to use Scala for demonstration purposes and quick prototyping. It is still one of my favourite programming languages even now, and I’m excited to see where it goes when Scala 3 rolls out.
What I Learned at the Workshop
Now for the interesting stuff! What did I learn from this workshop? Well, I already have a fair amount of experience with Rust, as previously noted, but the extent of my research has only ever been reading TRPL, parts of the Nomicon, Rust blog posts, and browsing the Rust subreddit. The instructor of the workshop, Chris Allen, works professionally with Rust, so I felt that this would be a good way to measure how my approach to Rust development differs from that of professionals. For most of the basic concepts, like borrowing and ownership, I felt like I had a pretty easy time following along. I learned that most Rust developers will try to avoid defining data types that contain references, since the extra complication of having a lifetime specifier outweighs the minuscule performance benefits. As it is often said, premature optimization is bad. I do believe I have defined a few newtype wrappers for string slices, so this is something I will need to consider changing or removing next time I work on my personal projects. The workshop also gave me a better understanding of the differences between &str and String. This taught me more about how the Deref trait works, as well as proper usage of the trait. Up until now, I have avoided using Deref since it is easy to misuse and often considered an anti-pattern when implemented for anything other than smart pointers, so this is good knowledge to have. From what I know now, it is useful for “downcasting” certain types to other, closely related types, such as converting &String to &str. For example, Deref allows the following code to work:
fn foo(s: &str) {
println!("{}", s);
}
fn main() {
let bruh: String = String::from("cat");
foo(&bruh);
}Instead of passing &bruh as a &String to foo, which will not typecheck, the Deref implementation automatically converts &bruh into a &str, which is then passed to foo. I also learned a lot about closures and function pointers at this workshop. Those who have followed my struggles with removing that one Box in mini-rando know how tricky closures and function pointers can be to work with in Rust. Chris taught me that viewing closures as structs (which is what they are under the hood, by the way) is a very easy way to figure out how they will react with respect to borrowing or capturing their environment. For example, like a struct, if a closure has ’static lifetime, it will not be able to borrow its environment at all and will have to be a move closure instead. This is analogous to a struct having lifetime ’static and having references for fields. The struct would outlive any reference that doesn’t also have lifetime ’static, and thus we would have dangling references. As the last topic of the workshop, we also learned about the Tokio framework. I had never worked with Tokio futures before, so I found this part of the workshop to be very useful and learned a bit about the current async I/O situation in Rust. There has been much buzz about async/await syntax coming to Rust and talk about how Rust lacks good support for asynchronous I/O. It seems that a number of people do not like Tokio, likely because of a lack of HKTs and monad comprehensions in Rust, which makes Tokio futures somewhat difficult to use ergonomically. That combined with Rust’s general lack of expressive power due to its borrowing and ownership system makes async/await seem like a much more appealing option. Since I don’t really get to work with async I/O that often, I’m not particularly invested in either side of this, but it is certainly interesting to see how things will unfold from here. As far as I can tell, a fair number of people still like Tokio as is, since it is still a framework and provides more utilities than async/await does on its own.
Closing Thoughts
Overall, I feel that what I learned from this workshop will help me with my Rust projects a fair bit. It taught me how to recognize a bunch of anti-patterns in the Rust code that I write and taught me how to have an easier time battling with closures and function pointers. In addition, should I ever play around more with async I/O in the future (pun entirely intended), I now know how to work with Tokio and at least have a better idea of what to look out for when the new async/await syntax arrives. With other languages like Ada/SPARK and Haskell picking up linear/affine types, I feel like this knowledge may some day serve me well even in other languages.