Hi everyone, my name is Patrick Akil and for today we have two major topics. 1 is Rust and one is game development and I love game development talk. But first about Rust. Everyone I know that likes Rust really, really loves Rust, and we'll get into why that is exactly why learning Rust might make you a better soft engineer or might help you land a job
earlier and faster. Joining me today is Stefan Diri, Rust consultant and Rust Engineer, and we talk about his passion for both Rust and the game development industry and why we cannot combine both Rust and gaming yet professionally. Has a lot to do with the gaming industry, has a lot to do with gaming engines. And he's seen the insurance and outs of it. So enjoy everyone I talk to and also I listen to or I see media online talking about Rust. People that like Rust really love Rust.
Like it's a thing. And then everyone that tries it either stops because they say it's too complex or the compiler just keeps screaming at me and I have to offer my child basically to get it to run. And then that's where it ends. Or people actually go through that hump and then they fall in love with it. I haven't seen a lot of middle ground there is that I love or haven't gotten around to it.
Yet polarizing, yeah. Which by the by the way, reminds me of AI. Had a conversation with a guy that just runs a company that their main software is written in Rust. And that exact factor is probably why he went over the prototyping phase with Rust because he said it makes it super easy for him to hire for
like his engineers. Because if you can prove that you can do Rust and that is, you know, you have open source projects or you pass a certain test they have, then it's like the easiest like like hiring test to make sure that someone's
actually capable. Because they must have crossed that boundary that you just described this super like steep learning curve in the beginning that that people, a lot of people perceive in in Rust. I would come back to that later because I believe it's also a kind of a myth because I think in in it's a, it's a way how it's taught that it's probably a lot of people making it harder for themselves to learn Rust.
But I think if you go back in time, especially when Rust was not as advanced and in terms of making it simple for people, there was definitely more hurdles back then to to learn it. And yeah, and then I totally understand why some people were just too frustrated because obviously if, if, if the compiler is not accepting what you're trying to do, it makes you feel like you're not
productive, right? The fun thing is as soon as you've passed that, it makes you actually feel the exact opposite because it feels like you always have this imaginary like peer programmer next to you that's helping you to be even more productive than you thought in, in the past that you've been. Because it's it, it sort of reduces or it, it, it switches the balance of the, the, the time you invest into fixing like runtime exceptions and crashes and what not later.
And, and like when it's pushed to, let's say staging or even production to upfront loaded and have to, as a developer, you have to focus on these problems that might arise later during the first sort of like phase to get it to even compile. So this whole mantra that when it, when it compiles, it runs in Rust. That's sort of this front loading of all the shit that you can ignore in other languages. Like, yeah, that might crash at some point. But you know, who knows, maybe it never happens.
And, and we deal with it when it comes right. And in, in Rust's case, it really makes, it forces you to do all your error handling explicitly as soon as possible. Yes, there's a way to go around that. If you, you know, that's, that's another area that I think is overlooked that Rust can be very prototypey. If you, if you know how to use it, you can still ignore all these things. You can still say, OK, I don't give a shit. Just ignore that until later.
And then yeah, it might crash. So you can have crashes like that in Rust too. But yeah, I think it's hard to navigate that in the beginning when you learn the language. There's because there's so many different ways for people how how they apply Rus. Some people are using it in this perfectly safe, 100% no, you know, potential crashes, like stuff that is explicitly ignored.
And then it's obviously very like intimidating, maybe in the beginning how much you have to take care of until you get something to run. Yeah, in, in essence, when I started out, like my career didn't start out with software engineering, I didn't have a traditional software engineering background. I did more data science stuff, saw the Python, and then I started in operations and I grew towards the software engineering role. And in there, maybe it's because of the type of person I am.
I just wanted to be effective, right? We get something, it's very tangible. I can create it, it runs, does the job, that's it. But I've also worked with engineers that I call them more of the like scientists side. They love trying out a new language, picking up something, doing an advent of code in a different language, and then figuring out what is eloquent, which is like very subjective, I think, but then still very opinionated for some reason, of course.
And I'm not that I feel like I want to be effective in what I'm doing. Something like Rust. I do like compile time checks, like being safe with regards to what I've written and then the safety of it running because it compiled. That sounds awesome to me. But then I tried it and I did just didn't, didn't get over that hump. I also like Go. It's very simplistic. It definitely still gives you compile time checks, but also gives you runtime exceptions and
errors and all that. And people say, OK, Rust is like the sweet spot where you can get that. So I feel like I should try it out more and get to that point. For some reason people just love. You can always give it another. Try. I will, yeah. I feel like I will feel like
you're inspiring. Yeah, I mean, we can, we can definitely sit together there because I I believe like if, if, if it's that personality that you describe, there's certainly I think a different way that I would approach learning Ross, than maybe a more perfectionistic scientific kind of engineer that you described that I would say would love the fact that it takes forever until they get it to work, but then they believe it's perfectly working afterwards.
In your case, I would optimize for this. Let's let's prototype first, let's get something to work. And then you still have in my opinion, because you could say, well, if you do it like this and it crashes all over the place, then why would I use it in the first place?
The, the big advantage is then still that you can just work yourself through that, you know, but when this prototype becomes production, you can just work yourself through all of these technical debt areas that are very explicit in Rust because you have to basically say tell the compiler, yeah, I know this might crash, I don't care right now. And so these places are very explicit to clean up afterwards because. You have them.
That's nice. Yeah, exactly, because you can just basically search for unwraps and panics and stuff like that. That's how it's called in Rust. And that makes it kind of a, like you said, a a great sweet spot if you know how to use both sides, because then you can always make it very stable, very secure in terms of this will never crash. But you could also be quick in
just prototyping something. Yeah, I mean, people that go through, let's say, a boot camp where the promise is within two or three months you're going to get a job. I feel like they they teach you something to get stuff done right, and then your fundamental knowledge might be lacking. That's what I had in the beginning. I was like super effective. And then I figured some stuff that I'm doing and I would also realize this in pair programming, like other people just know like off the top of
their head. And for me, I would have to be like, OK, how is this? Or if I would have to do something big, I would either get like analysis paralysis. I wouldn't really be able to figure it out where I would have to go like a few directions before actually funneling it down. I felt like first experience is always experience. Like the the more you do that, the better you get at it. But also I felt like my fundamental knowledge was lacking.
I feel like when you're very explicit, when you're saying you're either prototyping in Russ or doing doing it the idiomatic way without any exceptions and being explicit and you're ignores, I feel like your fundamental knowledge should be there. Or at least if for you to be able to be effective, your fundamental knowledge will be there, which is a nice benefit. That's a that's a good point,
yeah. But even before my whole Rus journey started, I had that exact same experience with people that when I came from my C++ background and did Java and, and, and C#, it was natural for me to think in, in terms of how is memory laid out, how is memory accessed? How is what's efficient and how maybe just chasing pointers through a linked list in Java is maybe not as efficient as a, just a consecutive array in, in C++, right?
And then you, you immediately start feeling like you're like your hands are tied in these languages where it's almost impossible to actually do it in this efficient way. Right. And then, and then one of the typical interview questions that we had as as soon as we expected someone to have a certain foundational knowledge when hiring, even for C# or Java was like, OK, explain the difference
between a heap and a stack. And you would be surprised how many people come like years into their career. Totally fine not knowing the actual difference there. Yeah, yeah, yeah. In the end, if they have to be effective without actually knowing that, if they've never worked in a in a space where efficiency really matters, like people talk about it, but in like 95% of software, it doesn't
really matter. Or it's like solved in the background in some sort of way where people actually hands on, don't have to think about it. Then I can definitely see that it just grows like that, I think. Yeah, no, I understand. I mean, that's, that's, that's humanity, right? If you can't find a way, even if it's super dirty and and not nice and cutting shortcuts will people will do it. Yeah, yeah. And then we have, we have this whole abundance of, of
processing power, right? You don't in a lot of cases you don't have to care. But I started in, in programming while you really had to care. Like I was starting to program on like 386 machines and stuff like that. So there's not as much resources to deal with there in the 1st place. So running a garbage collector on those kind of machines would have been unthinkable back then. So it's kind of funny to see how this progresses, right?
And now you can do more on your, I don't know, watch than you could have done on this whole computer back. It's insane. We have. So much compute power, like locally. It's incredible. Yeah, yeah. When you were describing kind of your your journey with the language DE like I, you told me also before the show and I'd never heard about that. And then it got me thinking, especially with AI now, AI is very good in generating code
with a lot of code examples. That's why we see it's very good in Python, it's very good in JavaScript, TypeScript, it's probably lesser good in Go, It's probably also lesser good in Rust because those are like newer languages. I wonder if because of people being very productive with AI generated code, if there's ever going to be a new language because new languages will have to play catch up. Basically everything is accelerating.
People are more productive. Why would I switch to another language that's going to solve a specific problem without all my tooling around it? I feel like there's a gate with regards to accepted languages and Rust might be one of the last ones to be honest. Yeah, strangely. Oh, that's a depressing way to think about it. Yeah, you kind of have a point there. I mean, I didn't look at it like that, but yeah, it's definitely
a new language. Would have to bring so much value in a different way that it justifies an AI not being able to be such a supporting hand from the get go. Or we make AI even better, right? That they can be more effective with less resources.
Maybe an AI can be a good Rus programmer as soon as we have like a formalized standard of the language to define it and the AI can just pick that up and it doesn't need all the real world examples out there and it can transfer knowledge from similar languages like C++ over to it, right? Ultimately, in the end, there's really little languages out there that have no no peer. That is a similar kind of
concept, right? Even on the functional side, you have multiple languages that that that are fundamentally similar, although syntactically very different. And so I think there might still be a shot for these kind of languages if the if the AI also gets better in terms of transferring knowledge from one language to another. Interesting. Yeah, for me there is.
Like if we're looking at I, I looked at a few indexes with regards to language adoption and because of your ability to generate code, those languages also have more usage because there is just more of that specific language out there, which I thought was interesting, but Russ is definitely still high. How is generating code with Russ so far? Have you been? Have you played around with it? I mean, I have the regular copilot on and see what it's suggests.
But to be fair, I have not a good comparison with, with other languages cause since AI is a thing, I basically am doing almost full time Rust. So I, I really struggled to see. Well, actually I think the, the other use case that I used AIA lot is in, in like, in like scripting, Kubernetes configurations and stuff like that. And I definitely feel it's stronger on that side, which makes sense. There's probably way more out
there for that. And on the Russ side, it's, it's fine in a lot of cases, but it's also horribly dumb in a lot of other cases. So yeah, if it's like simple, OK, I just don't have to type this whole thing now, then then it's often all right. But yeah, it's, it also always feels like definitely suffering from the lag in terms of the training window or whatever it's called for the AIS to.
Because then then you have this new feature that you know that this is just not how you do it in idiomatic Rust anymore. But it still lives in the time from like 3 months ago where? Yeah. I, I want to jump into your experience that has been kind of hands off because for me and especially this has been kind of rampant in my head. I work at a consultancy. I got the opportunity to do product management, which was always something I wanted to do.
So I did that, but now I feel like since I've been hands off or it's been a year, maybe year and a quarter, things are accelerating on the development front. I talked to a lot of people that are in start up environments. They say with the three of us, I feel like we're effective as like a whole team of 10 and like, man, I feel like I'm missing out. You're now hands on, but I also know you have engineering management experience.
Do you see yourself kind of going back to engineering management at some point, or are you loving what you're doing now? No, I am always going back and forth. I've done my first engineering management, leadership sort of role in 20-15 around that time. And what I noticed about myself is just how I started learning to program when I was 12 before it ever became a career.
I also couldn't stop doing it in my spare time because it became a hobby for me. Even when I like my day job was an engineering management and I grew teams to like 70 people. There was no time at all in the official like job hours to, to program anything, let alone not, not even like proper doing proper code reviewing anymore. And I was, I, I noticed how I would have really suffered if I wouldn't have had time at, at during that period to also work on my side projects.
Like I have this open source git terminal UIA client project that I, that I'm already on for like 6 years now. And I felt like this was a really good way to vent after work to really focus on something totally different. Forget about all the interpersonal communication issues that are basically 90% of of the job and then coming back to a compiler that is like completely catered for my OCD. It's like right or wrong, that's it Black and white, that's it.
Yeah, yeah. So I think I'm, I'm always flip flopping and I will probably keep doing it like that. I I think I couldn't work in like position where I know OK this is it and I will never be able to to write any any line of code anymore ever. Yeah. So for me, side projects are not something I I've picked up. It's something lately that I'm thinking, OK, I have the ability to be more productive and I have a hard time starting.
So maybe we can just get help, find people that are enthusiastic about something and start starting and get better at starting. Because when something's already going, I'm really good at keeping it going. Like a podcast, like this is basically the example of it. But starting has always been difficult for me. That's why I don't really have many side projects or projects
at all. Like it's when I get time out of my day today and it's kind of force, like CBS, an environment just gives you a day, says play around with something. And then I'm like, OK, if I have a day, then I do something. Yeah, that makes sense. But then otherwise, in my own time, it's like I just don't get to it usually. But I feel like it's giving you a lot of value.
Oh, yeah. For me personally, to be honest, I probably could have not started my own consultancy and have a have a network to actually find enough work to do over over years and years, if I wouldn't have engaged myself in all kinds of side projects that's in some shape or form became visible at some point, either because I open sourced them or I talked about them, presented about them at at
conferences. And I think, yeah, like this is, this is for me, it was a was a great way for me personally to keep learning and to, to keep growing and to keep in touch with development even when I was for for a few years on a, a very busy management role. But I can totally see like a lot of people don't do it right. They don't have side projects. It's just not a thing for them because they have other hobbies. And that's I think the key for me, like this thing is actually
been my hobby my whole life. So if I, if I for a lot of people, it's look super weird then like, oh, I thought you're off work. Yeah, but I'm not on work now. Right. But it looks the same. Yeah, well, that's not my problem. You know, yeah, yeah, I love that. Like I think if you can find joy in what you do day-to-day, like that's a perfect match. And then for you, if it's like a side project, how how did you figure out what to create a side
project for anyways? Would it be like a small problem that solves your itch or a scratch itch somewhere, or? Yeah, that's actually what I thought when you mentioned it's hard for you to start. I think my suggestion would be figure out something that that you feel like is is missing out there while you work on something totally different. And you think, why did no one do this? Then you start looking like is, is there maybe something
similar? In my case, it was really literally I was working with giant Git repositories and I was using regular UI clients for that in the past, so I don't know what it was. Source tree. Oh yeah, I know that one. Yeah. Fork nowadays. Yeah, Fork has been actually a pretty good one. Inspirational as well, but the point was that almost none of them was capable of opening
these huge repositories. They were usually cut off after like a few 1000 commits and then do some lazy loading if you actually wanted to look into the exact like the entire history. But the problem then was that they usually completely exploded in terms of memory consumption. Like you couldn't even open like the Linux kernel repository and search for for a for a string in like the first commit in the history.
It would take forever. It would like grow a balloon into like gigabytes of memory consumption and then start to try or try to run that on the repository that you check out on the remote server, right? So there were a bunch of specifics that came together for me. And then I looked for alternatives and the biggest one was lazy Git written in Go lots of features. But what I didn't like about it was like, it was it, it really felt like you had to have a PhD to understand their UI.
So for me, it didn't really combine this, this, this ergonomics of AUI client that I used before with this whole low memory footprint and, and efficient like analysing or whatever of the, of the big repositories. And so at that point I thought, hey, I just started learning Rust. It seems like the perfect use
case to apply Rust, right? And then, but yeah, and then I, I basically decided at that point, OK, it needs to be a terminal based UI so that I don't even have all these issues with like cross-platform UIS on, on Windows, Mac, Linux and what not. So at that point, Gitio, I was born and that's probably the biggest side project that I ever started. But it became a thing because it was itching this one, scratching this one itch that I had myself.
And then people were joining in because they had the same. And then you have this situation that you describe where it becomes like it moves forward anyway. Yeah. And, and my best decision in the in the project's history was to make it a complete like own entity, like it's own organization, making people part of it to be able to give them, to empower them to contribute and really feel like they become a central figure in the in this
process. And then you can face yourself out further and further right if you have other. Obligations or maybe also other interests. And for me, especially because this project is now 6 years old, it's obviously something that I would like to have more people like take more ownership of and and me being able to phase out more and more to not be the single point of failure anymore. Yeah, that makes sense. I feel like nowadays I see companies building in public, but also people building in
public. It's always been the case, but they're now just more vocal about it. Also from a position of there's a lot of software engineers and right now people are looking to cut costs, which means they cut in headcount, which means there is more software engineers looking for jobs that there are. I feel like in general, there's enough to build there. We can build more stuff where we can be more creative with what we build.
Not just build E commerces in all retail organizations, but actually fix a problem that matters maybe even to the society. But in the end, people are looking to distinguish themselves because if a lot of people are applying to the same job, then it's going to be hard to filter out people that look the same.
Basically, figuring out what problem you can solve in an open source project that you can start or contributing to something that is already there, or kind of building in public or talking about what you've learned. I feel like a great ways to distinguish yourself nowadays. For for sure, when I started, there was no GitHub even like there was SourceForge or whatever. And it was, it was so hard to actually like visibly build open
source software back then. And it was limited to a way smaller community in, in, in, in the in, in like in, in all the engineering community. So I think everyone that that asked me how to get a foot in the door in the industry is that's exactly what I'm what I'm telling them. There's has never been as many opportunities to show your skill outside of of like a closed source project at a client or whatever, Maybe to just contribute to open source projects. There's so many cool stuff out
there. You can basically just start looking into your throughout your day. Just check out what kind of terminal applications did you use yourself? And chances are that probably 80% of those are on GitHub somewhere. And you can, if you were ever thinking, oh, why the fuck is it like that? Just go there and fix it because that's exactly what's what gets you gets gets it like visible what you're doing like gives you visibility. That, and that's usually in the beginning of your career, the
hardest thing to get right. It's like this chicken and egg thing. People want you to be cheap, but also experienced and not give you a job until you have experience. Like how do you get that right? So the the the one key thing is to contribute to open source, in my opinion already while you have time to do it like, I don't know, you're studying, then do it already on on the side right do. You think choosing a particular language in kind of open source contributions can give you an
edge then as well? Because you talked about that person that already threw kind of a hiring barrier of entry with regards to Rust, knows if he has a good engineer because they can do it or people just don't apply. I mean, I'm obviously biased, yeah. But I would say it's definitely a thing that companies struggle to find Rust engineers. So I would still, I would like honestly say there is an edge if you if you choose Rust.
The second reason why I would say that is that I personally think it's it forces you to look into some of those fundamentals that you described that maybe would come up rather later otherwise, which would give you an edge again in in the hiring process where you might understand fundamentals better than someone that didn't have to worry about those things in in in their career, even though they might be working with Java already for for five more years than you.
And on the other hand, I would still want to try to be unbiased and say, ultimately, I think the only thing that really is important is that you pick a project that really that you're really passionate for, something that you can actually drag your butt up for after university or after work to actually do something on the side for it, right. And that doesn't work with anything that feels like another
job. It needs to be something you really burn for something that you think this is, this is something I need for myself. And or it became a thing like I've, I, I know people that basically built this side project game for themselves. And then at some point people were just hopping on it and, and asking them on discord, Hey, can I pay you something to get this thing? And then it became a business out of nowhere. Right. You could never know.
Yeah, I love that. I mean, you and I spoke before the show and asked what what is your passion? And you said there's two things. There's Rust and there's game development. I always wanted to be a game developer, but it's because I grew up with video games. It's just that was my single, I think, the hobby that I spent the most time on. Now, the only thing that might compare is like anime consumption in like watch hours. But gaming has always been a big thing.
In the end, I couldn't do it because I didn't have the right education. And then I needed to like gain another three or four years of education in one year. And I just didn't. I didn't make it. And I was like, OK, I'm just going to do this thing because it also looks interesting. And maybe in a roundabout way, I go to the gaming industry now. I've heard a lot about the gaming industry. Everything is like surface level. But I am very curious to hear
your opinion. I was wondering because you started off this conversation with Rust in game development, at least the prior conversation we had, why can those two not be combined? I mean, as a matter of fact, they can be combined. I'm working on games in Rust. There's people that released games in Rust. I just think it's, it's an adapt adaption delay that is happening. It takes very long to build
engines. If you know, if we, if we look at how the majority of games are made, it's mostly done in these like huge proprietary engines like Unity and Unreal, which gives you like this big toolbox so that the actual development of a game idea that you have or, or the implementation of that is becoming like as simple as possible. Because if you're, if you're not the scientific programmer, you just want to get a product done right.
You have this vision for a game you wanted to implement and the, I would say the the majority of games that become successful start like that and and then you grab a toolbox that's just there 'cause you don't want to worry about the toolbox. Now in Rust, there's the saying that there's more engines in Rust than there are games. Of course, the I think that has
two reasons. One is there's really a fundamentally different way how you have to approach game development in Rust. And the second thing is Rust naturally attracts the scientific programmer, the perfectionist, the ones that want the language to shout at them to make it right. They don't want to do this unwrap, panic, shortcut, whatever, don't care about it later kind of solution. So it's it, it, that's why it also has this reputation of this over perfectionism.
And, and I think that doesn't help, especially in the game development space, because there you want to prototype quickly because the I, I, I've most of my career worked in mobile games and browser games. So it's not, it's probably a little bit different in AAA kind of console games. Even even then, nowadays you have a release in like a day one patch and then a week 1 patch, so definitely it's still speed that matters I feel. Yeah, for sure.
Anyway, so the, the, the, the, the, the browser space and has, has, I would say even more demand on quick prototyping cycles. You want to try like, I don't know, 10 different ideas because statistically maybe 0.5 of those will actually become successful. So you want to spend as little time as possible to, to get the idea tested. And so like I said, another case where Rust on the surface level
doesn't really shine. Like everyone has this thought Rust is not good in, in quick prototyping, right? So that's one reason. And the other one, like I said, is there's a lot of fundamental technology that you have to be have to build 1st to get to, to, to be able to write a game in Rust. So either you write that yourself or you use one of those, like I said, many engines out there that that I wouldn't even call engines these days. It's more like frameworks that that help you get off the
ground. Like you don't want to talk to the Vulcan API yourself. You want to have some layer in between that makes it easier for you to just load a model and then put it on screen, right? And open windows on like different platforms because they are all their own little special snowflakes. If you, if you to want to create a window, right. And, and ultimately it's a big competition to get to compare yourself to. If I really want to build this game now, do I just use this
thing that gives me all of that? Yeah. It's not maybe 100% as safe or fast as it could be. But for that's the other thing. For 90% of those games, it also doesn't matter because, again, you know, you might not care that you just burn more fossil fuels than you need to, but the game is done. Yeah. And so I totally understand why it takes very long to adapt.
It's such a fundamentally different technology if in in game development because you can not really use that in combination with the existing stuff. You really have to bet on one of those engines, like in my case, Bevy that is slowly but surely moving towards to such a feature parity maybe at some point with with these big established
engines. And then there's there's there's another problem that it's not easy to just roll out a game that you, you know, if you think about a game now and you want to build it in Rust, there there's this other big problem on the horizon that you need to be transparent about or that we need to be transparent about. It's not going to be easy to get that on a console because these platforms are even harder to get
this new technology rolled into. We can go into that, but the the fact is there is just no one who's done it before. So whoever is going to do that first has to go through a lot of hassle, not just technical, but also political and like compliancy and and stuff like that and legal. And so that's not a great sell, right for anyone who wants to build their game in Rust. Now, I think personally, the the most realistic scenarios that we will get a game like Tiny Glade.
I think I mentioned that in one of the prior interviews. That just looks gorgeous. That becomes a success that publishers become interested in to actually help trade blaze through through these platforms that are currently hard to develop for with with Rust. And then I hope that this opens the doors for anything written in Rust essentially to eventually be able to to be rolled out there. Yeah, with an Unreal Engine and with what's the other one?
Because there's Unreal and there's Unity, Unity here. How how much hands on programming do I actually do? Or is it more of a matter of you have an application, you go through your windows, you actually click and drag and you do vector speeds and let's say you create a game. There's there's both ways like there's a visual visual scripting solution that's both engines basically support.
So thanks. So you don't really have to write a line of code, but I would argue that a that more than a prototype sized game is probably going to be very hard to maintain in a in a fully visual graph editing kind of way. I actually didn't see it yet. And, but I also haven't used as much Unreal where this whole blueprint graph development process is more established.
And but yeah, as soon as you have a bigger team that needs to be able to contribute together on the same code base, it becomes increasingly hard if you have this visual scripting solution to use that. Yeah, makes sense. But you can like, that's the point, right? And that's the, that's, that's the real beauty of them that you can really quickly prototype something with that, like even without having any real development programming
experience. But you can always just swap that out and and start using C# in Unity's case, C++ in in Unreal's case. Yeah, I know a guy that was building an MMRPG with Unity and C# at a company and I have to get him on because he has many stories about kind of his experience with game development. But I'll connect you to because I think you might share some stories there. In any case, I was wondering with Bevy, you shared that it's open source, which is correct,
right? Yeah, that's Unity and Unreal or not. No OK I mean ish ish Unity for sure is not they have they have their core engine is is closed source. Unreal is open. How do you say that source available? I guess it still is not technically open source because you cannot just fork it and use it for free like the the licensing behind Unreal still requires you to basically pay a a share if you reach a certain amount of success with your
project. Gotcha. In in Unity's case, there's a bunch of turmoil with the whole licensing that they change, but I think ultimately they gravitate towards something similar. But they also still require you to pay for seats for your developers to actually use the engine. I think that didn't change yet, but yeah, I think this is 1 a good example of why I think an open source engine like Bevy is this going to be ultimately long term more successful.
You can look at the big comparison like the, the, the, the big grandfather of open source engines, Godot, who became way more successful in the whole turmoil that Unity, like this self-inflicted wound that Unity did with their licensing changes. I think to your like end of 22 and a lot of people were flooding into the open source space. Like what's the alternative?
Like if I never want to experience this shit anymore, then I need to go to use something that's open source because no one can rock pull that underneath me, right? Unity ultimately didn't do that, but everyone was suddenly realizing they could at any point it could be over and it's never it's to this point it's not open source.
So if they would just shut the doors, it would just stop where it is in time and and no one knows if the editor might even stop, stop running if it couldn't call home anymore from from your machine, right. So I think that's that a lot of people woke up over that worry. And I see that it actually like only really led to action on smaller studios that had the opportunity where it's not like this whole tanker just takes time to really turn around to, to potentially use alternatives.
But certainly in the indie space, a lot of people were like, OK, never going to use that anymore. And they started using Gadot. They also started looking into Bevy as a as an alternative. And I think there is a niche sort of market where I would say, OK, that's, that's a game that you can today effectively do with Bevy. But it's, it's still a very niche kind of project where it's, it doesn't require you to have this nice editor
experience. It's a very data-driven game or very like procedurally generated game. Those kind of games I think really have today already a great way to be developed in in Bevy and Rust. But yeah, the the majority of games out there, you need a proper editor and that's something that will eventually also come. Interesting.
We had a hackathon, I think it was last week, and some colleagues of mine actually played around with Godot trying to figure out what the rendering looks like, how fast we can get something on a meta quest actually rendered and played around with. It was fun. And I didn't know it was because of kind of what people experience with Unity and kind of the the awareness that, oh shit, if our core is this and it's not in our control basically, then we have a huge dependency there.
Yeah. I mean, there's, there's probably, I mean, there was already usage of GDO before, but this was a that was a huge like growth situation that that more people were seriously considering GDO at that point in time. And it was a great timing because Gido just had this big release before they had all these like more modern rendering features that also made it like more feel feel closer to what they, what you could build in terms of really realistic graphics with them.
You could already do like the, the, the the typical 2D games, like the candy crushes of today. You could already do that with Gido years ago, right? But this gave it like that was a great moment in time where Gido caught up in terms of graphics and fidelity and also got more way more attention and publicity because of the the the situation with Unity.
Culture. How does your experience with regards to game development compared to kind of the experience outside of the game development, either web or any of the other experiences you've had? What makes game development so unique in what it does? That's a good question. I think number one goes back to everything we talked about. It's always very efficiency,
like focused. Yeah, there's there's exactly, you always have this, this dreaded 16 millisecond budget where your your update cycle has to be finished. Otherwise it's going to start looking shitty for your user. It's going to be laggy, slow, whatever. So that was always the reason why I thought C++ was good in that, but there was a lot lacking on on the other aspects.
On the, on the other hand, I would say also outside of the, let's say rendering update frequency, hot path specifics of game development, it's also always been an industry that was on the edge of technology. They were, they were always very fast in adopting new solutions. Like I said, this event driven IO back then when node JS came out, that was a the thing for us because we were, we were experiencing these issues with like 10K users connected to our threat based servers back then.
So we were like the first trying to adopt this and we didn't want to use node JS. So we actually used the the underlying lip UV library that node JS uses for that in our C code base. But yeah, I was doing since like 2014, I was doing some consulting outside of games every, every now and then. It was always something that like freaked me out how like old school a lot of stuff is, right? I mean, there's a reason why people are highly paid for writing COBOL. I mean, I could never do this.
But this is something that there is a market for that stuff. And obviously there's different sort of demands. And so for enterprise software, a lot of cases like this look very differently. They don't care if it's modern, right? We can, we can you can use this old stuff as long as long as it runs.
Yeah, exactly. And and in modern like game development, it's it's always a competition with like how could how much nicer could you do it if you were using like all the modern technologies at your disposal, right or new platforms, right. That was also like, aside from all this performance chasing you always had like, OK, now there's no, there's phones, let's develop for that.
Like totally new to constraints and everyone in the industry was like, especially when I joined and and phones came out, everyone's like, wow, this feels like programming in the 80s again, right? Same constraints. We can just apply the same solutions and same again with like variable VR headsets and stuff. Again, very low, like you have to really squeeze a lot of processing into those devices, right? Have a very low like supply of resources again.
So I would say for me personally, this technology advancement that I could always follow with the games industry was, was something that was always attracting me to it. And the other big aspect I would say is passion. I don't think I've ever seen someone being passionate about building an ERP server while in the games industry. For everyone who's working on a product, they are all passionate about it. They love that shit. They come. They come from the story that
you described. I did get video games in my childhood. Right now it's like a dream to be able to build those things yourself. It gives you a whole different type of motivation to actually go to work and work on these things. There's, there's these stories from, from companies like doing this huge amount of crunching. And I've experienced that myself. And it's because a lot of people just do it because they want to. Yeah, there's, there's, of course, there's always black sheep.
There's companies that force that on people. And that's, that's not great. But there's also a lot of situations where you just want that you feel ownership for your product. You want this to be as good as you can and you invest more time than you than you might usually what in in a more 9 to 5 each job. Yeah, that's where you want to be, to be honest, to work on something that you're so passionate about.
Man, I would love to try it. I feel like the way you describe the game industry and also the problems that it needs to solve in efficiencies and speed, like from user experience I've experienced that things are loading. I'm like, man, it's a crappy game. So especially from the creator standpoint, those things matter. I feel like those might be the more interesting problems that we have out there in the industry, right?
Like not all software is written equally, but specifically in this section of an industry, I feel like that's where the complex problems are as well. I mean, to be honest, more game developers should go out there and try to optimise an ERP solution because I mean, imagine what kind of productivity is lost because of those waiting spinners everywhere. Fair enough. But also I feel like I haven't worked in a in an in an organization to which their core
is a game, right? I feel like if you have kind of this fast pacedness of we have a release, we're immediately going to do a day one patch because we know the release is buggy. And then we need to be on top of shit because things we have scientists also in the game that are just going to crawl on walls, which should not be crawlable. So we need to be able to fix that and be on top of things. Like I feel like you need to organize your organization in a way that you can be agile as well.
And the companies that build ERP's, they're more risk oriented, maybe resilience oriented. They don't have to go as fast, as long as they sell and as long as people buy. But there's maybe one thing that we all have in common and that is uptime. And I think that's, that's the reason that's, that's one of those things that I where I see a lot of companies gravitating towards Rust, you know, if we look away from the games industry, but it's the same there, right?
You want, like you said, you want your thing to be stable. Your ERP system can maybe spend 2 minutes loading here, but it needs to run, it needs to be available, it needs to be, it cannot drop messages of, I don't know, something that just arrived in your warehouse and things like that. So I think there is a fundamental like like similarity there when it comes to stability.
I think a lot of systems can benefit from from using a language that allows you to eventually reach a point where you know for sure, like this is like provably not crashing anymore, no way. So maybe your machine runs out of memory. That's maybe something that can happen. But then you have a language at your disposal that makes it easier than ever to really control how much memory you are actually using.
Of course, there's always other constraints as well, but the the things that you have control over, you want to limit as much as possible of the things that the the surprises that can
happen in production, right. So I think there is a future for more Rust in back ends in in like any case, like outside of gaming, inside of gaming, lots of games these days, especially where I came from in the in the Mobile World, but also in AAA, when you, like you said, like the first day one patches, those games are usually they become huge when they're online games where people can interact together. And all of that requires a back end.
And these back ends, they will cost you money if they're down. You cannot have like maintenance windows or you don't want that in best case scenarios. So I think there's a there's a huge realm for rust in back ends in in any case, in regular enterprise and also in in in gaming.
Yeah, awesome. As the last thought, let's say hypothetically I've been inspired in this conversation and I want to try out Rust. Either I have programming experience, or I'm starting from scratch, or I'm early in career, or I'm advanced. Where do I start? Is it contributing to open source? Is it just going through the docks because they're very good? Is it listening to some sources online? Looking at a YouTube video? What would you recommend?
I mean, it's ultimately very personal what, what people learn best with, right. Again, I don't want to impose anything that that doesn't go well with your way of learning. I would say. So pick something out of the bouquet that I have that makes you like easiest to motivate yourself. If it's watching YouTube videos, there's certainly like 2 or 3 candidates out there that streamed or like do stream or have streamed in the in the
past. A lot about very technical Rust like explanations, analysis of code that really helps you follow along, like how do they process that and helps you understand code bases in in written in Rust. But I would say ultimately, if that's something that you can at all like Fathom read, there's the book, there's the book, which is sort of the language reference, but it's also written in such an engaging way like I've not seen in any technical like reference language reference book before.
So what definitely if if reading is your thing, start with that. The second thing is there is this so-called Rustlinks project, which is like like a GitHub repository that you can just fork. And then it contains all these challenges that walk you through the chapters of this book. So you can, if you have, if you have this book, which is also open source, so you can also just read it online.
You, you don't have to like have like it being printed on paper, but it makes it easy for you to also reference back to the book if you are stuck in one of those chapters and in the, in the challenges that this repository has for you. And then you can read up on the details like, why does it work like that? And it goes actually through all the fundamentals of Rus, even like life, explicit lifetime
management and things like that. And after that, I would certainly say if this is something you, you, you feel comfortable with, contribute open to open source or build your own project with it, right? There's nothing better than applying what you try, what you learnt or or read somewhere then. Applying that in a in a real world to codebase. Awesome. All right, thank you so much, man. I'm I'm definitely going to re listen to this and I'll probably
play around. I did research and people were talking about the book and I was like, is that really a thing? And I'm happy you confirmed that's that's definitely a thing. Definitely a thing and it's a great book. Awesome man, I've really enjoyed this conversation. Thank you so much for coming on. Thank you. Thanks for having me. Thank you all. Right, we're going to round it off. Thank you so much for listening.
It's been a while since we've done an episode, so the best way to support the channel and the podcast is to leave a comment, leave a like, let us know what you think and check out Rust because it's interesting. We'll see you in the next one.