5 ms·

> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. The rust compiler is very slow. The best

> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction, whereas Rust asks that you think in terms of ownership. This is not preferable ergonomics to many. I realize what I'm saying above, while true, doesn't give a clear example. Many gamedevs would rather iterate with a language that is lower friction, not only because game code is finnicky (like frontend UI code) but because the build process can be unique. Many gamedevs prefer to iterate with hot-reloading, and asking them to use a slower compiler is asking them to accept greater latency in that cycle. I do not claim that these reasons apply to everyone.

gpm 3mo ago
The comment you're replying to wasn't arguing rust > GCed languages (e.g. C# or whatever game dev language you are thinking of). It was arguing rust > non-GC non-safe languages (e.g. zig).
- leecommamichael 3mo ago
  I see that now, thanks. There's a lot to say here, especially with other approaches to memory management. My overall goal was to give them some context that wasn't their own.
kibwen 3mo ago
> The best way to speed it up appears to be organizing a codebase in many crates. A "crate" in Rust is the unit of compilation. In C, a file is the unit of compilation. Rust just lets you have a compilation unit that's composed of more than one file (without having to resort to C-style textual inclusion). But if you want, you can certainly have one-file-per-crate, just like you would in C. And what's nice about having many crates is that crates forbid circular dependencies, which trivially enables coarse-grained parallelism in the build system. So yes, organizing a large codebase into crates is the best way to achieve parallelism, but that isn't something to be deplored (and strictly controlling circular dependencies is useful for comprehending large codebases in general).
- comex 3mo ago
  The forbidding of circular dependencies is exactly what makes it hard to achieve parallelism! It means you have to draw nice clean module boundaries and split your compilation units there. Clean boundaries sound nice, except… what if the module is getting large? Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors? In C, usually yes. In C++, sometimes yes. It depends on how template-heavy the code is, but if you have some discipline you can keep most logic out of headers and thus easily splittable. In Rust, almost always no, because of circular dependencies. You can try to work around it by adding `dyn Trait` everywhere, but that requires a lot of code changes and comes at big ergonomic costs (and a small runtime cost). Which is why in practice, Rust compilation units are almost always larger than C++ or C compilation units. Rust can sometimes be competitive with C++ on compilation speed anyway, thanks to a smarter build system and not having to re-parse headers a billion times, but usually it's slower.
  - FridgeSeal 3mo ago
    > Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors?…In Rust, almost always no, because of circular dependencies This feels like a strange, overly-specific complaint. It reads a bit like “When I write entangled code, it’s hard to untangle”. Like, yeah, the only thing that’ll save you from that is…not writing entangled code? I’m not of the opinion that the argument of “yeah but C lets me do whacky stuff” is a particularly strong line. FWIW, letting a module grow, and then splitting modules up by cut-and-pasting stuff out along natural domain lines generally _is_ how I write Rust. Largely due to how easy it makes it to construct modules and submodules.
    - comex 3mo ago
      I addressed some of these points in my reply to a sibling comment: https://news.ycombinator.com/item?id=48856158 https://news.ycombinator.com/item?id=48856158 I may have been a little overly specific, since there are other issues besides cycles that also block splitting crates apart, but from what I’ve seen it’s very common for modules within a crate to have cyclic dependencies and therefore not be easily factorable into separate crates.
zamalek 3mo ago
Game engines are typically in two languages, one for the engine itself and one for scripting. That even goes for Unity: in Unity, C# is a significantly more powerful than average scripting language (for lack of a better term), but the engine itself is still C++. That's not to say that you couldn't write a commercial game engine with something like C# that stands shoulder-to-shoulder with unity and unreal, but it doesn't seem like anyone has attempted to do so. Maybe it's the decompilation fear. Also, it would continue to make sense to use a scripting language alongside Rust.
- atrevbot 3mo ago
  As someone who has almost no familiarity with game engines, it seems the success of this port was largely possible due to a comprehensive test suite written in a runtime agnostic way. What might be the equivalent test suite implementation required to successfully port a game engine to another language?
  - zamalek 3mo ago
    One option would be to have an input replay alongside captured outputs (audio visual), at some fixed framerate. Capturing intermediates (scene graph etc.) would probably also be valuable, as that could help nail down why something is failing. Or you could do it [as I recall the project being called] the scientist way. You still have the old code, so you could replay inputs against each and compare. Probably more realistic because uncompressed video would be a ridiculously huge dataset. This would be more resilient in the face of testing hardware and driver drift. Historically game engines are the worst offenders when it comes to unit testing. I'm not sure if that's still the case - but that's why I erred on the side of integration tests.
    - hdjrudni 3mo ago
      Box3D just showcased some stuff including deterministic replays. If you wanted to port that, you could probably import the replay and make sure it plays back the same way in your new language. I think it captures the inputs and forces applied, not the pixels. I suppose rendering is a component of a game engine too though, not just physics. I don't know how to do that reliably. Even if you captured pixels, it'd be annoying. If you've ever tried doing screenshot based diffing on web you will know that slight changes in aliasing in Chrome bugger everything up. Things that should be equivalent randomly aren't but not in a way that any human would care.
vlovich123 3mo ago
For what it’s worth game devs often use C# or C++ engines which have even worse issues. Rust also has the early beginnings of hot reload which bevy adopted if I recall correctly [1]. I still think a higher level language is good for “business” logic to orchestrate how efficient low-level pieces connect, but Rust is holding its own even against those use cases IMHO. [1] https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/ https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/
- Rohansi 3mo ago
  > For what it’s worth game devs often use C# or C++ engines which have even worse issues. Such as? You can't be referring to hot reload alone because you can already do that in both C++ and C#.
  - vlovich123 3mo ago
    Well for c++ memory safety and sharp abstractions and even worse compile times than Rust. I’m not aware of hot reload really being done in c++ at any scale but I’m not a game dev so I’m open to learning. C# AFAIK holds a minor place in gamedev and also has slow compile times maybe? I assume it has better support for hot reload times. But generally the performance profile isn’t there for the most demanding games even if the DX is.
    - Rohansi 3mo ago
      It's not specific to game dev but Visual Studio has hot reload for C++ that you should be able to make use of. C# compile times are fast. Performance is a lot better than you probably think, especially with modern .NET (not what Unity uses).
      - vlovich123 3mo ago
        Visual Studio limitations around hot reload are quite unrealistic for any serious codebase and only work on Windows with Visual Studio when you started it under a debugger. Rust’s hot reload is cross platform if I recall correctly and is always available until you disable it from the build (eg debug on, release off). It also has a better story for working around the limitations that Visual Studio just throws up on. C++ hot reload is not a common experience in the ecosystem.
stymaar 3mo ago
> The rust compiler is very slow. It's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it. > The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.
- minraws 3mo ago
  As much as I like Rust, > In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero. Is not true, you can't have circular out of crate dependencies. This often means you now need a third crate that's a trait crate, but then you can't implement external traits on external types, so you need bridge crates, and so on. Rust's limitation of performance requiring lots of crates indeed has real impacts on projects beyond simple hello worlds or trivial cli apps. Considering it to be a zero impact issue is rather reductive, even in the context of the language's design principles itself. Rust for all it's good sides has had a lack of interest from core team and energy to drive real valuable changes beyond the nightly blockers into stable, or maybe they are working real hard and the boulders are so hard to move that we can't see any change looking outside in. Is it justified after the gargantuan effort that was merging Async and GATs? Yes. But acknowledging the problem doesn't help us solve it. This is to say, Rust is an amazing labour of love project that seems rather stuck in time due to lack of investment/time/effort or all of the above, I am not sure, but it's moving slower than I would like, at solving the problems Rust developers face everyday. And yes Rust compiler is slow (very slow is arguable, compared to modern C++ it isn't that bad, but compared to say Go without cgo, its horrid), Cargo is just bad, without proper hermetic builds and stuff, even when I setup sccache for our team and our cache hit rate remained below 20% and most of it was just C++ deps hitting the cache. Just to be clear Zig builds are quite slow too, especially on windows where debug builds also use llvm. TBH Zig debug builds on Linux also don't really feel that fast, C still compiles faster for me by a considerable margin. Either way as someone doing Rust everyday for last 8+ years, 5+ in small/large teams, I have lots of complaints and I am sad, it has been over years of me complaining without nearly enough progress, they have a survey declare ambitions, and then well... things just don't move much.. not nearly as much as I would have expected. Honestly given I have been a rust dev for over half a decade now, I should instead of commenting here probably be figuring out if I can contribute to Rust to help things along (faster?). But most meetings and discussions happen at very EU/US centric times, and number of non US/European core contributors in Rust is also rather small(I don't know of one but I hope there are a few) so as someone not in those circles, I don't have the energy to figure out my way in, with my day job. Tldr; Is Rust the language for the job here, likely. But the question should be why couldn't have been the language Bun was written from the very start. Why does Zig or C++ or C seem so much more productive. Sorry for ranting about this but this felt a little relevant since you claimed people complaining, are likely people who have never worked with Rust.
psychoslave 3mo ago
Hey thanks for teaching me a word today, and to be finicky myself, the convention seems to be to use a single n it. :)
IshKebab 3mo ago
> The rust compiler is very slow. It was very slow. It's gotten a lot faster over time (over 2x faster). It's still not exactly fast, but it's definitely faster than C++. Although C++'s slow compile times are often complained about they were never really enough to stop most people using it, including for games. > a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction I'd be careful about that "without any added friction". Rust's lifetime/borrowing system tends to lead to less buggy code because it encourages structuring code in a less spaghetti way. GC does eliminate memory errors but you also lose that non-spaghetti code structure.
- pjmlp 3mo ago
  Because contrary to Rust, C and C++ have a culture of binary libraries. You are seldom compiling the world from scratch. Especially in the platforms dear to game devs.
  - IshKebab 3mo ago
    > You are seldom compiling the world from scratch. True in Rust too though - you're normally doing incremental compiles. And even though you're compiling the world, it's still on par with C++. For example I just tried compiling a hello world Bevy project, which has 462 crate dependencies - pretty big. It took 2m20. Totally reasonable to build an entire game engine and all it's dependencies. I wish they had reported the compile time of Bun before/after the Rust port - that would have been very interesting.
    - pjmlp 3mo ago
      Yeah but compiling full Unreal from scratch already requires going down the path of forking it for own purposes. Same applies to most commercial libraries, where code is usually provided for debugging purposes, not for building everything from scratch. Also incremental linking on Rust, or hot code reloading is still not something that works out of the box. How beefy is that machine to achieve 2m20? I started using C++ on MS-DOS, on a 20 MHz 386SX PC with 2MB RAM and 20 MB HDD. Especially relevant in current times.
