Oh no don’t get me wrong, a year back I upgraded to an I5-7500 prebuilt, and it’s a beast for all my tasks. (maybe compiling is quick because I split modules a little too much?)

Your advice is good for not knowing what I’m making. If I was making something multi threaded with much state I would fear UB more.

may be much rarer in Debug because of speed difference

Thanks, then I will remember to recreate bugs with opt-level = 3.

Wait no, this doesn’t make sense if I don’t have access to the user’s machine, maybe I should send him a log-heavy version of some sort? How should I even what I am supposed to log? I should think about this some more before release.

Do you have any sources about this “unfitness” of Rust for gamedev? From my experience many people have problems with the borrow checker due to habits they obtained coding in other languages.

I can’t say anything for sure, but I read this article, in conjunction with this article, before I made this post, so you might consider looking at it, and how it influenced me.

Edit: wait, I’ll extend this reply even more.

Edit 2: Done:

So I’d be interested what special behavior occurs in gamedev that makes coding in Rust more difficult than for other software.

Maybe it’s because the gaming industry is historically among the slowest industries, they stuck with DOS until there was literally no drivers on it for the latest GPUs, only then did they upgrade. There’s a video explaining how a recent AAA game could run on the steam deck, but not on Linux, it turns out the game was using a Windows XP library that’s too old for wine to support, so how did it work on the deck? they effectively added this to their code:

if platform_name == "steamdeck" { use_modern_library() }

, which explains why it only ran on the deck, but notice how they still stuck to the ~2003 library as the default even though the modern one works, that’s how much they hate change.

Considering the above, suggesting they change the particular way of their forefathers wouldn’t be fruitful, unless extremely obvious B I G gains are to be found. Notice how Jonathan Blow’s game development language is literally ‘C++ but better’, and how it mimics C++ in everything but the universally hated parts, and adds none but the universally wanted features. (as universal as an industry can agree on anything, that is)

That may be because games are a dangerous business, you pool all your resources in one project, and you get basically no income for up to four years, then you release and possibly succeed.

I also speculate that games aren’t really maintained, most of the best games I know only received 3 patches at most (version 1.3). I think the priority isn’t: “How am I gonna remember how this works in 3 months from now and deal with technical dept”, it’s more like: “How can I implement this in a way that the only thing faster than the implementation time is the feature itself?”, so there is no fear of possibly breaking something that the checker can save you from down the road.

The last sentence kinda doesn’t make sense since the first 3 years are more that enough technical dept for Rust to start doing its thing, but IDK how they think.

Bonus: look for Jonathan Blow’s opinions on Rust on Youtube, he is an example of a studio owner fearing the risk of the possible “friction” that the Borrow checker could possibly cause.

Hello Pers,

I made a mistake when writing the post, it reads like I am against the borrow checker, which I am not, I love the checker, and didn’t encounter any - major - problems with it.

I meant that even if we used unsafe everywhere it would still be a good language, which is an attempt at arguing with those saying that Rust isn’t fit for gamedev because the of the checker. Which I failed at due to lack of experience, as this is my first time making a game, and Rust is my first language*.

Regarding: “If it doesn’t panic in Debug, it won’t act weird on Release”, even if I got reported a really weird bug related to UB, I should (I am not experienced enough to make a claim) be able to know it’s UB since the game’s gonna crash when I try to recreate the bug in Debug.

Some would say that shipping the game with runtime checks won’t have an effect on performance, which is probably true, since it’s so simple the list of entities is an array (not a vector), and the game state is - effectively - global (everything is impl CombatContext { fn x(&mut self) {} })**, and some (most? too early in development to tell) of the game is locked at 5fps (maybe I’ll bump it up a bit)***.

I am so concerned about performance because I had to daily drive a computer that most people on this website - and especially on Reddit - would consider garbage E-waste, for 4 years, and was trying hard to play games on it, which was further amplified by my GPU not supporting Vulkan (nor Dx9 for some time), which meant I couldn’t use Proton, which taught me some hacks that are… let’s not talk about them.

So I find huge pain in leaving any possible performance optimizations, especially that some people I know are stuck on - arguably - worse machines****; accessibility is a big priority.

It also makes me angry to see pixel games come with 70Mib binaries and require Vulkan because:

1 - internet costs money

2 - they claim in the system requirements that their game “Should run on anything”.

Memes like: “Oh my game could run on a potato” infuriate me (good thing I don’t use social media), NO, your game can’t run a potato, DooM can, it was actually optimized properly, your 2D pixels can’t even render on a machine a 100x more powerful, you should feel ashamed*(5).

*: I was messing around with C# + Godot not super long ago, nothing serious.

**: I have been refactoring my code lately to limit the scope of most functions, in a way inspired by ECSs, but significantly more primitive.

***: the game has both a 3D and a 2D part, the 2D part has locked FPS, the 3D part can run at any framerate.

****: Macroquad supporting OpenGL only down to 2.0ES would be a problem, if I wasn’t intending on forking it anyway to reduce the binary size (grim is an extremely bloated dependency, I managed to shove off 10 Mib in a few hours), and unless using 1.x is as hard people on the internet claim it is, which is probably false, as these people are mostly weak and say the same things about using a custom engine.

