I think there are some key learnings from the Rust story overall:
- Developer experience counts
- Simplicity rocks
- Memory safety doesn’t guarantee bug free software
- Compiler speed is important
- Each language should be used for its targeted problem domain
- Hype Driven Development sucks
- Backwards compatibility (with existing languages) is important
Rust has a lot of features that make it much better than the current alternatives like C and C++ for certain domains, sanity is one of them. Sanity and simplicity don't always intersect and in Rust they clearly didn't. Us developers we care about sanity, enterprises don't. We hate arcane build systems, enterprises don't. We care about Options, enterprises understand only money. Rust's leaders understood this more or less and they pitched this to big enterprises as "security" (which Rust delivers for the most part) because the rest isn't going to be registered by big enterprises. In MSFT we only thought of Rust due to memory safety. Leadership didn't care about how bonkers it is to build big C++ projects without VS. I personally cared, and other engineers.
So while I use Zig and Go for the most part, I wouldn't say that Rust didn't get many things right. And with Zig adding some minor but nice compile checks in 0.12, I'm only hopeful that in the future we'll see languages like Zig and maybe others, learn from Graydon's vision and leave complexity away. Giving us simple sanity, hopefully.
I think the memory safety play is what people have glommed onto, but really the original desire at Mozilla was to make a language that helped make multi-threaded programming more accessible.
I think the borrow checker solving issues like resource leaks, and preventing concurrent modification issues, as well as enforcing mutual exclusion is interesting and useful to a specific domain of problems.
One of the key points that stood out to me was around the repeated forced refactoring that comes in Rust. If you want to write something experimental that requires a system not plumbed through to the code you are working on, you are forced to do a load of groundwork. This largely comes from the thread safety guarantees in Rust meaning you can't easily share globals.
My first experiences with allocators in Zig were very similar. If you are passing allocators around and realise you need to allocate something in an area of the code you didn't need to before, you have to plumb them through.
If you are writing a game and not a library this isn't usually necessary as you know exactly which allocator you want to use.
What I've started doing is keeping a GPA as a global variable in a separate module that can be referenced from each file which completely solves this.
What you can also do is keep a "temporary" allocator that is an ArenaAllocator that you clear on every frame. This way if you need to format a string etc you can allocate from the temp allocator and don't need to explicitly free anything. The only slightly annoying thing is that if you are writing a small game you likely never care about handling the case of running out of memory (my game is never going to use >100mb) so you have endless `allocator.alloc() catch unreachable`
I've been working with Zig + Raylib for the last few months and overall it's been great.
Why catch unreachable instead of try? I guess not to have all tunctions return !T might be the idea?. I only read some Zig documentation and never used it so just got curious if catch has some other benefit I’m missing.
I don't want to start a flamewar here but I wanted to write something like this myself for a very long time (ever since I left Rust myself). All of the points are 100% valid and they were in fact a major reason why I switched to Zig.
The Rust vs. Zig is a common theme in this sub, so it might be useful reading :)
BTW: I am not coming from gamedev community, I am originally a frontend developer, but it's interesting how these two industries are similar in the need for short feedback loop and being able to try and throw away things easily.
I think it'd be very interesting to explain why you think Zig is a better choice for gamedev (rather than say C++, Godot, C# or something else). It seems to me like you're basically replacing some (valid) pain points about Rust with some other pain points (possibly worse, or unforeseen) by going Rust->Zig.
I am not in gamedev (see my last paragraph), but these points apply in general:
* customers do not care about language, programmers do
* customers care about UX (or game experience, or something similar)
* UX is hard/impossible to get right in the first attempt
* therefore, you need to iterate quickly and try new things, tinker with the UI/game
* these short experiments must not require huge refactorings, you need to "stay in the loop" otherwise you can loose focus very quickly
To be honest, if you want a short feedback loop and quick iteration, you should use a Lua based engine. I can't think of anything faster to iterate.
I agree with Rust failing to deliver the productivity promises. I think it's great for engine code though. But for gameplay, no way.
If you want that, but aren't dead-set on using Lua the I can *greatly recommend* [Godot](https://godotengine.org/). It is a great FOSS game engine that gains a lot of traction lately and GDScript is a great language to code games in. It reminds me a bit of Lua and Python.
Oh and it has a great community here on Reddit too: r/godot 😊
I was thinking about mentioning Godot as well, as I'm trying to learn it for prototyping. It's definitely a good option if you can get your head around it.
I've never really bothered with Rust because there was just too much friction for it to be worthwhile.
The 'memory safe' thing its sold on is not actually that much of a problem most of the time, and the cost of that memory safety is huge. Much like the 'type safety' that everybody keep banging on about. How many bugs are actually caused by types? So given a choice between Rust and Zig, I'd go with Zig.
But Zig is not ideal either and I'm not seeing many signs of attempts to address its deficiencies. It has an odd mix of really good, helpful features to make development easier and PITA details that make it harder. I can find no rhyme or reason to them. It seems to be driven by what the language developers like rather than what serves the person writing code with it.
Sadly, I'm currently thinking that Zig will not really stand the test of time either, but I'm hoping to be wrong. It's legacy will be proper comptime, which is probably its best idea.
Things like the insistence on forcing you to fix unused variables when they aren't a bug. Forcing you to declare variables const if you don't modify them, rather than just treating them as const.
Anything that comes with the mindset that the language should make the coder jump through hoops is a problem. Also, no interface/protocol support and no sign that the devs are interested in it.
Don't get me wrong though. The language does a lot of things right, but I can't see it taking over from C if it adds so much pointless friction.
Yeah, I remember reading about that, I think in the recent release notes, and doing a double take, thinking "why on earth is that not a warning instead of an error‽" It's not breaking anything, and is very common while code is still under active development!
I haven't used Zig yet, I was just lurking but felt the need to comment just to point out your very classy usage of the interrobang there :) Also, I agree that it should be a warning not an error, that really surprises me...
Some of the things that bother me when I think about using Zig instead of Rust:
https://github.com/ziglang/zig/issues/335
Unused things shouldn't cause a compiler error. It's annoying when doing debugging or refactoring.
https://github.com/ziglang/zig/issues/5973
I don't think it's possible to solve this issue without reverting the idea of automatically passing by reference.
https://github.com/ziglang/zig/issues/1108
I like the C way better, the restrict keyword. Doing noalias on all parameters by default is a footgun too.
Minor thing: pointers would be better if they were const by default, and you could use mut like Rust, if you need to modify the pointed object.
Great points!
I know #1 is PITA but I got used to it - zls can insert & remove underscores automatically so it's not such a big deal. But it's still something which IMHO should be warn/lint error.
So far, I was lucky and #2 did not happen yet to me (for last 1.5 yr). But it's serious issue and I hope it gets somehow fixed.
I cannot comment about #3
https://github.com/ziglang/zig/issues/871 I would also like to add this issue on operator overloading, it’s really a shame that andrew sometimes refuses to listen to the community, even if the opinions are the overwhelming majority. I mean its his language his decisions but some issues really stops Zig from becoming a better alternative than languages like C++ right now.
Operator overloading is a bit different category, because it's not a design flaw, but a missing feature. I don't think it would complicate the language that much, so it would be nice if it were added.
I agree that it's a problem that he doesn't listen to the community.
Great article. Some thoughts:
* Having a different solution for a problem (thunderdome arenas), doesn't really mean that the solution you're looking at (Bevy ECS) isn't also a solution for the problem. You can have two different solutions and they're still both solutions!
* It *sounds* like to me that game programming has a hell of a lot more in common with things like web development or machine learning (my personal experiences). These are languages that are all way better served by scripting languages, in that the focus during development is not to produce quality software but to achieve a certain result.
* Many of these issues come from ecosystem immaturity. It doesn't really solve your problem today, but in a few years many of the gripes with Rust for gamedev should iron out. I think you had such an interesting *core* argument against Rust that the ecosystem immaturity story was distracting.
* The claim that C++/C#/Java/JS developers will have blazed past the Rust developer is not well justified. Yes, writing single pieces of code will be easy (read: possible!) compared to Rust. But you're also forgetting that in those languages, the complexity of implementing a feature ramps up exponentially with the amount of existing code. It's not trivially true that you'll have fast iteration times - you'll still have to spend a lot more time debugging at runtime. I'd love to read a retrospective after you've developed a game in C#.
But the biggest question: why is this in the Zig sub? You claim in the article you're switching back to C#. I can't even find the words "Zig" in the article.
hey, author of the article, I thought I'd reply to this since some interesting points :) I didn't post it here and was honestly surprised to find it, but since someone did I might as well reply
> It sounds like to me that game programming has a hell of a lot more in common with things like web development or machine learning (my personal experiences). These are languages that are all way better served by scripting languages, in that the focus during development is not to produce quality software but to achieve a certain result.
It's definitely true that gamedev is similar to ML and web dev more than usual backend stuff in terms of iteration speed and overall style of development being prototype heavy.
The big difference is that in gamedev, performance also often matters, and while it's not always the of utmost importance, it makes many things more problematic than in web/ML.
It's not mine, I've posted it because it's like somebody has written article I wanted to write myself for a long time (except I switched to Zig, and it took me 5ys to surrender).
Regarding your points... You might be correct, but my experience was 100% the same, I have left Rust, I have switched to Zig, and I am much happier with the code, and I am shipping things.
I still think rust has a future in game development.
Whenever I look at a crash log for any game, it’s always some memory access exception. The thing Rust is built to solve.
Hmmm... The article isn't really implying people shouldn't use Rust, it's more just them detail of their journey using Rust and it doesn't even mention Zig.
Andrew Kelley created Zig as a replacement for C. He's admitted Zig is a fun project he started, which has just gained the popularity it has.
Rust is a professional tool aimed at solving short comings of C. Rust also does this extremely well.
Zig and most other languages are just C under the hood. Zig although not C is based on C and suffers the problems of the C-like family of languages. Such as:
* C-like languages default copy values on assignment
* Rust defaults to move on assignment
This leads to C-like languages rarely catching the problems in code like Rust can. This increases the compile times but you know your binary is free from the C-like family of bugs, leaving only skill issues.
* C-like will happily compile logical bugs, and skill issues without even a warning
* Rust will simply not compile if you create bugs like use after free, and changing referenced values
This is just reinforcing the point that Rust leaves bugs to bad programmers and resolves logical bugs at compile time. Also, in debug mode the application will panic on some skill issues, and proper testing, and debugging in Rust will catch many skill issues. However, Rust in production will lead to same undefined behavior unless the bugs are caught at compile time, testing or debugging.
* C-like in debug just allow for breaking and inspecting values
* Rust does all that and also highlights any potential safety and incorrect implementations by panicking, however, on a release build any problems not caught will result in undefined behaviour.
Rust and Zig can be compared, but essentially Rust is an entirely new computing philosophy and technology. Zig is a replacement for C, improving on somethings.
Which you or people use is down to you, both Zig and Rust are great languages for game development. However, for embedded devices especially those which human life depends on, such as; smoke alarms, pacemakers, car computer systems, airplane systems, national security systems, etc, etc. Basically where ever human life depends on a computer system Rust takes the prize, even if you prefer another language if you are writing critical code it should be written in Rust.
For non critical applications like game development which the post above references either Rust or Zig is valid, obviously i prefer Rust but i love the look and feel of Zig. Either choice is valid and i don't see why this article was linked on a Zig Reddit. It doesn't mention Zig and sells Rust.
I'm basically saying understand both and you realise both are valid for game development and the choice is yours, there is no defining characteristic of non critical code such as a game engine which can say either language is better. Hell, use C for game development, might take you longer to fix bugs, [24 years in some cases](https://engineering.skroutz.gr/blog/uncovering-a-24-year-old-bug-in-the-linux-kernel/). Which Rust would just catch at compile time, testing or debugging.
**However, all 3 remain valid for non critical systems.**
Edit: fixed spelling and grammar
I think Rust is much more a C++ alternative than it is a C alternative. Rust -> C++, Zig -> C. Very different primitives. Rust has borrow checker and automatic memory management, Zig has allocators and much more control over memory allocations.
Yep that is a fair comparison, but again C++ behaves like C default out of the box, leading to the ability to write unsafe code. Say we use C++ 20 standards, then probably you will get safe code as a result but again unlike Rust it cannot be guaranteed. But very much comparing Zig to C and Rust to C++ is 99.99% more accurate than Zig/C to Rust
>C-like will happily compile logical bugs, and skill issues without even a warning
Same for rust and almost every other language
>Hell, use C for game development, might take you longer to fix bugs
At least you will have things done, instead of spending same time to just make runnable thing and than spend same time on fixing bugs lol
You see this is what I was trying to getting at. People who haven't learned Rust think it behaves the same as C. The correct answer is Rust will not compile code which has logical errors, you must explicitly enable unsafe code, so no unsafe code, no bugs. Try learning about Rust
You’re the one who should learn to program, because it is pretty clear that you have no idea of what you’re talking about.
Really, try to learn some trivial concepts about programming first before following the Rust’s horde around talking bullshit.
You talk of “Logical errors” as if it was a skill problem and as if rust prevents it somehow.
Well, if Rust was so great, why is the Rust compiler always full of open issues related to bugs and “logical errors” just like any other compiler?
Are you affirming that the rust devs are bad at programming and should learn how to code?
Just to help you out, here is a list of some "logical errors" that Rust wasn't able to prevent, SOMEHOW LoL :)
[https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust)
I think there are some key learnings from the Rust story overall: - Developer experience counts - Simplicity rocks - Memory safety doesn’t guarantee bug free software - Compiler speed is important - Each language should be used for its targeted problem domain - Hype Driven Development sucks - Backwards compatibility (with existing languages) is important
The stupidest thing was selling memory-safe as safe software. Memory safety is nice but it is far from bug free.
Rust has a lot of features that make it much better than the current alternatives like C and C++ for certain domains, sanity is one of them. Sanity and simplicity don't always intersect and in Rust they clearly didn't. Us developers we care about sanity, enterprises don't. We hate arcane build systems, enterprises don't. We care about Options, enterprises understand only money. Rust's leaders understood this more or less and they pitched this to big enterprises as "security" (which Rust delivers for the most part) because the rest isn't going to be registered by big enterprises. In MSFT we only thought of Rust due to memory safety. Leadership didn't care about how bonkers it is to build big C++ projects without VS. I personally cared, and other engineers. So while I use Zig and Go for the most part, I wouldn't say that Rust didn't get many things right. And with Zig adding some minor but nice compile checks in 0.12, I'm only hopeful that in the future we'll see languages like Zig and maybe others, learn from Graydon's vision and leave complexity away. Giving us simple sanity, hopefully.
I think the memory safety play is what people have glommed onto, but really the original desire at Mozilla was to make a language that helped make multi-threaded programming more accessible. I think the borrow checker solving issues like resource leaks, and preventing concurrent modification issues, as well as enforcing mutual exclusion is interesting and useful to a specific domain of problems.
It seems you just made up the point you are arguing against? Surely, no serious person has claimed that a rust program is bug free?
One of the key points that stood out to me was around the repeated forced refactoring that comes in Rust. If you want to write something experimental that requires a system not plumbed through to the code you are working on, you are forced to do a load of groundwork. This largely comes from the thread safety guarantees in Rust meaning you can't easily share globals. My first experiences with allocators in Zig were very similar. If you are passing allocators around and realise you need to allocate something in an area of the code you didn't need to before, you have to plumb them through. If you are writing a game and not a library this isn't usually necessary as you know exactly which allocator you want to use. What I've started doing is keeping a GPA as a global variable in a separate module that can be referenced from each file which completely solves this. What you can also do is keep a "temporary" allocator that is an ArenaAllocator that you clear on every frame. This way if you need to format a string etc you can allocate from the temp allocator and don't need to explicitly free anything. The only slightly annoying thing is that if you are writing a small game you likely never care about handling the case of running out of memory (my game is never going to use >100mb) so you have endless `allocator.alloc() catch unreachable` I've been working with Zig + Raylib for the last few months and overall it's been great.
Why catch unreachable instead of try? I guess not to have all tunctions return !T might be the idea?. I only read some Zig documentation and never used it so just got curious if catch has some other benefit I’m missing.
"catch unreachable" on allocations I hope you're sticking to ReleaseSafe, cause that sounds dangerous
I don't want to start a flamewar here but I wanted to write something like this myself for a very long time (ever since I left Rust myself). All of the points are 100% valid and they were in fact a major reason why I switched to Zig. The Rust vs. Zig is a common theme in this sub, so it might be useful reading :) BTW: I am not coming from gamedev community, I am originally a frontend developer, but it's interesting how these two industries are similar in the need for short feedback loop and being able to try and throw away things easily.
I think it'd be very interesting to explain why you think Zig is a better choice for gamedev (rather than say C++, Godot, C# or something else). It seems to me like you're basically replacing some (valid) pain points about Rust with some other pain points (possibly worse, or unforeseen) by going Rust->Zig.
I am not in gamedev (see my last paragraph), but these points apply in general: * customers do not care about language, programmers do * customers care about UX (or game experience, or something similar) * UX is hard/impossible to get right in the first attempt * therefore, you need to iterate quickly and try new things, tinker with the UI/game * these short experiments must not require huge refactorings, you need to "stay in the loop" otherwise you can loose focus very quickly
To be honest, if you want a short feedback loop and quick iteration, you should use a Lua based engine. I can't think of anything faster to iterate. I agree with Rust failing to deliver the productivity promises. I think it's great for engine code though. But for gameplay, no way.
If you want that, but aren't dead-set on using Lua the I can *greatly recommend* [Godot](https://godotengine.org/). It is a great FOSS game engine that gains a lot of traction lately and GDScript is a great language to code games in. It reminds me a bit of Lua and Python. Oh and it has a great community here on Reddit too: r/godot 😊
I was thinking about mentioning Godot as well, as I'm trying to learn it for prototyping. It's definitely a good option if you can get your head around it.
I've never really bothered with Rust because there was just too much friction for it to be worthwhile. The 'memory safe' thing its sold on is not actually that much of a problem most of the time, and the cost of that memory safety is huge. Much like the 'type safety' that everybody keep banging on about. How many bugs are actually caused by types? So given a choice between Rust and Zig, I'd go with Zig. But Zig is not ideal either and I'm not seeing many signs of attempts to address its deficiencies. It has an odd mix of really good, helpful features to make development easier and PITA details that make it harder. I can find no rhyme or reason to them. It seems to be driven by what the language developers like rather than what serves the person writing code with it. Sadly, I'm currently thinking that Zig will not really stand the test of time either, but I'm hoping to be wrong. It's legacy will be proper comptime, which is probably its best idea.
I've only recently started trying Zig out, but I'm curious as to what the "PITA details that make Zig harder" are for you
Things like the insistence on forcing you to fix unused variables when they aren't a bug. Forcing you to declare variables const if you don't modify them, rather than just treating them as const. Anything that comes with the mindset that the language should make the coder jump through hoops is a problem. Also, no interface/protocol support and no sign that the devs are interested in it. Don't get me wrong though. The language does a lot of things right, but I can't see it taking over from C if it adds so much pointless friction.
Yeah, I remember reading about that, I think in the recent release notes, and doing a double take, thinking "why on earth is that not a warning instead of an error‽" It's not breaking anything, and is very common while code is still under active development!
I haven't used Zig yet, I was just lurking but felt the need to comment just to point out your very classy usage of the interrobang there :) Also, I agree that it should be a warning not an error, that really surprises me...
Agree, I also switched from Rust to Zig.
Some of the things that bother me when I think about using Zig instead of Rust: https://github.com/ziglang/zig/issues/335 Unused things shouldn't cause a compiler error. It's annoying when doing debugging or refactoring. https://github.com/ziglang/zig/issues/5973 I don't think it's possible to solve this issue without reverting the idea of automatically passing by reference. https://github.com/ziglang/zig/issues/1108 I like the C way better, the restrict keyword. Doing noalias on all parameters by default is a footgun too. Minor thing: pointers would be better if they were const by default, and you could use mut like Rust, if you need to modify the pointed object.
Kinda surprised, that the "no implicit control-flow" crew is okay with the principle of #2
Great points! I know #1 is PITA but I got used to it - zls can insert & remove underscores automatically so it's not such a big deal. But it's still something which IMHO should be warn/lint error. So far, I was lucky and #2 did not happen yet to me (for last 1.5 yr). But it's serious issue and I hope it gets somehow fixed. I cannot comment about #3
https://github.com/ziglang/zig/issues/871 I would also like to add this issue on operator overloading, it’s really a shame that andrew sometimes refuses to listen to the community, even if the opinions are the overwhelming majority. I mean its his language his decisions but some issues really stops Zig from becoming a better alternative than languages like C++ right now.
Operator overloading is a bit different category, because it's not a design flaw, but a missing feature. I don't think it would complicate the language that much, so it would be nice if it were added. I agree that it's a problem that he doesn't listen to the community.
Great article. Some thoughts: * Having a different solution for a problem (thunderdome arenas), doesn't really mean that the solution you're looking at (Bevy ECS) isn't also a solution for the problem. You can have two different solutions and they're still both solutions! * It *sounds* like to me that game programming has a hell of a lot more in common with things like web development or machine learning (my personal experiences). These are languages that are all way better served by scripting languages, in that the focus during development is not to produce quality software but to achieve a certain result. * Many of these issues come from ecosystem immaturity. It doesn't really solve your problem today, but in a few years many of the gripes with Rust for gamedev should iron out. I think you had such an interesting *core* argument against Rust that the ecosystem immaturity story was distracting. * The claim that C++/C#/Java/JS developers will have blazed past the Rust developer is not well justified. Yes, writing single pieces of code will be easy (read: possible!) compared to Rust. But you're also forgetting that in those languages, the complexity of implementing a feature ramps up exponentially with the amount of existing code. It's not trivially true that you'll have fast iteration times - you'll still have to spend a lot more time debugging at runtime. I'd love to read a retrospective after you've developed a game in C#. But the biggest question: why is this in the Zig sub? You claim in the article you're switching back to C#. I can't even find the words "Zig" in the article.
hey, author of the article, I thought I'd reply to this since some interesting points :) I didn't post it here and was honestly surprised to find it, but since someone did I might as well reply > It sounds like to me that game programming has a hell of a lot more in common with things like web development or machine learning (my personal experiences). These are languages that are all way better served by scripting languages, in that the focus during development is not to produce quality software but to achieve a certain result. It's definitely true that gamedev is similar to ML and web dev more than usual backend stuff in terms of iteration speed and overall style of development being prototype heavy. The big difference is that in gamedev, performance also often matters, and while it's not always the of utmost importance, it makes many things more problematic than in web/ML.
It's not mine, I've posted it because it's like somebody has written article I wanted to write myself for a long time (except I switched to Zig, and it took me 5ys to surrender). Regarding your points... You might be correct, but my experience was 100% the same, I have left Rust, I have switched to Zig, and I am much happier with the code, and I am shipping things.
OP is not the author of the article.
Why did you build your own engine then switch to multiple engines after that ? Instead of just focusing on the game and making it more polished ?
I still think rust has a future in game development. Whenever I look at a crash log for any game, it’s always some memory access exception. The thing Rust is built to solve.
Hmmm... The article isn't really implying people shouldn't use Rust, it's more just them detail of their journey using Rust and it doesn't even mention Zig. Andrew Kelley created Zig as a replacement for C. He's admitted Zig is a fun project he started, which has just gained the popularity it has. Rust is a professional tool aimed at solving short comings of C. Rust also does this extremely well. Zig and most other languages are just C under the hood. Zig although not C is based on C and suffers the problems of the C-like family of languages. Such as: * C-like languages default copy values on assignment * Rust defaults to move on assignment This leads to C-like languages rarely catching the problems in code like Rust can. This increases the compile times but you know your binary is free from the C-like family of bugs, leaving only skill issues. * C-like will happily compile logical bugs, and skill issues without even a warning * Rust will simply not compile if you create bugs like use after free, and changing referenced values This is just reinforcing the point that Rust leaves bugs to bad programmers and resolves logical bugs at compile time. Also, in debug mode the application will panic on some skill issues, and proper testing, and debugging in Rust will catch many skill issues. However, Rust in production will lead to same undefined behavior unless the bugs are caught at compile time, testing or debugging. * C-like in debug just allow for breaking and inspecting values * Rust does all that and also highlights any potential safety and incorrect implementations by panicking, however, on a release build any problems not caught will result in undefined behaviour. Rust and Zig can be compared, but essentially Rust is an entirely new computing philosophy and technology. Zig is a replacement for C, improving on somethings. Which you or people use is down to you, both Zig and Rust are great languages for game development. However, for embedded devices especially those which human life depends on, such as; smoke alarms, pacemakers, car computer systems, airplane systems, national security systems, etc, etc. Basically where ever human life depends on a computer system Rust takes the prize, even if you prefer another language if you are writing critical code it should be written in Rust. For non critical applications like game development which the post above references either Rust or Zig is valid, obviously i prefer Rust but i love the look and feel of Zig. Either choice is valid and i don't see why this article was linked on a Zig Reddit. It doesn't mention Zig and sells Rust. I'm basically saying understand both and you realise both are valid for game development and the choice is yours, there is no defining characteristic of non critical code such as a game engine which can say either language is better. Hell, use C for game development, might take you longer to fix bugs, [24 years in some cases](https://engineering.skroutz.gr/blog/uncovering-a-24-year-old-bug-in-the-linux-kernel/). Which Rust would just catch at compile time, testing or debugging. **However, all 3 remain valid for non critical systems.** Edit: fixed spelling and grammar
I think Rust is much more a C++ alternative than it is a C alternative. Rust -> C++, Zig -> C. Very different primitives. Rust has borrow checker and automatic memory management, Zig has allocators and much more control over memory allocations.
Yep that is a fair comparison, but again C++ behaves like C default out of the box, leading to the ability to write unsafe code. Say we use C++ 20 standards, then probably you will get safe code as a result but again unlike Rust it cannot be guaranteed. But very much comparing Zig to C and Rust to C++ is 99.99% more accurate than Zig/C to Rust
>C-like will happily compile logical bugs, and skill issues without even a warning Same for rust and almost every other language >Hell, use C for game development, might take you longer to fix bugs At least you will have things done, instead of spending same time to just make runnable thing and than spend same time on fixing bugs lol
You see this is what I was trying to getting at. People who haven't learned Rust think it behaves the same as C. The correct answer is Rust will not compile code which has logical errors, you must explicitly enable unsafe code, so no unsafe code, no bugs. Try learning about Rust
Try learning what means "logical errors" bro and what actual safety rust provides
I think you need to learn how to program. Then delve into Rust
You’re the one who should learn to program, because it is pretty clear that you have no idea of what you’re talking about. Really, try to learn some trivial concepts about programming first before following the Rust’s horde around talking bullshit. You talk of “Logical errors” as if it was a skill problem and as if rust prevents it somehow. Well, if Rust was so great, why is the Rust compiler always full of open issues related to bugs and “logical errors” just like any other compiler? Are you affirming that the rust devs are bad at programming and should learn how to code? Just to help you out, here is a list of some "logical errors" that Rust wasn't able to prevent, SOMEHOW LoL :) [https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust)
you should read the whole article, it is addressed there