Hacker News Reader

Comment by pjmlp | Hacker News Reader

> Many games written in C++ also take ages to compile.

Only if they didn't took the effort to use binary libraries for third party dependencies, or using hot code reloading tools like Live++ or Visual Studio's hot reload for native code.

Granted, nothing prevents Rust to have similar options, but they don't seem to be a high priority currently.

View on HN

I mean... if you change the size of a type used by value in a bunch of other places downstream (the equivalent of the change in the video), none of what you're describing is going to help much with compile time, since it's not ABI compatible. For less invasive changes rustc already does a decent (not amazing) job of avoiding recompiling unchanged dependents. As far as initial compile time goes, precompiled binaries would definitely help (on non-overpowered hardware particularly), but initial compile time is not really a development bottleneck since people do not recompile from scratch all that often. I do think people dramatically underestimate how long they would spend waiting for the equivalent C++ libraries to compile when comparing from-scratch compilation times to Rust projects, though, but that's neither here nor there.

Mostly because compiling from scratch in C++ is seldom a thing outside FOSS environments, all frameworks in gamedev SDKs are binaries already.

By the way, Rust incremental compilation is broken again, yes I know of the workarounds.

When you say 'broken', what you mean is '1 out of every 50 compiles will need a clean of the incremental compiler artifacts, which adds maybe 30 seconds to the subsequent compile but doesn't mean recompiling dependencies'. To call it 'broken' is quite misleading, it's just a minor annoyance that will be gone in the next release cycle.

> This mitigates the effects of a known bug, #94124, which can cause deserialization errors (and panics) during compilation with incremental compilation turned on.

It looks broken to me.

Regardless of what gamedev SDKs with billions of dollars behind them do or do not do, initial compile time is simply not a major bottleneck for developer productivity for Veloren. What is a bottleneck is how long it takes from making a change to seeing it in-game after the initial compile. On that front, C++ and Rust are on pretty similar footing (at least when incremental compilation is working :P) and it mostly comes down to how much the project is prioritizing compile times.

No they are not, given that Visual Studio and Unreal both have C++ hot reload since ages, and there are other third party solutions like Live++.

C++ hot reload does not improve compile times beyond what you can do yourself via dynamic linking (and can't help at all within compilation units, or avoid recompiling dependencies when ABI-level stuff breaks--choosing to have relatively small and large numbers of compilation units, or discourage ABI-breaking changes, is absolutely a project-level choice). For stuff that's time sensitive to compile, Veloren already uses dynamic linking with automatic hot reloading with the correct configuration options. I agree it's not as convenient as having tooling to do it for you, but, again, there is a lot more money in that stuff than there is in Rust game development right now.

Fair enough and as I mentioned, "nothing prevents Rust to have similar options", so I don't want to make this a kind of C++ vs Rust kind of thing.

All the best for the project.

Reply on news.ycombinator.com