Loglog Games

> First, let me assure you - yes, we (as in, the Rust Project) absolutely do care about the performance of our beloved compiler, and we put in a lot of effort to improve it.

I'm probably being ungrateful here, but here goes anyway. Yes, Rust cares about performance of the compiler, but it would likely be more accurate to say that compiler performance is, like, 15th on the list of things they care about, and they'll happily trade off slower compile times for one of the other things.

I find posts about Rust like this one, where they say "ah, of course we care about perf, look, we got the compile times on a somewhat nontrivial project to go from 1m15s to 1m09s" somewhat underwhelming - I think they miss the point. For me, I basically only care if compile times are virtually instantaneous. e.g. Vite scales to a million lines and can hot-swap my code changes in instantaneously. This is where the productivity benefits come in.

Don't just trust me on it. Remember this post[1]?

> "I feels like some people realize how much more polish could their games have if their compile times were 0.5s instead of 30s. Things like GUI are inherently tweak-y, and anyone but users of godot-rust are going to be at the mercy of restarting their game multiple times in order to make things look good. "

[1]: https://loglog.games/blog/leaving-rust-gamedev/#compile-times-have-improved-but-not-with-proc-macros

This huge blog post goes over some of the challenges of using Rust. https://loglog.games/blog/leaving-rust-gamedev/

For the community I'll pluck out this paragraph

> That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense". This is not just with Rust, if you try using ECS you're told the same thing. If you try to use Bevy you'll be told the same thing. If you try to make GUIs with whichever framework you choose (be it one of the reactive solutions or immediate mode), you'll be told the same thing. The problem you're having is only a problem because you haven't tried hard enough.

I've experienced this same feedback when I was struggling with Rust. One time when I posted in the Rust subreddit about it seeking help and talking about my struggles, I got the unhelpful response of "I believe in people" as a dismissive response to my struggles. Admittedly this was years ago and I've since moved on from Rust, but the blog post is dated from 2024-04-26, so it appears the issues with the language still remain

The first part of your statement feels true, although that's... unverified and lacks actual backing up.

The second part of your statement is very debatable based on what safe means in this case, and whether it's an enormous benefit for a given situation.

There's plenty of stories [0][1] about Rust getting in the way and being very innappropriate for certain tasks and goals, and those "enormous benefits" can become "enormous roadblocks" in different perspectives and use cases.

In my personal and very subjective opinion I think Rust can be very good when applied to security applications, realtime with critical safety requirements (in some embedded scenarios for example), that sort of stuff. I think it really gets in the way too much in other scenarios with demanding rules and pattern that prevent from experimenting easily and exploring solutions quickly.

[0]https://barretts.club/posts/rust-for-the-engine/ [1]https://loglog.games/blog/leaving-rust-gamedev/

Rust? Since when is Rust the pinnacle of static type safety?

After I've worked for some time with a language that can express even stronger invariants in types than Rust (Scala) I don't see that property anymore as clear win regardless circumstances. I don't think any more "stronger types == better, no matter what".

You have a price to pay for "not being allowed to do mistakes": Explorative work becomes quite difficult if the type system is really rigid. Fast iteration may become impossible. (Small changes may require to re-architecture half your program, just to make the type system happy again![1])

It's a trade-off. Like with everything else. For a robust end product it's a good thing. For fast experimentation it's a hindrance.

[1] Someone described that issue quite well in the context of Rust and game development here: https://loglog.games/blog/leaving-rust-gamedev/

But it's not exclusive to Rust, nor game dev.

There are at least a couple of main reasons:

1. Rust attracts technically minded people, which is only a part (arguably not so important) of the skills/mindset required to produce a game; the result is that Rust as a community produces (way) more engines/plugins than games.

2. Rust is not convenient for fast iterations, typically required for games; when considering the game development landscape as a whole (ie. including indie production), performance is not as critical as thought, therefore the language loses the appeal compared to, say, C#.

Over the last year, there have been a few articles by devs who actually produced a game in Rust, then left; this is one of the most recent: https://loglog.games/blog/leaving-rust-gamedev.

> I wonder if Rust can reap some of the benefits of arena-based allocation by leveraging its lifetime tracking.

I'm reminded of one positive remark made here: https://loglog.games/blog/leaving-rust-gamedev/#ecs-solves-the-wrong-kind-problem

> The key point being, this allows a language like Rust to completely side-step the borrow checker and allow us to do "manual memory management with arenas" without actually touching any hairy pointers, and while remaining 100% safe. If there was one thing to point at that I like about Rust, it'd be this. Especially with a library like thunderdome it really feels that this is a great match, and that this data structure very well fits the language as it was intended.