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)
4 Likes
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.
12 Likes
UnitfulRecipes feels like something that pretty much can’t exist in other languages.
4 Likes
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.
2 Likes
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.
If someone knows of an industrial or more theoretically important application, I’m all ears.
7 Likes
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.
1 Like
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!)
1 Like
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.
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.
6 Likes
Yes, but commonly used packages like Unitful and BenchmarkTools are rightfully cautious about pulling in dependencies, even as lightweight as RecipesBase.
1 Like
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:
17 Likes
uncertainties and pint in Python do that.
What they lack is composability with external packages, uncertainties has an entire module 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 of uncertainties don’t require any work at all in Measurements.jl (like complex quantities, FFT, etc…).
pint needs some glue code 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 pull requests 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, 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 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.
18 Likes
I think this comment is more important than the packages available:
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.
2 Likes
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.
1 Like
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.
11 Likes
There’s a substantial difference between constructing a class of graphs and finding the longest path through them.
1 Like
@RJDennis GitHub - RJDennis/SolveDSGE.jl: A Julia package to solve, simulate, and analyze nonlinear DSGE models. 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
4 Likes
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 at JuliaCon about it if you are interested to learn more about it!
12 Likes
Genify.jl?
7 Likes