Remix clone Hacker News

The disadvantage of doing a big refactor in Rust is that you can't do a partial refactor -- it won't compile until you've fixed everything.

The advantage of doing a big refactor in Rust is that you can't do a partial refactor -- it won't compile until you've fixed everything.

▲

echelon 15 hours ago | parent [-]

Why would you want a refactor into a broken state?

You always need to figure out how much you're going to bite off with each refactor. It's usually possible to do things incrementally.

▲

zsyllepsis 15 hours ago | parent | next [-]

I don’t think that’s what the parent was saying.

There are cases when refactoring Rust code where it’s possible to hit limits in the compiler related to e.g. lifetime inference. When these limits are hit, simple straightforward refactorings that are perfectly safe become more complicated - suddenly you’re forced to manually annotate lifetimes, and to thread those lifetimes through function calls, and…

And your small, incremental refactor suddenly isn’t. It doesn’t happen all that often, and they’re working to reduce how often users run into these challenges, but a number of cases like this still exist. And when you run into them it can be a frustrating experience.

	▲	estebank 10 hours ago \| parent [-]
		Personally I'm convinced that the solution to that is not for the language to be more implicit but rather to make tooling for refactoring more front and center. A task for "add a lifetime to this struct everywhere it's mentioned" is already catered to by modifying the original type and then applying rustfix, but more advanced but relatively common changes should also be mechanized away. The annotations are there not only for the benefit of the compiler but also the developers.

▲

jayd16 13 hours ago | parent | prev [-]

You might want to test some optimization or refactor without crossing all the Ts. Lost of reasons you'd want to quickly iterate without doing the maximum amount of work needed upfront.