pcwalton

> Rust is still popular but it turns out the developer joy is pretty low.

I mean, Rust keeps winning the "most loved" language contest on GitHub, so it seems someone likes it.

This is a good point. Zig is practically optimized for this: comptime is extremely dynamically typed compared to actual generics, and the lack of memory safety is often "a breath of fresh air"--until you have to actually fix bugs (including security bugs) resulting from it.

> It's not a great hobby language but it is a fantastic professional language,

I never thought I'd live to see the day when someone would say this. The first 5 years of Rust were all "this is interesting for hobby projects but nobody will ever adopt this in industry".

If Microsoft had adopted this attitude, then by now Excel's market share would probably be 0% and Google Sheets' would be 100%. Microsoft doesn't add features because they like bloated software; they add features because the market demands them, and the market demanded support for more than 65,535 rows.

Over the past year I've been working at my studio to add enough features to Bevy to ship real apps, and Bevy is at the point where one can reasonably do that, depending on your needs.

> You can't do possibly-erroneous pointer math on a C# object reference.

Bevy entity IDs are opaque and you have to try really hard to do arithmetic on them. You can technically do math on instance IDs in Unity too; you might say "well, nobody does that", which is my point exactly.

> You don't need to deal with the game life cycle AND the memory life cycle with a GC.

I don't know what this means. The memory for a `GameObject` is freed once you call `Destroy`, which is also how you despawn an object. That's managing the memory lifecycle.

> In Unity they free the native memory when a game object calls Destroy() but the C# data is handled by the GC. Same with any plain C# objects.

Is there a use for storing data on a dead `GameObject`? I've never had any reason to do so. In any case, if you really wanted to do that in Bevy you could always use an `EntityHashMap`.

Thankfully my studio has given me time to be able to submit a lot of upstream code to Bevy. I do agree that there's a bootstrapping problem here and I'm glad that I'm in a situation where I can help out. I'm not the only one; there are a handful of startups and small studios that are doing the same.

I just don't, and even less often with game logic which tends to be rather simple in terms of the data structures needed. In my experience, the ownership and borrowing rules are in no way an impediment to game development. That doesn't invalidate your experience, of course, but it doesn't match mine.

> No Tiny Glade doesn’t count.

> And if you look at Steam there are simply zero Rust made games in the top 2000. Zero. None nada zilch.

Well, sure, if you arbitrarily exclude the popular game written in Rust, then of course there are no popular games written in Rust :)

> And maybe not Switch although I’m less certain.

I have talked to Nintendo SDK engineers about this and been told Rust is fine. It's not an official part of their toolchain, but if you can make Rust work they don't care.

> I really don’t think Rust is a good match for game dev. Both because of the borrow checker which requires a lot of handles instead of pointers and because compile times are just not great.

I completely disagree, having been doing game dev in Rust for well over a year at this point. I've been extremely productive in Bevy, because of the ECS. And Unity compile times are pretty much just as bad (it's true, if you actually measure how long that dreaded "Reloading Domain" screen takes).

> More than anything else, this sounds like a good lesson in why commercial game engines have taken over most of game dev. There are so many things you have to do to make a game, but they're mostly quite common and have lots of off-the-shelf solutions.

> That is, any sufficiently mature indie game project will end up implementing an informally specified, ad hoc, bug-ridden implementation of Unity (... or just use the informally specified, ad hoc and bug-ridden game engine called "Unity")

But using Bevy isn't writing your own game engine. Bevy is 400k lines of code that does quite a lot. Using Bevy right now is more like taking a game engine and filling in some missing bits. While this is significantly more effort than using Unity, it's an order of magnitude less work than writing your own game engine from scratch.

But Unity game objects are the same way: you allocate them when they spawn into the scene, and you deallocate them when they despawn. Accessing them after you destroyed them throws an exception. This is exactly the same as entity IDs! The GC doesn't buy you much, other than memory safety, which you can get in other ways (e.g. generational indices, like Bevy does).

> We were writing an animation system in Bevy and were hit by the painful upgrade cycle twice.

I definitely sympathize with the frustration around the churn--I feel it too and regularly complain upstream--but I should mention that Bevy didn't really have anything production-quality for animation until I landed the animation graph in Bevy 0.15. So sticking with a compatible API wasn't really an option: if you don't have arbitrary blending between animations and opt-in additive blending then you can't really ship most 3D games.

