# Julia packages that have no equivalents in other languages?

**URL:** <https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646>\
**Category:** Teaching & Outreach\
**Created:** [July 14, 2021, 4:59pm UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646 "2021-07-14T16:59:02Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![brenhinkeller](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/brenhinkeller/32/36648_2.png) [@brenhinkeller](https://discourse.julialang.org/u/brenhinkeller)\
**Post date:** [July 15, 2021, 2:19am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/21 "2021-07-15T02:19:13Z")

</div>

DifferentialEquations.jl is probably the canonical example of a Julia package with no real equal in other languages (particularly including the composability with other packages like Flux, and at this point really the whole SciML ecosystem)

---

<div class="post-metadata">

**Author:** ![brenhinkeller](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/brenhinkeller/32/36648_2.png) [@brenhinkeller](https://discourse.julialang.org/u/brenhinkeller)\
**Post date:** [July 15, 2021, 2:22am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/22 "2021-07-15T02:22:55Z")

</div>

There’s also almost certainly nothing like Unitful.jl or Measurements.jl in any other language (kinda really need multiple dispatch to just be able to pop units or uncertainties on to your existing code like that).

For my own work LoopVectorization.jl is probably the overall MVP, and while there is SIMD vectorization in other languages, the ease of use of LV is pretty exceptional.

---

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [July 15, 2021, 5:53am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/23 "2021-07-15T05:53:45Z")

</div>

`UnitfulRecipes` feels like something that pretty much _can’t_ exist in other languages.

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [July 15, 2021, 7:00am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/24 "2021-07-15T07:00:11Z")

</div>

Personally I’m hoping Makie will be designed so it doesn’t need a special FoobarRecipies package and will just work automatically with whatever types I put into it.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [July 15, 2021, 7:08am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/25 "2021-07-15T07:08:49Z")

</div>

> [@rafael.guerra](#):
>
> sorry for the basic question, but what are the applications of LongestPath.jl?

I told you it’s niche. 😉

I developed it because I wanted to know how long a game of 3x3 go can be without repetitions, but that’s still to be determined. I have been able to bound the number to the interval [4692, 4810], which is a lot better than was known earlier. For a generalization of that problem, see [GitHub - GunnarFarneback/GoGameGraphs](https://github.com/GunnarFarneback/GoGameGraphs).

If someone knows of an industrial or more theoretically important application, I’m all ears.

---

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [July 15, 2021, 7:41am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/26 "2021-07-15T07:41:12Z")

</div>

I think the recipes system is elegant. The reason we need `xRecipes.jl` is that there is not (yet) first class support for optional dependencies. It will be hard for Makie, or any other package, to do better.

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [July 15, 2021, 7:50am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/27 "2021-07-15T07:50:11Z")

</div>

But isn’t this exactly what Plots avoids by just having `RecipesBase` for the package defining the type to depend on, and then the user just calling `using MyPackage, Plots` (without any `MyPackageRecipes`)? My understanding was always that Makie set out to allow for the same, and that it even did at some point, but that that support has bitrotted (sorry verry off topic here, might need to split this out!)

---

<div class="post-metadata">

**Author:** ![blackeneth](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/blackeneth/32/10353_2.png) [@blackeneth](https://discourse.julialang.org/u/blackeneth)\
**Post date:** [July 15, 2021, 8:03am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/28 "2021-07-15T08:03:49Z")

</div>

Python has the Global Interpreter Lock (GIL). Julia has the advantage of being designed in the multithreaded/multicore/multiprocessor era.

Python packages can get around the GIL by using C or C++. Thus Python is the poster child for the two language problem. Why use Python at all – just learn C++ instead (which isn’t as daunting as its reputation).

With Julia, you can write your package in Julia and have it be fast. Some of the most interesting posts on this forum are when a user posts a question, “how can I make X go faster?” Then the community responds with suggestions that make it two orders of magnitude faster.

Julia also has support for Unicode in strings, which is often a bolt-on in older languages. Julia also supports Unicode symbols written in the code, so one can use, for example, θ as a variable in the code and not a word equivalent such as _theta_.

Julia has first class support for _missing_ values. Very important for statistics.

In addition to asking what Julia has that others do not, you might also ask about the beneficial things that Julia _doesn’t have._

For example, there is no Numpy and it’s _170 page manual._ It’s just built into Julia.

Julia is not so goddamned object oriented as Python. See [All evidence points to OOP being bullshit](https://tanzu.vmware.com/content/blog/all-evidence-points-to-oop-being-bullshit).

Finally, computers are faster than we think they are. The hardware today is capable of sustained computations that were previously found only in supercomputers. _As long as the software doesn’t hold you back._ I don’t like to wait around, so I want my computer to perform to its potential. I also don’t want to consult a 170 page manual on how to compute X(X’X)X’ efficiently.

So I like Julia. It may not have everything yet – but it has the right concept and philosophy to be an approachable, yet highly performant language.

---

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [July 15, 2021, 8:20am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/29 "2021-07-15T08:20:32Z")

</div>

Yes, but commonly used packages like Unitful and BenchmarkTools are rightfully cautious about pulling in dependencies, even as lightweight as RecipesBase.

---

<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:** [July 15, 2021, 8:30am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/30 "2021-07-15T08:30:51Z")

</div>

> [@Erasmo98](#):
>
> I think a good argument could be that there are things that are difficult to do in other languages, for instance because there is no suitable package.

I would choose a different approach. I think that the best argument for Julia is that _if the exact functionality you are looking for is not available in a package, you are still fine_, as you can easily compose existing pieces and write the necessary code.

Treating a package ecosystem of a language as a given, static feature is misleading, but historically justified, as most languages make implementing large and complex functionality very costly. Large C++ libraries can have tens or hundreds of thousands of person-hours in them.

But Julia is different: experienced Julia programmers isolate problems to small, composable pieces, usually packaged as such, and can combine existing functionality with their own custom code easily. Most of the great packages mentioned in this topic were born that way. I would recommend this video for your students:

[![](https://global.discourse-cdn.com/julialang/original/3X/c/5/c5a2f02c81c376da005f8610ce9cdd4ad47cfdf4.jpeg "JuliaCon 2019 | The Unreasonable Effectiveness of Multiple Dispatch | Stefan Karpinski") ](https://www.youtube.com/watch?v=kc9HwsxE1OY)

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [July 15, 2021, 10:34am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/31 "2021-07-15T10:34:49Z")

</div>

> [@brenhinkeller](#):
>
> There’s also almost certainly nothing like Unitful.jl or Measurements.jl in any other language

[`uncertainties`](https://github.com/lebigot/uncertainties) and [`pint`](https://github.com/hgrecco/pint) in Python do that.

What they lack is composability with external packages, `uncertainties` has [an entire module](https://github.com/lebigot/uncertainties/tree/c4d9b9926ff0d1fc4009bec677f2e210dd715bdf/uncertainties/unumpy) to allow for numpy arrays of numbers with errors, `Measurements.jl` has exactly zero lines of code to enable creating arrays of `Measurement` objects, they just work. Most of the features mentioned for [future development](https://uncertainties-python-package.readthedocs.io/en/latest/#future-developments) of `uncertainties` don’t require any work at all in `Measurements.jl` (like complex quantities, FFT, etc…).

`pint` needs some [glue code](https://github.com/hgrecco/pint/blob/3a428c2814966af7971f87412d5df47bb307f8d0/pint/measurement.py) to integrate with `uncertainties`. Similarly, if you want to use `uncertainties` with other Python packages which didn’t write some specific glue code to integrate with it, you’re out of luck. Astropy needed [two](https://github.com/astropy/astropy/pull/3715) [pull requests](https://github.com/astropy/astropy/pull/6971) and more than three years to reinvent the wheel and get their own numbers with uncertainties, a feature which `uncertainties` already provided but they couldn’t use because Python… 🤷‍♂️ Fun fact, I started using Julia and created `Measurements.jl` out of frustration because of the lack of composability of `uncertainties` with Astropy. BTW, Astropy has also [its own units](https://github.com/astropy/astropy/tree/885f36f3a41815993654bebc555d3114cbd9edd8/astropy/units), because, why would you want to have a more generic package which any other package in the ecosystem could use (and `pint` does that already)?

To be fair, `Measurements.jl` has [some lines of code](https://github.com/JuliaPhysics/Measurements.jl/blob/ba56443c23bed16fc6e4e8e87c3b12c835f00edb/src/unitful.jl) to make constructing objects which have units and errors a bit nicer, but besides that sugar, `Measurements.jl` and `Unitful.jl` work nicely together out-of-the-box.

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [July 15, 2021, 1:52pm UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/33 "2021-07-15T13:52:52Z")

</div>

I think this comment is more important than the packages available:

> [@Comparing Numba and Julia for a complex matrix computation](https://discourse.julialang.org/t/comparing-numba-and-julia-for-a-complex-matrix-computation/63703/3):
>
> I should add that this is almost certainly the wrong way to go about getting performance improvements. “Highly optimized” code in Python usually means code that is “vectorized” as much as possible — broken into a series of relatively simple array operations that can individually call fast library operations. (For example, calling atan on a bunch of numbers in your code above.) You can write the same sort of code in Julia, of course, but it won’t be magically faster than Numpy — there’s no s…

The audience is important. Will they be _users_ of packages, or developers? It is like asking “What Julia has that Microsoft Word does not offer?” Well, if you are happy with MSWord, and what you want is an easy way to write letters, nothing.

That probably goes the same way if the user is satisfied with the set of packages of any other language he/she uses and there is no need to improve on those implementations, develop problem-specific codes, etc.

Julia is most appealing to developers. Maybe when the package ecosystem becomes as huge as that of python, “users” will find it as welcoming as python. But package users adapt easily to packages in different languages, if the packages are properly documented for the narrow uses they are designed to. In any field we read how to use package-specific inputs and syntax all the time.

---

<div class="post-metadata">

**Author:** ![xiaodai](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xiaodai/32/15937_2.png) [@xiaodai](https://discourse.julialang.org/u/xiaodai)\
**Post date:** [July 16, 2021, 12:11am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/34 "2021-07-16T00:11:16Z")

</div>

> [@blackeneth](#):
>
> just learn C++ instead

seems to be impractical in reality. a lot of teams solely rely on python etc. like my team. we aint’ going to learn c++. we stay within the domain of “most”, meaning most problems can be solved using python. for the one that can’t be, instead of reaching for C++, we just don’t touch it and let it be.

---

<div class="post-metadata">

**Author:** ![SergeantMike67](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sergeantmike67/32/25103_2.png) [@SergeantMike67](https://discourse.julialang.org/u/SergeantMike67)\
**Post date:** [July 18, 2021, 2:09am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/36 "2021-07-18T02:09:47Z")

</div>

I think this whole ecosystem argument used against switching to Julia is a red-herring put forward by those who have become comfortable in the status quo. Of course Julia’s ecosystem doesn’t measure up to Python’s, Python has a 20 year head start. The question really needs to be how does Julia’s ecosystem look at 8 years compared to Python at 8 years? I don’t know the answer to this but it seems to me that if the ecosystem is developing faster than Python did then the community is much more engaged and enthusiastic and recognizes the value of the langauge.

---

<div class="post-metadata">

**Author:** ![Liso](https://avatars.discourse-cdn.com/v4/letter/l/898d66/32.png) [@Liso](https://discourse.julialang.org/u/Liso)\
**Post date:** [July 20, 2021, 7:17am UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/37 "2021-07-20T07:17:14Z")

</div>

> [@GunnarFarneback](#):
>
> has no equivalent (and if there is something that can compete I’d very much love to know)

You could probably find competitive C-code [here](https://github.com/GunnarFarneback/GoGameGraphs/blob/master/src/GoGameGraphs.c) 😉

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [July 20, 2021, 1:31pm UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/38 "2021-07-20T13:31:38Z")

</div>

> [@Liso](#):
>
> You could probably find competitive C-code [here](https://github.com/GunnarFarneback/GoGameGraphs/blob/master/src/GoGameGraphs.c) 😉

There’s a substantial difference between constructing a class of graphs and finding the longest path through them.

---

<div class="post-metadata">

**Author:** ![Albert\_Zevelev](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/albert_zevelev/32/11844_2.png) [@Albert\_Zevelev](https://discourse.julialang.org/u/Albert_Zevelev)\
**Post date:** [July 20, 2021, 2:06pm UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/39 "2021-07-20T14:06:11Z")

</div>

@RJDennis [GitHub - RJDennis/SolveDSGE.jl: A Julia package to solve, simulate, and analyze nonlinear DSGE models.](https://github.com/RJDennis/SolveDSGE.jl) is by far the most composable package in the world for solving Dynamic economic models.

More generally, the package uses Pertubation & Projection methods to numerically solve systems of (stochastic) difference equations, which can be useful to others (non-economists) who have non-linear models that boil down to systems of difference equations

---

<div class="post-metadata">

**Author:** ![jonathan-laurent](https://avatars.discourse-cdn.com/v4/letter/j/ecae2f/32.png) [@jonathan-laurent](https://discourse.julialang.org/u/jonathan-laurent)\
**Post date:** [July 20, 2021, 2:26pm UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/40 "2021-07-20T14:26:29Z")

</div>

[AlphaZero.jl](https://github.com/jonathan-laurent/AlphaZero.jl) provides yet another illustration of a package that is only made possible by Julia’s unique strengths. Leveraging Julia’s inherent speed and its native support for composable parallel programming, this implementation of Deepmind’s AlphaZero algorithm is consistently one to two orders of magnitude faster than comparable (pure) Python implementations, while being equally simple and flexible. I will be giving a [talk](https://pretalx.com/juliacon2021/talk/NLG9FQ/) at JuliaCon about it if you are interested to learn more about it!

---

<div class="post-metadata">

**Author:** ![TheCedarPrince](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thecedarprince/32/17323_2.png) [@TheCedarPrince](https://discourse.julialang.org/u/TheCedarPrince)\
**Post date:** [July 20, 2021, 5:40pm UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/41 "2021-07-20T17:40:26Z")

</div>

Hey, as a reference, you might want to see the excellent advice in this zulip post too: [Zulip](https://julialang.zulipchat.com/#narrow/stream/137791-general/topic/Tips.20for.20Giving.20a.20Talk.20on.20Julia.20to.20Mostly.20Python.20Audience/near/217701894)

---

<div class="post-metadata">

**Author:** ![EvoArt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/evoart/32/25357_2.png) [@EvoArt](https://discourse.julialang.org/u/EvoArt)\
**Post date:** [July 29, 2021, 8:18pm UTC](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646/42 "2021-07-29T20:18:03Z")

</div>

Genify.jl?

[Previous page](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646.md?page=1)

[Next page](https://discourse.julialang.org/t/julia-packages-that-have-no-equivalents-in-other-languages/64646.md?page=3)