*(5): this might sound toxic, but that’s how people get better.

I believe BSD has more servers than macOS.

Actually, crowdstrike has a very bad record regarding this, their services even managed to break Debian servers one time.

Source: some article.

[joke] That must be my friend’s laptop. [joke]

The problem solving though?

running video games, or any OpenGL thing including 2D games and GPU-accelerated terminal emulators is a bad experience

The thing you replied to; I don’t open social media often enough to reply on time, so I sent you a late reply.

Also, sloppy focus aka focus-follows-mouse

It’s one of those features I always wanted to try, but always forget to look up how to actually enable and start using it, so I never actually tried it.

Inaccurate report,

I just ran Neovim in terminal and was used to Neovide, so I thought it was choppy.

Intel HD 630.

There is, however, a 2D game - which I am not going to disclose the name of - that’s pretty broken. (It uses Adobe Flash as an engine)

Also the steam client doesn’t maximize properly with tiling but I am sure that’s reported.

I have been daily driving Cosmic for a week now; it caused me Arch-syndrome, everyday I run sudo apt update hoping to get some polish to the desktop.

Edit: there’s more…

Neovide’s transparency is completely broken, and shows a blank, though not a pitch black, color and screenshotting it results in seeing the text with a checkered background. (In the resulting screenshot only) (Running on Proton 8.0-5)

clipboard=unnamed plus, the setting supposed to unify Neovim’s clipboard and system’s, doesn’t work. clipboard: error : Error: target STRING not available

I also was unable to transfer a file to my phone using Cosmic Files, but Nemo worked, though I read that’s fixed in some Blog.

Edit II: I just discovered popdev:master it seems to be a general unstable branch instead of just Cosmic things, but I took the risk and added it, I just have to remember to remove it once 24.04’s released

No, it is not, people have been using 8-space tabs even back when terminals were limited to 80 characters.

Well, what I meant was just rustfmt’s default with:

• 80 character line
• 8-space hard tabs

In addition to naming local variables short names, and soft-limiting functions to 48 lines long & their local variables to 5-10 (you know, normal reasonable things)

The part about switch statements doesn’t apply as Rust replaced them with match.*

The part about function brackets on new lines doesn’t apply because Rust does have nested functions.

The bad part about bracket-less if statements doesn’t apply as Rust doesn’t support such anti-features.

The part about editor cruft is probably solved in this day & age.

The rest are either forced by the borrow checker, made obsolete by the great type system, or are just C exclusive issues that are unique to C.

I left out some parts of the standard that I do not understand.

I just skimmed through the Rust style guide, and realized the only real difference between the 2 standards is indentation, and line length. Embarrassing.

*: I experimented with not-indenting the arms of the root match expression, it’s surprisingly very good for simple match expressions, and feels very much like a switch, though I am not confident in recommending to people.

Edit: How did I forget?! Indentation is limited to 3, increasing code readability.

So, why don’t people just restrict tabs to pre-text, strictly-sized indentation?

On a side note: I think (not sure) that indenting with 8 or more spaces just to align 2 similar but differently sized lines of code is a bit too much.

I am on Pop!_OS, I ran sudo apt install cosmic*.

Don’t worry, you’re not missing out on much, running video games, or any OpenGL thing including 2D games and GPU-accelerated terminal emulators is a bad experience, and alt+f4 isn’t implemented, and f11 to fullscreen is janky, and theming for buttons and such is clearly alpha.

The promise of an Arabic-supporting, Rust based, GPU-accelerated terminal is too attractive, however, as I was teared between multilingual terminal, Wezterm, Alacritty and Kitty for a while.

The first is horrible at everything but supporting languages, the second is really janky, the third doesn’t support tabs, the fourth has bad theming and customization.

wasting 10% of that space for each indentation? What are you smoking?

As I said before, this standard is older than C itself, and the kernel’s been using it for decades, I shouldn’t have to explain it. Long tabs and short lines boost readability, and restricting indentation to 3 solves the problem. Read my reply to 1rre@discuss.tchncs.de for more context.

Also rustfmt didn’t move the string in

println!("a very long string slice with a static lifetime"); to a new line even when it exceeded a 100 columns, I should seek a solution.

Note: The actual string I used was way longer than that.

This one in particular I am against. (it’s not like it’s possible in rust anyway)

A semi-rolling distribution, with access to Ubuntu’s many PPA’s, and easily removable extensions that reveal the lovely vanilla Gnome experience, it’s great!

Also they are making a Rust desktop, which I am currently running, though not daily driving.

Agreed, and upvoted.

It has a long-lasting C coding standard, they call it the standard since it was the only language anyway. Then, they made a newly conceived Rust standards, which ignore everything the original standard stood for. (Note the strong language in the post’s first quote, it’s from the original standard)

having five times more work to use tabs for indentations and spaces for alignment and thus having to use visual whitespace of some kind.

Excuse me. What does that mean? (also see my reply to 1rre)