thayne 3mo ago
> Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) Languages with garbage collection are generally considered "memory safe". GP was talking about choosing a language that requires manual memory management, but doesn't have something like rust's lifetimes to catch things like use-after-free.

gpm 3mo ago

The comment you're replying to wasn't arguing rust > GCed languages (e.g. C# or whatever game dev language you are thinking of). It was arguing rust > non-GC non-safe languages (e.g. zig).

leecommamichael 3mo ago
I see that now, thanks. There's a lot to say here, especially with other approaches to memory management. My overall goal was to give them some context that wasn't their own.

kibwen 3mo ago

> The best way to speed it up appears to be organizing a codebase in many crates. A "crate" in Rust is the unit of compilation. In C, a file is the unit of compilation. Rust just lets you have a compilation unit that's composed of more than one file (without having to resort to C-style textual inclusion). But if you want, you can certainly have one-file-per-crate, just like you would in C. And what's nice about having many crates is that crates forbid circular dependencies, which trivially enables coarse-grained parallelism in the build system. So yes, organizing a large codebase into crates is the best way to achieve parallelism, but that isn't something to be deplored (and strictly controlling circular dependencies is useful for comprehending large codebases in general).

comex 3mo ago
The forbidding of circular dependencies is exactly what makes it hard to achieve parallelism! It means you have to draw nice clean module boundaries and split your compilation units there. Clean boundaries sound nice, except… what if the module is getting large? Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors? In C, usually yes. In C++, sometimes yes. It depends on how template-heavy the code is, but if you have some discipline you can keep most logic out of headers and thus easily splittable. In Rust, almost always no, because of circular dependencies. You can try to work around it by adding `dyn Trait` everywhere, but that requires a lot of code changes and comes at big ergonomic costs (and a small runtime cost). Which is why in practice, Rust compilation units are almost always larger than C++ or C compilation units. Rust can sometimes be competitive with C++ on compilation speed anyway, thanks to a smarter build system and not having to re-parse headers a billion times, but usually it's slower.
- FridgeSeal 3mo ago
  > Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors?…In Rust, almost always no, because of circular dependencies This feels like a strange, overly-specific complaint. It reads a bit like “When I write entangled code, it’s hard to untangle”. Like, yeah, the only thing that’ll save you from that is…not writing entangled code? I’m not of the opinion that the argument of “yeah but C lets me do whacky stuff” is a particularly strong line. FWIW, letting a module grow, and then splitting modules up by cut-and-pasting stuff out along natural domain lines generally _is_ how I write Rust. Largely due to how easy it makes it to construct modules and submodules.
  - comex 3mo ago
    I addressed some of these points in my reply to a sibling comment: https://news.ycombinator.com/item?id=48856158 https://news.ycombinator.com/item?id=48856158 I may have been a little overly specific, since there are other issues besides cycles that also block splitting crates apart, but from what I’ve seen it’s very common for modules within a crate to have cyclic dependencies and therefore not be easily factorable into separate crates.

zamalek 3mo ago

Game engines are typically in two languages, one for the engine itself and one for scripting. That even goes for Unity: in Unity, C# is a significantly more powerful than average scripting language (for lack of a better term), but the engine itself is still C++. That's not to say that you couldn't write a commercial game engine with something like C# that stands shoulder-to-shoulder with unity and unreal, but it doesn't seem like anyone has attempted to do so. Maybe it's the decompilation fear. Also, it would continue to make sense to use a scripting language alongside Rust.

atrevbot 3mo ago
As someone who has almost no familiarity with game engines, it seems the success of this port was largely possible due to a comprehensive test suite written in a runtime agnostic way. What might be the equivalent test suite implementation required to successfully port a game engine to another language?
- zamalek 3mo ago
  One option would be to have an input replay alongside captured outputs (audio visual), at some fixed framerate. Capturing intermediates (scene graph etc.) would probably also be valuable, as that could help nail down why something is failing. Or you could do it [as I recall the project being called] the scientist way. You still have the old code, so you could replay inputs against each and compare. Probably more realistic because uncompressed video would be a ridiculously huge dataset. This would be more resilient in the face of testing hardware and driver drift. Historically game engines are the worst offenders when it comes to unit testing. I'm not sure if that's still the case - but that's why I erred on the side of integration tests.
  - hdjrudni 3mo ago
    Box3D just showcased some stuff including deterministic replays. If you wanted to port that, you could probably import the replay and make sure it plays back the same way in your new language. I think it captures the inputs and forces applied, not the pixels. I suppose rendering is a component of a game engine too though, not just physics. I don't know how to do that reliably. Even if you captured pixels, it'd be annoying. If you've ever tried doing screenshot based diffing on web you will know that slight changes in aliasing in Chrome bugger everything up. Things that should be equivalent randomly aren't but not in a way that any human would care.

vlovich123 3mo ago

For what it’s worth game devs often use C# or C++ engines which have even worse issues. Rust also has the early beginnings of hot reload which bevy adopted if I recall correctly [1]. I still think a higher level language is good for “business” logic to orchestrate how efficient low-level pieces connect, but Rust is holding its own even against those use cases IMHO. [1] https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/ https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/

Rohansi 3mo ago
> For what it’s worth game devs often use C# or C++ engines which have even worse issues. Such as? You can't be referring to hot reload alone because you can already do that in both C++ and C#.
- vlovich123 3mo ago
  Well for c++ memory safety and sharp abstractions and even worse compile times than Rust. I’m not aware of hot reload really being done in c++ at any scale but I’m not a game dev so I’m open to learning. C# AFAIK holds a minor place in gamedev and also has slow compile times maybe? I assume it has better support for hot reload times. But generally the performance profile isn’t there for the most demanding games even if the DX is.
  - Rohansi 3mo ago
    It's not specific to game dev but Visual Studio has hot reload for C++ that you should be able to make use of. C# compile times are fast. Performance is a lot better than you probably think, especially with modern .NET (not what Unity uses).
    - vlovich123 3mo ago
      Visual Studio limitations around hot reload are quite unrealistic for any serious codebase and only work on Windows with Visual Studio when you started it under a debugger. Rust’s hot reload is cross platform if I recall correctly and is always available until you disable it from the build (eg debug on, release off). It also has a better story for working around the limitations that Visual Studio just throws up on. C++ hot reload is not a common experience in the ecosystem.

stymaar 3mo ago

> The rust compiler is very slow. It's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it. > The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.

minraws 3mo ago
As much as I like Rust, > In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero. Is not true, you can't have circular out of crate dependencies. This often means you now need a third crate that's a trait crate, but then you can't implement external traits on external types, so you need bridge crates, and so on. Rust's limitation of performance requiring lots of crates indeed has real impacts on projects beyond simple hello worlds or trivial cli apps. Considering it to be a zero impact issue is rather reductive, even in the context of the language's design principles itself. Rust for all it's good sides has had a lack of interest from core team and energy to drive real valuable changes beyond the nightly blockers into stable, or maybe they are working real hard and the boulders are so hard to move that we can't see any change looking outside in. Is it justified after the gargantuan effort that was merging Async and GATs? Yes. But acknowledging the problem doesn't help us solve it. This is to say, Rust is an amazing labour of love project that seems rather stuck in time due to lack of investment/time/effort or all of the above, I am not sure, but it's moving slower than I would like, at solving the problems Rust developers face everyday. And yes Rust compiler is slow (very slow is arguable, compared to modern C++ it isn't that bad, but compared to say Go without cgo, its horrid), Cargo is just bad, without proper hermetic builds and stuff, even when I setup sccache for our team and our cache hit rate remained below 20% and most of it was just C++ deps hitting the cache. Just to be clear Zig builds are quite slow too, especially on windows where debug builds also use llvm. TBH Zig debug builds on Linux also don't really feel that fast, C still compiles faster for me by a considerable margin. Either way as someone doing Rust everyday for last 8+ years, 5+ in small/large teams, I have lots of complaints and I am sad, it has been over years of me complaining without nearly enough progress, they have a survey declare ambitions, and then well... things just don't move much.. not nearly as much as I would have expected. Honestly given I have been a rust dev for over half a decade now, I should instead of commenting here probably be figuring out if I can contribute to Rust to help things along (faster?). But most meetings and discussions happen at very EU/US centric times, and number of non US/European core contributors in Rust is also rather small(I don't know of one but I hope there are a few) so as someone not in those circles, I don't have the energy to figure out my way in, with my day job. Tldr; Is Rust the language for the job here, likely. But the question should be why couldn't have been the language Bun was written from the very start. Why does Zig or C++ or C seem so much more productive. Sorry for ranting about this but this felt a little relevant since you claimed people complaining, are likely people who have never worked with Rust.

psychoslave 3mo ago

Hey thanks for teaching me a word today, and to be finicky myself, the convention seems to be to use a single n it. :)

