Cuando alguien llega a Julia desde Python o Java, lo primero que le llama la atención es que las funciones no pertenecen a ninguna clase. No hay objeto.metodo(). Hay funciones libres, y el compilador decide cuál ejecutar mirando los tipos de todos los argumentos a la vez. Eso es el multiple dispatch, y es la pieza central del diseño de Julia.
Tipos abstractos y concretos
Julia separa los tipos en dos categorías. Los tipos abstractos no se pueden instanciar directamente: son la jerarquía conceptual. Number es el padre de Real, que es padre de Integer, que es padre de Int64. Puedes escribir funciones que acepten cualquier Real y funcionarán con Int64, Float32 o lo que sea que herede de ahí.
Los tipos concretos son los que tienen instancias reales: Int64, Float64, String, Bool. El compilador los conoce en tiempo de compilación y genera código máquina especializado para ellos.
# Jerarquía de tipos numéricos en Julia
# Number -> Real -> Integer -> Int64
# -> Int32
# -> AbstractFloat -> Float64
# -> Float32
# Función genérica que acepta cualquier tipo numérico real
function cuadrado(x::Real)
return x * x
end
cuadrado(3) # Int64
cuadrado(3.14) # Float64
cuadrado(Float32(3.14)) # Float32
# Comprobar la jerarquía
println(Int64 <: Integer) # true
println(Float64 <: Real) # true
println(String <: Number) # false
Tipos compuestos: struct
Para crear tus propios tipos usas struct. Por defecto son inmutables, lo que permite al compilador hacer optimizaciones agresivas. Si necesitas mutabilidad, añades mutable.
# Tipo inmutable (más eficiente)
struct Punto
x::Float64
y::Float64
end
# Tipo mutable
mutable struct Contador
valor::Int64
end
# Crear instancias
p = Punto(3.0, 4.0)
c = Contador(0)
c.valor += 1 # OK, es mutable
# p.x = 5.0 # ERROR, Punto es inmutable
También puedes anotar los campos con tipos paramétricos para crear estructuras genéricas. Punto{T<:Real} funciona con cualquier tipo numérico real sin duplicar código.
Multiple dispatch en la práctica
La diferencia con la OOP clásica es que en Python o Java, el método se elige según el tipo del primer argumento (el objeto que llama al método). En Julia, el sistema mira todos los argumentos y elige el método más específico que encaje.
# Tres métodos de la misma función genérica `combinar`
function combinar(a::Int64, b::Int64)
println("Int + Int: suma = $(a + b)")
end
function combinar(a::Float64, b::Float64)
println("Float + Float: producto = $(a * b)")
end
function combinar(a::String, b::String)
println("String + String: concat = $a$b")
end
# Julia elige el método correcto según los tipos reales
combinar(3, 5) # "Int + Int: suma = 8"
combinar(3.0, 5.0) # "Float + Float: producto = 15.0"
combinar("hola", " mundo") # "String + String: concat = hola mundo"
# ¿Qué métodos existen para combinar?
methods(combinar)
Esto no es solo un truco de despacho. El compilador genera código nativo diferente para cada combinación de tipos, lo que significa que no hay overhead de indirección en tiempo de ejecución. Cada llamada va directamente al código máquina especializado.
Union y tipos paramétricos
Cuando una función tiene que aceptar dos tipos posibles sin una relación de herencia entre ellos, usas Union:
# Una función que acepta Int o String
function mostrar(x::Union{Int64, String})
println("Valor: $x")
end
mostrar(42) # OK
mostrar("hola") # OK
# mostrar(3.14) # ERROR: Float64 no está en el Union
# Tipos paramétricos: Array{T, N}
# T = tipo de elemento, N = número de dimensiones
v::Array{Float64, 1} = [1.0, 2.0, 3.0] # vector 1D
m::Array{Int64, 2} = [1 2; 3 4] # matriz 2D
# Vector y Matrix son aliases
v2::Vector{Float64} = [1.0, 2.0]
m2::Matrix{Int64} = [1 2; 3 4]
Por qué esto produce código rápido
Hay un concepto clave para entender el rendimiento de Julia: la estabilidad de tipos. Una función es estable en tipos si el tipo del valor de retorno se puede deducir en tiempo de compilación a partir de los tipos de los argumentos. Si Julia puede hacer eso, genera código sin ramificaciones de tipo en tiempo de ejecución, lo que es igual de rápido que C.
# Función estable en tipos: el compilador sabe que devuelve Float64
function area_circulo(r::Float64)
return pi * r^2
end
# Función inestable en tipos: el tipo de retorno depende de un valor, no de un tipo
function division_peligrosa(a, b)
if b == 0
return "error" # String
else
return a / b # Float64
end
end
# Esta segunda función es más lenta porque Julia no puede especializarla
# Herramienta para diagnosticar inestabilidades
@code_warntype area_circulo(3.0) # Verde = estable, Rojo = inestable
La macro @code_warntype es tu mejor aliada cuando un código Julia va más lento de lo esperado. Te muestra en rojo las partes donde el compilador no puede deducir los tipos, que es casi siempre donde está el problema de rendimiento.
Integración con el resto de Julia
El sistema de tipos no es solo una curiosidad académica. Es lo que permite que paquetes de terceros se integren entre sí sin coordinación previa. Si defines un tipo MiMatriz que hereda de AbstractArray, funciona automáticamente con todo lo que espera arrays: sum, map, filter, broadcasting, y librerías como DataFrames o Plots.
Esto explica por qué en la serie de artículos sobre Julia vemos que DataFrames.jl y Flux.jl pueden operar con los mismos arrays sin capas de conversión. El multiple dispatch hace de pegamento sin coste.
Para quien viene de lenguajes como Rust, el sistema de tipos de Julia se siente menos estricto pero igual de potente para el dominio numérico. No hay ownership ni lifetimes, pero el compilador aprovecha la información de tipos para generar código igual de eficiente en el contexto de computación científica.
Imagen: Pexels / Jakub Zerdzicki