I agree with most of what you said and share your frustration with the tooling of Julia. However, I am not sure how well I would expect a static checker to work for Julia. Julia after all is a dynamical language, and while you may disagree with that choice, the dynamical typing permeates the language. There is no pattern matching and no language features to manipulate types, for example. Julia's AST and IR share a lot in basic data structure thanks in large part to Julia's dynamical nature. Since adding static typing to Julia at the current stage of its development would be almost an upheaval, I am not counting on it.

This means there is an upper bound to how good the editing and refactoring tooling will be. I suspect the best will be a little below Pythong's tooling, because Python's class helps in disambiguating methods.

One feature of Julia I think could be improved upon is the `include` statement to import code, similar to C's `include` macro directive. This makes finding functions within a package an absolute nightmare. I think this also restricts LSP's ability to find definition and usage since this tends to make Julia packages one big source file as far as the compiler is concerned. I saw that in Julia's compiler code, the core developers include C source files, not header files mind you, in other C source files, so perhaps the feature stems from their personal preference. Python's file-module may be too restricting, but Julia's including is too loose.