IshKebab 3mo ago

> The rust compiler is very slow. It was very slow. It's gotten a lot faster over time (over 2x faster). It's still not exactly fast, but it's definitely faster than C++. Although C++'s slow compile times are often complained about they were never really enough to stop most people using it, including for games. > a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction I'd be careful about that "without any added friction". Rust's lifetime/borrowing system tends to lead to less buggy code because it encourages structuring code in a less spaghetti way. GC does eliminate memory errors but you also lose that non-spaghetti code structure.

pjmlp 3mo ago
Because contrary to Rust, C and C++ have a culture of binary libraries. You are seldom compiling the world from scratch. Especially in the platforms dear to game devs.
- IshKebab 3mo ago
  > You are seldom compiling the world from scratch. True in Rust too though - you're normally doing incremental compiles. And even though you're compiling the world, it's still on par with C++. For example I just tried compiling a hello world Bevy project, which has 462 crate dependencies - pretty big. It took 2m20. Totally reasonable to build an entire game engine and all it's dependencies. I wish they had reported the compile time of Bun before/after the Rust port - that would have been very interesting.
  - pjmlp 3mo ago
    Yeah but compiling full Unreal from scratch already requires going down the path of forking it for own purposes. Same applies to most commercial libraries, where code is usually provided for debugging purposes, not for building everything from scratch. Also incremental linking on Rust, or hot code reloading is still not something that works out of the box. How beefy is that machine to achieve 2m20? I started using C++ on MS-DOS, on a 20 MHz 386SX PC with 2MB RAM and 20 MB HDD. Especially relevant in current times.

thayne 3mo ago

> Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) Languages with garbage collection are generally considered "memory safe". GP was talking about choosing a language that requires manual memory management, but doesn't have something like rust's lifetimes to catch things like use-after-free.