Towards new solutions for scientific computing: the case of Julia

Specific Domains Astro/Space
1

Hi to everybody,

@giordano and I have submitted a paper for the Proceedings of ADASS 2018. It is available here: [1812.01219] Towards new solutions for scientific computing: the case of Julia. Slides of the talk I gave are available on SlideShare: Towards new solutions for scientific computing: the case of Julia.

Because of a 4-page limit on articles, we had to do some hard cuts. We have not been able to talk about Julia’s type system and dynamic dispatch, and I would have liked to provide more details about the way I’m using Julia in cosmological applications.

The conference was great, although my talk was scheduled to be the very last. I was quite amazed to see that no one mentioned Julia during the 5-day conference (but there were three talks and two posters about Rust, even though it does not seem particularly well-tailored for astronomical applications.)

The public asked several questions:

  • Are there tools like rustdoc and rustfmt? I mentioned the existence of Documenter.jl but added that I am not aware of any automatic code formatter.
  • Does a transpiler from Python to Julia exist? I was not aware of any, but I said that it would be a hard task to produce a transpiler that produces performant Julia code, as techniques to write fast code are different in NumPy and Julia.
  • Is it possible to compile Julia code to executables, to simplify deployment? I answered that this is not easy at the moment, but that developers are willing to implement this at some time.
  • Can you write OOP code in Julia? I answered that there are OOP constructs, but they are quite different from mainstream OOP languages like Java and C++.
  • Is it possible to write Python extensions in Julia? This was asked by several people: as space projects have large Python codebases, this would allow people to introduce Julia in existing projects, much like Mozilla slowly is doing with Rust in Firefox. I answered that I wasn’t aware of this kind of tool, but it would probably be possible once Julia can produce standalone .so libraries. (@giordano pointed me to the existence of pyjulia, but I wasn’t aware of its existence.)

My impression is that a few people in the audience got excited for Julia. A few people told me that they considered using Julia a couple of years ago, but they gave up because of the immaturity of the language. Another one (a Rust enthusiast) told me that Julia could really become the “Python killer” in astronomy!

At the end of the conference, the SOC announced that they have struck a deal with the Astronomy & Computing Journal to produce a special issue about ADASS 2018, and they encouraged attendants to consider writing a paper for this issue in due time. (The idea is to submit something like the contribution to the proceedings, but without the 4-page limit.)

Maurizio.

17 Likes
2

I would also like to see some code formatting tool, having used gofmt before. But I think that in the context of Julia, it might be more difficult, since I feel that some developers hold strong opinions about details such as whitespace around binary operators in mathematical expressions.

3

There’s
https://github.com/ZacLN/DocumentFormat.jl
but I’m not sure how well it works as a standalone package right now.

2 Likes
4

Very nice slides and screencast. I think you highlighted a lot of important points (advantages and trade-offs, esp compilation cost) given the time limit.

I think that people who ask about transpilers and OOP in Julia are not the ideal audience for the language. My impression is that they would prefer to have a “magic” solution that would somehow make everything faster while more or less continuing programming as if they kept using their previous programming language. It is important to manage expectations, and clarify that to make productive use of Julia, you have to learn a new language. I think the slides conveyed this.

1 Like
5

+1 for the code-formatting. I would love to see this partially under the umbrella of julialang, not as an entirely independent package: Simply to fix one “official style guide” that is mostly adhered to in Base. This does not necessarily involve additional work by julialang, only an expression of opinion in the style-guide: “when in doubt, use BaseFmt code-formatting. Run with warn=true to get warnings for issues like lowercase typenames that are beyond mere formatting. See [link] for how to integrate this into CI”.

Obviously projects can deviate from that, but it is worthwhile to have a single unambiguous default for everybody. That way all people who don’t have strong opinions will end up with the same formatting.

8 Likes
6

A large part of OOP can be easily mimicked in Julia. Even things like inheriting structure and super constructors.

julia> using StructuralInheritance

julia> @protostruct mutable struct Foo{T}
           someField::T
           someOtherField::T
           Foo(x::T) where T = new{T}(x,x^2)
           Foo(x::T,y::T) where T = new{T}(x,y)
       end
ProtoFoo

julia> @protostruct mutable struct Bar <: Foo{Int}
                  yetAnotherField::Float32
              end
ProtoBar
julia> Bar(x) = Bar(StructuralInheritance.totuple(Foo(x))...,x^3) #even superconstructors
Bar

julia> Bar(2)
Bar(2, 4, 8.0f0)

julia> @doc Bar
  No documentation found.

  Summary
  ≡≡≡≡≡≡≡≡≡

  mutable struct Bar <: ProtoBar

  Fields
  ≡≡≡≡≡≡≡≡

  someField       :: Int64
  someOtherField  :: Int64
  yetAnotherField :: Float32

  Supertype Hierarchy
  ≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡

  Bar <: ProtoBar <: ProtoFoo{Int64} <: Any
1 Like
7

That’s a good response. I typically say something along the lines that the key difference is that methods don’t belong to classes/types, which is both necessary for multiple dispatch, but also enables better composeability. See also this StackOverflow question.

3 Likes
8

Hi @Maurizio_Tomasi,
Thanks for sharing your experiences with Julia. I myself haven’t dared yet to really get my feet wet in the language, but definitely will give it a try one of these days :wink: I attended ADASS 2017 in Chile, and indeed back then nobody brought the topic in the main talks I can remember. My impression is that Python is indeed more mainstream for the reasons you enunciate in your presentation.
Anyways, thanks again, and greetings from (the south of) Chile!

3 Likes
9

Thanks, @orco!