Tweak error-prone Bevy fast-compiles advice

[alice-i-cecile]

Problem

Currently, the Bevy book encourages fussing with complex fast compilation setups.

Fast compile advice is very cool, but comes with a large numbers of caveats and often breaks in surprising ways: https://github.com/bevy-cheatbook/bevy-cheatbook/issues/135

It should not be introduced to beginners, even if it may be valuable to advanced users later.

Solution

• remove advice to set up fast compiles

This advice can and should be added back later, in a more appropriate location with carefully vetted caveats.

[cart]

The main reasons I chose to include it early:

• Iteration times are critical for gamedev. Slow compile times == bad impressions. We dont want to lose potential users early because they hate waiting around for 8 seconds (when they could be waiting < 2).
• Doing the fast compiles setup early (ideally before the first compile) means they dont need to "fully recompile" a second time, which could also leave bad impressions

I do agree that things should easily just work out of the box. I think ideally we recommend platform specific setups that are "approximately guaranteed to work". I do agree that the current recommendations make it too possible for users to "fail".

[cart]

We could also force compilation failures with solid error messages for platforms where dynamic linking wont work (ex: wasm).

[alice-i-cecile]

I agree with those positions, but have two concerns:

1. "Time to fun" is too high. There's already a frustrating amount of yak-shaving, especially for users who need to install a large number of depedencies.
2. The existing setups are too unreliable. I would much prefer to be able to link to e.g. the bevy_ci_template that we built for the jam with all of the little steps set up for each platform.

We could also force compilation failures with solid error messages for platforms where dynamic linking wont work (ex: wasm).

I really like this.

[alice-i-cecile]

I've removed the commit about depending on main: that's much less controversial and should be its own PR.

[cart]

Maybe theres a middle ground solution: only introduce the --dynamic feature in the beginning. Only encourage its use on platforms that support it out of the box (and link to a separate long-form fast compiles document for platforms with more complicated setups).

[alice-i-cecile]

Maybe theres a middle ground solution: only introduce the --dynamic feature in the beginning. Only encourage its use on platforms that support it out of the box (and link to a separate long-form fast compiles document for platforms with more complicated setups).

Yeah, I think this may be the way. Overall this deserves a comprehensive plan; I'll chew on what I think this should look like.

[superdump]

The main reasons I chose to include it early:

• Iteration times are critical for gamedev. Slow compile times == bad impressions. We dont want to lose potential users early because they hate waiting around for 8 seconds (when they could be waiting < 2).
• Doing the fast compiles setup early (ideally before the first compile) means they dont need to "fully recompile" a second time, which could also leave bad impressions

I do agree that things should easily just work out of the box. I think ideally we recommend platform specific setups that are "approximately guaranteed to work". I do agree that the current recommendations make it too possible for users to "fail".

If fast compile has not been up front like this then I would likely not have looked them up and then wasted a bunch of time for a long time. I feel like it’s good that it’s there in the getting started so you get a good environment setup. If it’s a stumbling block then we could provide a helper script or something to get going?

[inodentry]

I agree with @cart and @superdump that configuring for fast compiles is important and we should keep this section.

I think the real issue is that this section recommends some controversial/experimental things, that lead users to run into issues if they follow the advice blindly without fully understanding what they are doing.

1. Dynamic linking is great ... but we currently do not mention that it has issues on many platforms. It only works if you are iterating on a native desktop build, not if you are targeting WASM or mobile. IIRC it also has issues with Windows and MacOS (ive seen many ppl complain)? As in, it only reliably and easily works on Linux? This stuff should be noted.

2. Nightly compiler. This should be removed. Rust nightly has had regressions before, and the wins of experimental options like -Zshare-generics are pretty minor. This stuff falls into the category of "experimental tinkering for advanced users" IMO, not something we should recommend to all beginners.

The linker advice is great. Fast linkers like LLD, mold (speaking of, should we recommend mold instead of lld on linux?), zld, make a huge difference, and don't really break anything.

In all, I love that we are helping beginners get fast compiles. I also agree that we should be more careful with what exactly we recommend, so that users can get most benefit, without "over-optimizing" by enabling controversial things that may cause them issues for little extra gain.

Also, we should do a better job of pointing out that all of this is optional, and that each individual piece of advice is also optional. For example: someone tried out the linker, and it worked, but dynamic linking is not working for them? They should just move on, not fuss about trying to get the whole config working.

[speakk]

One option is to have the more advanced and error prone optimization steps moved to the end of the tutorial. This way time-to-fun is much faster, and those steps being optional is much more clear by the fact that they are at the end.

edit: Wow this was a useless comment now that re-read the thread with morning brain and not late night brain. So ignore this and carry on 👍

[cart]

Closing as this PR doesn't have any actual changes / has stalled. Feel free to open a new PR that makes any of the changes discussed.