Most game engines other than the latest in-house AAA engines are leaving comparable levels of performance on the table on scenes that really benefit from GPU-driven rendering (that's not to say all scenes, of course). A Google search for [Unity drawcall optimization] will show how important it is. GPU-driven rendering allows developers to avoid having to do all that optimization manually, which is a huge benefit.

> Just a mode to automatically coerce between numeric types would make Rust so much more ergonomic for gamedev.

C# is stricter about float vs. double for literals than Rust is, and the default in C# (double) is the opposite of the one you want for gamedev. That hasn't stopped Unity from gaining enormous market share. I don't think this is remotely near the top issue.

> Nobody has really pushed the performance issues.

This is clearly false. The Bevy performance improvements that I and the rest of the team landed in 0.16 speak for themselves [1]: 3x faster rendering on our test scenes and excellent performance compared to other popular engines. It may be true that little work is being done on rend3, but please don't claim that there isn't work being done in other parts of the ecosystem.

[1]: https://bevyengine.org/news/bevy-0-16/

> Do people actually travel between SF and LA?

Yes. The most obvious example of a company that's built around that corridor is Netflix: tech in the Bay Area, film production in L.A.

> I do not understand how people expect to write convincingly that tools that reliably turn slapdash prose into median-grade idiomatic working code "provide little value".

Honestly, I'm curious why your experience is so different from mine. Approximately 50% of the time for me, LLMs hallucinate APIs, which is deeply frustrating and sometimes costs me more time than it would have taken to just look up the API. I still use them regularly, and the net value they've imparted has been overall greater than zero, but in general, my experience has been decidedly mixed.

It might be simply that my code tends to be in specialized areas in which the LLM has little training data. Still, I get regular frustrating API hallucinations even in areas you'd think would be perfect use cases, like writing Blender plugins, where the documentation is poor (so the LLM has a relatively higher advantage over reading the documentation) and examples are plentiful.

Edit: Specifically, the frustrating pattern is: (1) the LLM produces some code that contains hallucinated APIs; (2) in order to test (or even compile) that code, I need to write some extra supporting code to integrate it into my project; (3) I discover that the APIs were hallucinated because the code doesn't work; (4) now I not only have to rewrite the LLM's code, but I also have to rewrite all the supporting code I wrote, because it was based around a pattern that didn't work. Overall, this adds up to more time than if I had just written the code from scratch.

> The OP cites these (https://github.com/devkitPro/libogc/blob/52c525a13fd1762c103... and https://github.com/atgreen/RTEMS/blob/2f200c7e642c214accb7cc...), but that's hardly a smoking gun. The function is trivial, just filling in some struct fields.

Yeah, I'm with Marcan 90% of the time, and in my view Marcan is more likely than not right that that function is derived from the RTEMS function, but in my view there's still reasonable doubt. That is to say, purely based on the evidence linked, I only agree that it's probable that the code is copied and disagree with Marcan's claim that it's "not possible" for the implementation to be non-infringing.

The fact that some of the identifiers are similar raises the biggest suspicions. "__lwp_stack_isenough" vs. "_Stack_Is_enough" is suspicious because I'd probably call that "sufficient_stack_available" or something like that. "LWP_STATES_DORMANT" vs. "STATES_DORMANT" is also suspicious because the normal OS term would be "sleeping". Still, the function logic is different enough that, even with that evidence, one could plausibly claim that only the headers or interface were copied and the implementation was clean-room, which is non-infringing per Oracle v. Google.

In US legal system terms, I'd say that a preponderance of the evidence shows that the code is a derivative work (i.e. it's more likely than not that the code was copied at some point), but that there's still reasonable doubt (i.e. a reasonable person could plausibly believe otherwise).

That statement seems extremely hyperbolic. Just today I tried automating some very pedestrian code for a system that wasn't particularly well-documented and ChatGPT 4o hallucinated the entire API. It was deeply frustrating and wasted more of my time than it would have taken to just slog through the documentation.

I won't deny that LLMs can be useful--I still use them--but in my experience an LLM's success rate in writing working code is somewhere around 50%. That leads to a productivity boost that, while not negative, isn't anywhere near the wild numbers that are bandied about.

I'm a Rust compiler author, and I'm fully in favor of "UB exploitation". In fact, LLVM should be doing more of it. LLVM shouldn't be holding back optimizations in memory-safe languages for edge cases that don't really matter in practice.

That example is an instance of unspecified vs. undefined behavior, but the correctness of the pointer provenance-based optimization example I gave doesn't depend on whether writing to an out-of-bounds pointer is unspecified or undefined.

Hence why I (and many other compiler developers) are inherently skeptical whenever anyone says "just stop exploiting undefined behavior".

"Exploiting undefined behavior" occurs when a simple semantics (however one defines "simple") results in behavior A, but the compiler chooses behavior B instead based on the actual, more complex, language semantics. The code snippet in question passes that test. If I flip the declaration order of i and arr, then I get this [1] at -O0 (the "simple" semantics):

        push    rbp
        mov     rbp, rsp
        mov     dword ptr [rbp - 4], 0
        mov     dword ptr [rbp - 4], 5
        mov     eax, dword ptr [rbp - 4]
        pop     rbp
        ret

Which indeed returns 5. But at -O2 clang optimizes it to this:

        xor     eax, eax
        ret

Which returns 0. So the simple semantics produces one result, and the complex semantics produces another. Hence, it's exploiting undefined behavior.

[1]: https://godbolt.org/z/df4dhzT5a

Note that if you change the code to this you have the same issue:

    int g(int n) {
        int arr[3], i = 0;
        arr[n] = 5;
        return i;
    }

Without "exploiting UB" it's incorrect to optimize this to "return 0", because of the possibility that i was allocated right after arr and n == 3.

Yeah, I would have liked to see the paper specify whether the LTO they tried is fat LTO or ThinLTO.

At FAANG scale the cost is prohibitive. Hence the investment in ThinLTO.

I notice that the paper doesn't claim to eliminate all reasoning about undefined behavior for optimizations. For example:

    int f() {
        int arr[3], i = 0;
        arr[3] = 5;
        return i;
    }

Optimizing this to "return 0" is relying on UB, because it's assuming that i wasn't laid out directly after arr in the stack frame. I believe this is what the paper calls "non-guardable UB".

I don't agree with the claim in the paper that their semantics offers a "flat memory model". A flat memory model would rule out the optimization above. Rather, the memory model still has the notion of object bounds; it's just simplified in some ways.

Nice to see this finally out! I wrote much of the GPU-driven rendering code for this release, which really helps Bevy's rendering performance with large scenes.