Scaling Limitations of F# Toolchain / Tooling

[bryanedds]

From an internal discord monologue -

we appear to be on pace to hit around 90-100klocs of Nu engine code around the 2.0 release.
if we could imagine what Nu 3.0 might be - say for an engine of the sophistication of Unity - it would probably reach 250klocs.
unfortunately, the current F# tooling code in visual studio is starting to falter around 85klocs (debugger crashes when stepping too fast with local watch window up, very long time to update autocomplete tree at 30+ seconds w/ no notification it's even happening in VS, unlike ryder [maybe due to a bug in current VS F# tooling?])
without scalability enhancements on the F# tooling and compiler side (which I think are already the pipe, but not yet finished), VS will probably be well past screwed with 250kloc F# projects.
beyond that point, most of the new code should be able to be partitioned out to their own projects out side of Nu.fsproj.
the total gameplay code of a large AAA Nu game would probably reach about the same size, 250klocs (compared to, say, 2.5mlocs for a non-declarative AAA game implementation).
so we definitely need the tooling scalability improvements that are currently in the F# team's pipeline.
so another issue is that 250klocs is a lot of F# code to hot reload
seeing as how it takes about 1 second to reload 2kloc of F# code, a reload in the editor with a game of that size would take about 2 minutes.
which is about 10x longer than we'd consider reasonable for developer iteration time.

We understand that there are scalability improvements in the current F# compiler and tooling pipelines, particularly around supporting partial project recompilation. Hopefully this will be enough to help us scale into the largest likely F# game engine and game projects.