Julia v1.3: Reproducible results, Yggdrasil, & multi-threading changes
Julia has undergone a few new changes with the release of version 1.3. The newest minor update brings better reproducibility for future projects, a new community collection of build repos, a few new language features, and more. Let’s check in with Julia and see how the language is doing, what’s new, and what its community is saying about its current state.
The third minor release of Julia 1.x arrived. Julia, the open source, dynamically-typed, programming language continues to stay on track, releasing regularly scheduled improvements.
Julia v1.3 includes a few new language features, support for Unicode 12.1.0, and some multi-threading changes. It also adds several library functions, standard library changes, and one tooling improvement.
Let’s check in with Julia and see how the language is doing, what’s new, and what the community is saying about the language’s current state.
In July 2019, Julialang announced composable multi-thread parallelism across the entire package ecosystem. You can use multiple thready by setting the
JULIA_NUM_THREADS environment variable with:
$ JULIA_NUM_THREADS=4 ./julia
v1.3 polishes the feature with a few changes. From the changelog:
- Experimental feature:
Threads.@spawnmacro runs a task on any available thread.
- System level I/O operations are now thread-safe.
- Global random number generator (
GLOBAL_RNG) now thread-safe.
Channel(f::Function, spawn=true)keyword argument scheduled the created Task on available threads.
Channelconstructor, making it easier to read.
Newest language features
This is a minor release, so only four new language features arrive in v1.3.
- Unicode 12.1.0 support. This adds exactly one new character: U+32FF SQUARE ERA NAME REIWA, the new character for Reiwa, the current era of Japan.
- Methods can be added to an abstract type. See the original pull request.
- Support for Unicode bold digits and double-struck digits (0 through 9).
- Added syntax
var"#str#"for printing and parsing non-standard variable names. See the original pull request.
Ensuring future reproducibility
How do you plan for the future? In v1.3+, a few things change in order to support better reproducibility, so you can count on your past projects and come back to old code.
The announcement post by Elliot Saba, Stefan Karpinski, and Kristoffer Carlsson states:
Over the past few months, we have been iterating on and refining a design for
Pkgin Julia 1.3+ to reason about binary objects that are not Julia packages. While the motivating application for this work has been improving the installation experience for binaries built with
BinaryBuilder.jl, the artifacts subsystem is much more general and is widely applicable to all Julia packages.
This system has the huge benefit of working within the excellent Julia packaging system, gaining all of the reproducibility benefits of Manifests and the compatibility checking capabilities of the package resolver. This means that now when you come back to a project six months later, instantiating it will install not only the exact Julia source code you had previously, but will also fetch the exact library versions that were installed when it was working.
See an example of an auto-generated library package (JLL) on GitHub. JLLs are autogenerated using
BinaryBuilder.jl, which is a system for compiling 3rd-party binary dependencies. With it, these dependencies should/will work almost anywhere. Under BinaryBuilder, all packages are cross compiled.
Read the full blog post for an explanation on package artifacts, artifact types and properties, and how it all ties together.
Under the world tree
In the past, individual programmers created a “builder repository” for building Travis CI binaries. However, now a community buildtree is now located on GitHub. Yggdrasil is a collection of builder repositories for BinaryBuilder.jl.
From the repo:
The development version of BinaryBuilder makes use of the new
Artifactssystem shipping in Julia 1.3. This means that BinaryBuilder no longer generates
build.jlfiles that are placed into your Julia package’s
deps/folder, but instead generates whole Julia packages (known colloquially as “jll” packages) that are placed within the JuliaBinaryWrappers organization. Merged pull requests to Yggdrasil result in new versions of these wrapper packages being generated, uploaded and registered, allowing your client Julia code to simply invoke
using LibFoo_jllto get ahold of your binaries with no need for a
Go on and explore the new changes!
Who should use Julia? Is the language only for computer science?
Editor of Julia Notes, Nicolau Leal Werneck, published an article titled New trends in programming languages, which examines C++, Go, Rust, Swift, Python, and of course, Julialang.
Werneck compares the languages and concludes that “Julia can achieve the same performance as C++” and in some cases, can even surpass its speed. (Check out the code used in the “change-making-problem on GitHub Gist.)
Julia continuously passes the test. As Werneck writes:
We can show good running times, and if there is such a thing as a good test for a “clean syntax”, it seems the language can stand up to it. It can also definitely deliver modern needs such as running on GPUs and performing automatic differentiation.
Although many scientists use Julia, the language has usage even beyond scientific computing and can be used in general projects by all developers.
Why not give it a try? Quench your curiosity with the official documentation.