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.