Image for post
Image for post
Number hierarchy in Julia. Purple are concrete types, green are abstract.

Types in C/C++ and Julia

On the surface C/C++ code and Julia code will often look quite similar despite C++ being statically typed and Julia being dynamically typed. Comparing the two is an interesting case to highlight the difference between static and dynamic typing at a deeper level.

Static typing proponents like to say that dynamic type is really just a special case of static typing where every object has the same general type. That is misleading and hides the deeper differences.

Lets look at a code example in C/C++ and Julia which looks superficially almost the same.

struct Rocket {
int stages;
float fuel;
bool reusable;
};

void refuel(Rocket &rocket, float fuel) {
rocket.fuel += fuel;
}

So we got a struct representing a rocket, which keeps track of how many stages it has left, fuel and whether it may be reused such as the Falcon 9 rocket. In Julia I could write:

mutable struct Rocket
stages::Int
fuel::Float64
reusable::Bool
end

function refuel(rocket::Rocket, fuel::Float64)
rocket.fuel += fuel
end

Notice how similar it looks, if you disregard the fact that type and variable name has swapped places and become separated with a :: symbol. Also Julia doesn't use curly braces but begin and end, skipping the begin part if there is some other keyword such as struct or function to define it.

Similarities also exist at a more detailed level. In Python a composite type such as Rocket would have ended up as a dictionary. A Julia struct often has identical layout in memory to a C/C++ struct.

This is were all the similarities end. C/C++ types are defined and really only exists at compile-time. In a dynamic language types exist at run-time and type information can be manipulated and introspected at runtime with the same syntax as everything else is. Lets start the Julia REPL and look at how:

$ julia

Define variable a to contain 5.

julia> a = 5
5

Since types are regular objects existing at runtime, we can stick them in an array:

julia> mytypes = [Int, Float64, Bool]
3-element Array{DataType,1}:
Int64
Float64
Bool

Now for the fun part. This example show how you got the full language available when defining a type:

julia> mutable struct Rocket
stages :: supertype(Int)
fuel :: (a > 5 ? Float32 : Float64)
height :: if a > 20 typeof(a) else Float16 end
reusable :: mytypes[3]
end

There is no real difference between using if statement and ?: here, I am just doing it for the sake of showing that we are not limited to some specific subset of the language. while, for and if are not statements but expression in Julia so they return a value. That is why I don't need a return statement inside the if-else.

We can look at the actual type created with dump()

julia> dump(Rocket)
Rocket <: Any
stages::Signed
fuel::Float64
height::Float16
reusable::Bool

What happened is that the definition of the Rocket struct ran like any other code, resolved the types at runtime and assigned those types to the fields of the Rocket type.

Just like any other type we can instantiate an object of this type:

julia> r = Rocket(3, 40.6, 120, true)
Rocket(3, 40.6, Float16(120.0), true)

We are not limited to using the language to determine types for definition of composite types such as a struct. You can also use it when defining functions. Here is a bit of a contrived example of the refuel() function:

a = 20
function refuel(rocket::Rocket, fuel :: (a < 20 ? fieldtype(Rocket, :fuel) : Float64))
rocket.fuel += fuel
end

If you are from a static typing background it might be hard to wrap your head around the notion that functions don’t really exist in dynamic languages at the point where they are run. It is at runtime when the program encounters a function definition that the code for it is actually created. And in Julia’s case it is really just a sort of code template which is created.

It is upon calling the function with arguments of specific types that Julia will specialize the function and have the Julia JIT emit machine code specifically tailored to those particular function arguments.

This means that as in this case, we have the option of using all available state in the program to determine at runtime what the definition of the function should be. In our silly case, we are making a check on the contents of a variable a < 20 ?. If it is less than 20, we call a function fieldtype() which returns the type of a specific field.

julia> fieldtype(Rocket, :fuel)
Float64

All this dynamic and potentially complex code doesn’t really cost us anything in the long run, as the Julia JIT will do away with it. To demonstrate let me create another simple type:

julia> struct Point
x::Int
y::Int
end

Then we define a function which uses fieldtype() to define one of its arguments.

julia> add(p::Point, x::fieldtype(Point, :x)) = p.x + x
add (generic function with 1 method)

julia> p = Point(4, 8)
Point(4, 8)

julia> add(p, 5)
9

Now lets look at the generated assembly code.

julia> @code_native add(p, 5)
pushq %rbp
movq %rsp, %rbp
addq (%rdi), %rsi
movq %rsi, %rax
popq %rbp
retq

As you can see there are just some push and pop to save registers when calling a function. The meat of the function is just:

addq	(%rdi), %rsi

Thus despite all sorts of crazy stuff added to the function definition, the JIT compiler throws away all of that away and leaves us with highly optimized machine code.

It might still not be clear why Julia uses all these type annotations, especially if you come from a single dispatch language such as Python or Ruby. It makes it look as if Julia is a statically typed language. It is easy to demonstrate that Julia doesn’t require type annotations:

mutable struct Rocket
stages
fuel
reusable
end

function refuel(rocket, fuel)
rocket.fuel += fuel
end

If we test this code in the Julia REPL, you can see that it works fine to create an instance of the Rocket type.

julia> r = Rocket(3, 40.6, true)
Rocket(3, 40.6, true)

The types of the fields end up the same:

julia> dump(r)
Rocket
stages: Int64 3
fuel: Float64 40.6
reusable: Bool true

The refuel function works as before:

julia> refuel(r, 4.0)
44.6

The point of specifying types in Julia is the same as in Python and Ruby. In both you are stating explicitly the type of the first argument to a function when that function is a member of a class. I am referring to the first argument as the self argument which is often implicit.

You need to do this because the same function can have multiple different implementations for different classes. That is what polymorphism is all about. Specific code runs when the this or self argument is of a specific type.

Julia simply takes this reasoning one step further and picks a specific implementation of the function based on any argument, not just the first one (self or this).

So the purpose of Julia type annotations is really to just be able to tell the runtime system which implementation belongs to which combination of argument types.

Image for post
Image for post
The type of every argument is used to lookup a specific function implementation (called method in Julia), not just an implicit self/this argument (first argument to Python methods).

That is not the purpose of type annotations in statically typed languages. In a statically typed language this is used to catch type errors. Such as attempting to call a function with the arguments of the wrong type, at compile time.

That would be impossible to do in Julia as there is no clear distinction between compile time and runtime. Functions are compiled as they are encountered at runtime.

One way to look at this is to say that statically typed languages care about the type of expressions while dynamically typed languages care about the types of values. And expression has no type in a dynamic language. It is when the expression is evaluated that we get an object with some type.

This does not suggest one way is better than the other, and that was not the point of this article either. The point was to convey that dynamic typing is not the same as writing in a statically typed language where everything is of type void. Static and dynamic typing are fundamental different ways of dealing with types.

Written by

Geek dad, living in Oslo, Norway with passion for UX, Julia programming, science, teaching, reading and writing.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store