Oh did I get frustrated seeing "to make incremental compilation simpler to implement" in the latest 0.15.1 release notes...

I have no doubt incremental compilation will make many large projects easier to compile, and perhaps it really is the future of all compiled languages, but you're right, it's being wielded as a janky dismissal of many good ideas.

▲

kingstnap 6 days ago | parent [-]

Maybe maybe not.

Working with / testing systems that have huge input spaces is difficult. You have to stamp out lots of edge cases because the boundary of the space is huge.

Working with systems that both have huge input spaces but also have internal state is exponentially worse. You basically have edge cases to the power of edge cases to deal with.

Simultaneously, it's not always faster / easier to manage deltas in programming. As an example, consider the case of sorting a 1 million element list. How much difference is there between starting from completely scrambled vs. I instead told you it's mostly sorted, but only 1% of elements were out of place.

Its definitely not 99% easier let me tell you that.

	▲	tialaramex 6 days ago \| parent [-]
		It's complicated: https://github.com/Voultapher/sort-research-rs/blob/main/wri... The left chart there is the proposed (now current) Rust unstable sort, named IPN Sort and the right chart is the old (at the time current) unstable sort That nice black triangle line going straight up and to the right is random input, a typical input for testing sort performance. Compare those essentially flat lines at the bottom in orange and green, for the easy ascending and descending inputs (sorting them is no work, or trivial as appropriate) and the distinct brown circle s95 which is markedly worse than the black line. s95 is 95% sorted data, plus 5% random data, which is what you'd see if you: 1. sort container of N Things 2. do work which overall removes about 0.05 x N Things, maybe they're completed 3. add 0.05 x N Things, maybe they're new 4. repeat from step 1 Compared to the usual test workload this is actually more work because indeed it's mostly sorted but the non-sorted parts are far out of position. The vertical on these charts is mean comparisons per item, that is if we can sort 100 items with total 1000 comparisons, that scores 10 on the vertical axis, the reason to do this is that it's independent of physical realisation. Because the horizontal axis is log size a horizontal line means the sort is O(n) for that class of input, a diagonal means O(n log n) which is what we're hoping for from a sort algorithm.