10 years ago, I commented on the Rust issue for "Incremental recompilation", where it was suggested that Rust could at least adopt Haskell GHC's model of incrementality, which is currently file-level:

https://github.com/rust-lang/rust/issues/2369#issuecomment-1...

This would already help a lot.

I recommend anybody who's interested in incremental recompilation to read what GHC does, because the effort to achieve that is relatively low.

Of course there's always desire for more:

GHC currently needs to parse+typecheck+codegen a file before it can process other files that import it. Codegen is slow. Thus, there's currently demand split compilation into "stages", so that the next file can be typechecked after its imports have been just typechecked (not codegenned).

I would also enjoy if recompilation avoidance were to happen at the function level, not the file level.

Macro systems are a key language feature that can destroy incremental recompilation. In theory, Haskell is well set up for that, as its macro system (TemplateHaskell) is fully AST based and _theoretically_ could distinguish "fully pure" macros from side-effectful macros (such as splicing the current git commit in as a string literal). But the recompilation avoidance system does not currently exploit such differences.

▲

steveklabnik 2 hours ago | parent | next [-]

Just to be clear about it, Rust today does do some amount of incremental compilation, and there is more work being done to continue to make it moreso. It's just very difficult to re-architect such a large and heavily used codebase. People are putting in heroic amounts of effort to improve things.

An example that's being funded right now: https://rust-lang.github.io/rust-project-goals/2026/expansio...

▲

amelius an hour ago | parent | prev [-]

Can't we have a system where we trade some performance for quick incremental compilation?

We can always compile with full optimization just before shipping?

	▲	steveklabnik an hour ago \| parent \| next [-]
		The article gestures at (and the author has made a comment in this thread about) how this is the case for Zig. You are right that there is tension here, and so that's exactly what you do: accept less performance for the gains in incremental, and then don't do incremental for final builds. It's a fine way to go about it, assuming that the lack of performance doesn't make the program unusuable. (Some people add some basic optimizations to their Rust debug builds, for example, because no optimizations is too painful to actually use.)
	▲	pjmlp an hour ago \| parent \| prev [-]
		Of course we can, C++ even REPL and hot reloading tools. The main issue is that so far such tools haven't been a priority for Rust.