# Implicitly loaded modules in the future? **URL:** https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646 **Category:** Internals & Design **Tags:** question, module, code-organization **Created:** [June 9, 2021, 8:58pm UTC](https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646 "2021-06-09T20:58:00Z") **Posts on this page:** 1 **Showing post:** 38

### Author: ![sijo](https://avatars.discourse-cdn.com/v4/letter/s/da6949/32.png) [@sijo](https://discourse.julialang.org/u/sijo) #### Post date: [June 10, 2021, 6:42am UTC](https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646/38 "2021-06-10T06:42:09Z")

I also think `include` is not a great way to organize code and one of Julia’s weak spots. I compared it to Go in [another](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/41) thread: > In Go, you can’t include files: you can import packages and one package = one directory and _each file_ has an explicit list of imported packages at the top, and importing names in the main namespace (like `using` in Julia) is strongly discouraged. In Julia, files can include files can include files… Open a file, you don’t know in which context it is included so you can’t be sure how it’s going to be interpreted. Maybe it’s even included several times in different contexts? Maybe the behavior depends on the order of includes? > > Another way to put it: declarative (rather than imperative) code is generally considered more robust or at least easier to analyze and verify. In Go, you write imperative code in functions, but the overall organization (definition of packages and functions) is declarative. In Julia, this organization itself is imperative. Note that Jeff voiced some [agreement](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/63) 🙂 --- _[View the full topic](https://discourse.julialang.org/t/implicitly-loaded-modules-in-the-future/62646)._