# World age warning on debugger

**URL:** <https://discourse.julialang.org/t/world-age-warning-on-debugger/135579>\
**Category:** VS Code\
**Tags:** debug\
**Created:** [February 11, 2026, 5:07pm UTC](https://discourse.julialang.org/t/world-age-warning-on-debugger/135579 "2026-02-11T17:07:19Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![ryofurue](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ryofurue/32/24531_2.png) [@ryofurue](https://discourse.julialang.org/u/ryofurue)\
**Post date:** [February 11, 2026, 5:07pm UTC](https://discourse.julialang.org/t/world-age-warning-on-debugger/135579/1 "2026-02-11T17:07:19Z")

</div>

I’m quite new to VS Code. I just started to use it several days ago. I’m already comfortable in editing Julia code on it. I use the official Julia extension.

When I run the debugger on a module, however, it warns about world-age issues on all my functions, even when the module includes only `function` statements and `using` statements for standard modules. There is absolutely no global variables, `include` statements, or any function calls at the module top level.

But then, searching this forum, I found only old threads about the VS Code Julia debugger. So, I wonder what’s going on.

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [February 11, 2026, 5:15pm UTC](https://discourse.julialang.org/t/world-age-warning-on-debugger/135579/2 "2026-02-11T17:15:25Z")

</div>

> [@ryofurue](#):
>
> When I run the debugger on a module

What does that mean exactly?

FWIW, I’d always recommend running very specific code in the debugger, e.g. with `@run`/`@enter`.

---

<div class="post-metadata">

**Author:** ![ryofurue](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ryofurue/32/24531_2.png) [@ryofurue](https://discourse.julialang.org/u/ryofurue)\
**Post date:** [February 12, 2026, 4:56am UTC](https://discourse.julialang.org/t/world-age-warning-on-debugger/135579/3 "2026-02-12T04:56:00Z")

</div>

> [@pfitzseb](#):
>
> > [@ryofurue](#):
> >
> > When I run the debugger on a module
> 
> What does that mean exactly?

Thank you for your question, which by itself shows that “the debugger” (to me) isn’t well known in the Julia community!

1. Install the official Julia extension (author: julialang).
2. Open your Julia program/module.
3. Click on the “Run and Debug” button in the left-most side strip \> The “Run and Debug” pane shows up to the left of the editor tab.
4. Click on the “create launch.json file” link and save launch.json file which is automatically generated.
5. Come back to your Julia program (activate your Julia source code tab).
6. Click on the “play” ▶ button at the top of the “Run and Debug” pane.

Then, the debug session starts. If your code includes an error, the line is highlighted and a popup shows a detailed error diagnosis.

I thought that this is how debugging works on VS Code.

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [February 12, 2026, 11:17am UTC](https://discourse.julialang.org/t/world-age-warning-on-debugger/135579/4 "2026-02-12T11:17:06Z")

</div>

Yeah, that’s one way to to run the debugger.

I would typically recommend running a specific function in the debugger instead of your whole codebase though, mostly because of the slowness of the debugger and the overhead of having to start a new Julia session.

Take a look at [Debugging · Julia in VS Code](https://www.julia-vscode.org/docs/stable/userguide/debugging/#Debugging-code-from-the-REPL) for a more REPL-centric approach, which crucially doesn’t run all your top-level code through the debugger and therefore shouldn’t cause any world age issues.

---

<div class="post-metadata">

**Author:** ![ryofurue](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ryofurue/32/24531_2.png) [@ryofurue](https://discourse.julialang.org/u/ryofurue)\
**Post date:** [February 12, 2026, 2:23pm UTC](https://discourse.julialang.org/t/world-age-warning-on-debugger/135579/5 "2026-02-12T14:23:48Z")

</div>

> [@pfitzseb](#):
>
> Take a look at [Debugging · Julia in VS Code](https://www.julia-vscode.org/docs/stable/userguide/debugging/#Debugging-code-from-the-REPL) for a more REPL-centric approach

Thanks. At the top of the webpage you linked actually shows what I described in my previous post! So, it’s known and it’s not something obscure that nobody uses. Good.

> [@pfitzseb](#):
>
> I would typically recommend running a specific function in the debugger instead of your whole codebase though,

Can you elaborate on that? Currently my code looks like this:

```julia
module MyModule
using SomeStandardModule
function myfunc1(x, y, z)
   # . . . 
end
function myfunc2(a, b, c)
   # . . .
end
# . . . some more funcs . . .
function testing()
   # . . . do something meaningful with myfunc1(), myfunc2(), . . .
end
testing() # do the test
end # module MyModule

```

When I’m satisfied, I’ll comment out the function call `testing()` and use the module from other programs of mine.

The only advantage of the REPL method you mention is that it’s much faster than the debugger, is it?

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [February 13, 2026, 10:19am UTC](https://discourse.julialang.org/t/world-age-warning-on-debugger/135579/6 "2026-02-13T10:19:09Z")

</div>

That, and it doesn’t require you to comment stuff out that shouldn’t be there anyways.

The typical pattern in a case like yours is to remove the top-level `testing()` call and run something like

- `using MyModule`
- `julia> testing()`
- make changes, apply via Revise or inline evaluation
- `julia> testing()`
- make changes, apply via Revise or inline evaluation
- debug via `julia> @run testing()` after setting some breakpoints