Revise.jl: Editing a Running Julia Session Without a Restart

The restart tax Revise.jl is built to remove

Julia's compile-and-run model means a session accumulates state: loaded packages, compiled specializations, values you have been poking at. That state is useful right up until you change a line of source, at which point the usual answer is to quit and start over. The README frames the cost plainly: restarting means loading packages again and waiting for code to JIT-compile. Revise.jl targets that specific loop. The README states that you can be in the middle of a session and then update packages, switch git branches, or edit source in your editor, and that changes will typically be incorporated into the very next command you issue from the REPL. The audience is therefore narrow and identifiable: people doing interactive development or debugging in Julia, not people running batch jobs or CI, where a fresh process per run is normal and cheap. The project sits under developer-tools and reloading topics, which matches that scope.

JuliaInterpreter is what makes method replacement possible

The mechanism is not a source-level text substitution. According to the README, the 3.x and 2.x release cycles use JuliaInterpreter to step through your module-defining code. That phrasing matters: Revise is executing your module definitions under an interpreter so it can observe what gets defined, rather than only reading files. The 1.x cycle took a different route, not using JuliaInterpreter but integrating with Pkg.jl, and the README offers it as a fallback for users who hit trouble on the newer releases. So the architecture has two moving parts: a file watcher that notices edits, and a definition-tracking layer that knows which methods came from which file so it can replace them. The README also credits the change that made the whole idea feasible: Jameson Nash's fix of Julia issue 265. Without a runtime that permits redefining methods in place, none of this would be possible, and that dependency is worth understanding before you build a workflow on top of it.

Getting it into a session: startup.jl and the config path

The README points most users at a single change: alter your .julia/config/startup.jl file so Revise runs automatically, as described in the Configuration section of the documentation under the anchor Using-Revise-by-default-1. That is the recommended path rather than a per-session import. The reasoning is straightforward: a tool that only helps if you remember to load it first will be forgotten exactly when you need it, halfway through a debugging session. Putting it in startup.jl means every interactive Julia you launch has it active. The README does not spell out the exact line to add; it defers to the linked configuration page. If you want the precise call, read that page rather than guessing from the README, because the recommended form has changed across release cycles. Beyond that, the README gives no other setup commands, no environment variables, and no configuration keys, so anything you see elsewhere about Revise options should be checked against the stable documentation.

What Revise does not promise to catch

The README's own wording is hedged: changes will typically be incorporated into the very next command. Typically, not always. That is an honest description of a tool that works by tracking definitions, because some edits are not method-body edits. Changing a struct's field layout, altering a type parameter, or modifying top-level code that has already run is a different problem from swapping a function body, and the README does not claim to handle those cases. It also does not describe behaviour for macros, generated functions, or code loaded from paths outside the tracked set. The README further notes that the 1.x line exists for users who have trouble with the newer releases, which is an admission that the interpreter-based approach can misbehave in ways the maintainers expect to happen. Treat Revise as a fast path for the common case of editing a function body in a file it watches, and keep a restart in your back pocket for structural changes.

Editor integrations and the alternative of restarting cleanly

The README names Julia for VSCode and Juno as IDEs that offer an editor-based mechanism for achieving a subset of Revise's aims. That is the real alternative, and the difference is structural. An editor integration reloads what the editor knows about, tied to the files open in that editor and its own notion of what changed. Revise works at the Julia process level: it tracks definitions regardless of which editor wrote the file, which is why the README can say you can edit in the editor of your choice. The trade-off runs the other way too. An IDE integration is part of a tool you already run, so there is nothing extra to install or keep in startup.jl, and it may understand project structure better than a file watcher. Revise's advantage is that it is not bound to any editor, so switching between Vim, Emacs, VSCode or anything else does not change how reloading works. If you are already happy with how your IDE reloads code, Revise adds a second reloading mechanism rather than replacing the first.

Version churn, maintenance and the licence question

The release cadence visible in the repository is brisk: v3.16.4 on 2026-08-21, v3.16.5 on 2026-08-24, and v3.17.0 on 2026-08-30. Patch releases inside a week suggest active maintenance, and also that you should expect to update. The README's Major releases section is the part that affects upgrade cost: the 3.x and 2.x cycles both depend on JuliaInterpreter, while 1.x does not and instead integrates with Pkg.jl. Moving between those cycles is not a version bump, it is a change in how the tool does its job. The README tells users on 1.x to report problems on the newer releases first, which reads as a preference for keeping everyone on the current line. On licensing, the repository metadata reports NOASSERTION, meaning no recognised SPDX identifier was detected. That is a flag, not a verdict: read the LICENSE file in the repository and, if the terms matter for how you distribute your work, get proper advice rather than inferring anything from the package registry entry.

Editorial conclusion

Adopt Revise.jl if you spend your day in a long-lived Julia REPL and the restart, package-load and compile cycle is the thing slowing you down; skip it if your workflow already restarts Julia per test run or if you rely on editor tooling for reloads. Before trusting it, put Revise in .julia/config/startup.jl, then edit one method in a tracked file and confirm the next REPL call uses the new body. Also check the licence terms, since the repository reports NOASSERTION rather than a recognised SPDX identifier.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. timholy/Revise.jl on GitHub