# Is there some minimal list of packages (almost) all users should use?

**URL:** <https://discourse.julialang.org/t/is-there-some-minimal-list-of-packages-almost-all-users-should-use/47583>\
**Category:** General Usage\
**Created:** [October 1, 2020, 9:50am UTC](https://discourse.julialang.org/t/is-there-some-minimal-list-of-packages-almost-all-users-should-use/47583 "2020-10-01T09:50:10Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 1, 2020, 9:50am UTC](https://discourse.julialang.org/t/is-there-some-minimal-list-of-packages-almost-all-users-should-use/47583/1 "2020-10-01T09:50:10Z")

</div>

I do see e.g. brand new ConcreateStructs.jl but it may be too new, so I have established packages in mind at least.

I’m not thinking of e.g. some statistics package, but to add language features (and well Revise.jl), not something you would already get from say an IDE. E.g. people from coming from Scala would miss pattern matching, and I know it exists (in more than one package). I also see Underscores.jl and other similar.

Could I rely on the manual to document most of the default go-to packages? Maybe it does already (I know it mentions Cxx.jl and Cxxwrap.jl, ad probably mentions DataStructures.jl and possibly OrderedCollections.jl).

Maybe a subset of what JuliaPro included (or more? that curated list is likely outdated and had other priority?).

Note, I see:

> JuliaPro now ships with the [General registry](https://github.com/JuliaRegistries/General) […]
> 
> We have stopped shipping the JuliaPro registry. This registry used to be the default, and its purpose was to provide a slower, more stable, upgrade path for packages. However, we found that this causes confusion, and our plan is to provide this functionality via our [JuliaTeam](https://juliacomputing.com/products/juliateam) product. JuliaPro users will use the General registry by default. In additon we now ship an additional registry called _JuliaComputingRegistry_ .

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [October 1, 2020, 10:09am UTC](https://discourse.julialang.org/t/is-there-some-minimal-list-of-packages-almost-all-users-should-use/47583/2 "2020-10-01T10:09:12Z")

</div>

Since the default julia installation comes with a lot of stuff, you can do very much without any packages at all so I would say there isn’t really a set of “required” packages. Of course, there are some nice ones that are useful in a lot of cases. Some of my favourites are:

- Revise.jl
- Debugger.jl
- StaticArrays.jl
- Parameters.jl
- Cthulu.jl
- SnoopCompile.jl
- TimerOutputs.jl (self advertisement)

---

<div class="post-metadata">

**Author:** ![jakobnissen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jakobnissen/32/13477_2.png) [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)\
**Post date:** [October 1, 2020, 11:29am UTC](https://discourse.julialang.org/t/is-there-some-minimal-list-of-packages-almost-all-users-should-use/47583/3 "2020-10-01T11:29:22Z")

</div>

To continue the self-advertisement of Kristoffer, I’m also very fond of his OhMyREPL.jl package, and have it loaded by default.

---

<div class="post-metadata">

**Author:** ![lungben](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lungben/32/12314_2.png) [@lungben](https://discourse.julialang.org/u/lungben)\
**Post date:** [October 1, 2020, 12:19pm UTC](https://discourse.julialang.org/t/is-there-some-minimal-list-of-packages-almost-all-users-should-use/47583/4 "2020-10-01T12:19:06Z")

</div>

For working with data:

- DataFrames.jl
- CSV.jl
- JDF.jl (fast and compact, but Julia-specific binary storage format for tabular data)
- Plots.jl (or one of the alternative plotting packages)
- Pluto.jl / IJulia.jl (notebooks)
- BenchmarkTools.jl

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [October 1, 2020, 12:28pm UTC](https://discourse.julialang.org/t/is-there-some-minimal-list-of-packages-almost-all-users-should-use/47583/5 "2020-10-01T12:28:33Z")

</div>

BenchmarkTools and Profileview are the two I couldn’t live without.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [October 1, 2020, 12:43pm UTC](https://discourse.julialang.org/t/is-there-some-minimal-list-of-packages-almost-all-users-should-use/47583/6 "2020-10-01T12:43:12Z")

</div>

> [@Palli](#):
>
> Could I rely on the manual to document most of the default go-to packages?

To a certain extent yes (eg it [mentions Revise.jl](https://docs.julialang.org/en/v1/manual/workflow-tips/#Revise-based-workflows)), but beyond a very minimal core there is no universal agreement about a list “everyone” should use. Even the standard libraries don’t necessarily get used by every single Julia user.

I would not worry about this and just research and add packages on demand. Eg you want to debug performance, so add Cthulu etc.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 2, 2020, 11:04am UTC](https://discourse.julialang.org/t/is-there-some-minimal-list-of-packages-almost-all-users-should-use/47583/7 "2020-10-02T11:04:15Z")

</div>

There could be two separate lists, your is more about tools to help developers that would not be used in your final package (excluding StaticArrays) or script.

I guess I opened the door to that with mentioning Revise too “to add language features (and well Revise.jl)”.

What I had in mind are tools like Match.jl (the go-to-tool for pattern matching, right? while there are other options), and others adding “language features”, i.e. what would be built into other languages and people might miss out on as they simply do not know of. I suppose LispSyntax.jl would e.g. not make the cut for a minimal list. 🙂

> [@4 major problems of pattern matching in Julia](https://discourse.julialang.org/t/4-major-problems-of-pattern-matching-in-julia/34392):
>
> Despite of the notation issues of existing Julia macro libraries for pattern matching, based on my experience as a concerned user and developer, I hereby propose 4 major problems preventing us from bringing out good enough pattern matching, which I hope the authors and contributors of existing and future pattern matching libraries could pay attention to: Optimizations: merging and splitting (EDIT addition) cases/patterns using algorithms of analysing decision trees, thus users won’t need awa…

There are also several threading related packages, I didn’t check if mentioned in Julia’s docs.

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [October 2, 2020, 12:19pm UTC](https://discourse.julialang.org/t/is-there-some-minimal-list-of-packages-almost-all-users-should-use/47583/8 "2020-10-02T12:19:29Z")

</div>

It might be interesting to point out that at the end of triage yesterday, we were talking about the possibility of adding a few extra things to `InteractiveUtils` (`Cuthulu`, `BenchmarkTools`, and `Profile` were 3 of them). This would be combined with moving a lot of code that currently always gets loaded (eg `Pkg`) and make it only get loaded with `InteractiveUtills`. The net result of this would be a much smaller startup time for non-interactive uses (and a much smaller sysimage), while improving the plug and play nature of the repl by including a few of the batteries you were going to import anyway.