OCaml: las primeras impresiones de un desarrollador de Rust

Artículo original ↗ Discusión en Hacker News ↗

Los desarrolladores de Rust que exploran OCaml encuentran fuertes similitudes en los sistemas de tipos y los tipos algebraicos de datos, pero también contrastes marcados en los paradigmas: el sesgo funcional de OCaml, la potente inferencia de tipos y los nuevos efectos algebraicos en la v5 lo hacen parecer a la vez elegante y ajeno para quienes están acostumbrados a los lifetimes explícitos y al estilo imperativo de Rust. Los comentaristas debaten sobre rendimiento, manejo de errores (excepciones frente a `Result`/panics) y el impacto práctico de las listas enlazadas, la recursión y la genérica, a la vez que señalan que las herramientas de OCaml (especialmente OPAM y el soporte en Windows) y la curva de aprendizaje pueden ser barreras reales. Muchos ven Rust como un lenguaje de sistemas inspirado en ML que llevó la comprobación avanzada de tipos a un público más amplio, mientras que OCaml sigue siendo atractivo por su expresividad y seguridad, pero menos accesible para el uso cotidiano o empresarial.

Relación entre OCaml/ML y Rust

  • Muchos ven Rust como “un ML con un borrow checker” más que OCaml como “Rust sin” uno.
  • El atractivo de Rust suele atribuirse a características al estilo ML: tipos algebraicos de datos, Option/Result, potente inferencia de tipos, pattern matching.
  • Otros sostienen que Rust es demasiado imperativo y carece de características como los tipos de orden superior y closures respaldadas por un GC adecuado para ser un “ML verdadero”.
  • Rust originalmente tenía un GC y evolucionó hacia un reemplazo de C++ con fuertes garantías de seguridad.

Seguridad, excepciones y panics

  • Algunos critican las excepciones omnipresentes de OCaml por hacer más difícil razonar sobre el flujo de control y complicar las pruebas de “seguridad”.
  • Contrapunto: las excepciones no perjudican la seguridad de memoria en un lenguaje con GC; el problema real es la “seguridad de excepciones”, que Rust también enfrenta con panics y la semántica de unwind.
  • Los panics de Rust se comparan con las excepciones; pueden capturarse, pero muchos recomiendan panic=abort o evitar panics fuera de main.

Rendimiento y casos de uso

  • Hay desacuerdo sobre si los lenguajes ML son “as slow”.
  • Varios afirman que OCaml/F# se sitúan en rendimiento cerca de Java/C# y muy por encima de Python/Ruby, especialmente con código nativo y arrays en lugar de listas.
  • Rust triunfa aplicando tipos al estilo ML a la programación de sistemas y a la seguridad de memoria, donde los ML con GC se consideran demasiado pesados.

Tipos, inferencia e interfaces

  • Se elogia la fuerte inferencia de tipos por reducir la verbosidad, pero algunos echan de menos anotaciones explícitas por legibilidad y ubicaciones de errores más claras.
  • Compromiso sugerido: anotar parámetros de funciones e interfaces públicas y dejar que el compilador infiera el resto.
  • Los archivos de interfaz .mli se defienden como potentes para el encapsulamiento y la estructura a gran escala, aunque otros consideran que los archivos separados son redundantes e incómodos.
  • Los tipos inferidos muy genéricos pueden ser difíciles de entender; algunos argumentan que mejoran el razonamiento (“theorems for free”), otros dicen que oscurecen la intención.

Estilo FP: listas, recursión e iteradores

  • Los principiantes están sobrerrepresentados por las listas enlazadas y la recursión; los desarrolladores con experiencia dicen que el OCaml real suele usar arrays, secuencias y estructuras mutables cuando conviene.
  • Las listas enlazadas siguen siendo ubicuas, pero no siempre son óptimas para el rendimiento.
  • Los usuarios de Rust señalan una división similar entre cadenas de iteradores y bucles imperativos.

Curva de aprendizaje, productividad y herramientas

  • Varios describen un cambio de paradigma pronunciado desde lo imperativo/OOP hacia el estilo funcional; semanas o meses pueden no ser suficientes para sentirse productivo.
  • OCaml se percibe como excelente intelectualmente, pero menos obviamente práctico para algunas tareas como la programación competitiva.
  • Las herramientas tienen luces y sombras: se elogian los efectos de OCaml 5 y las mejoras modernas de la stdlib; OPAM es criticado por frágil, especialmente en Windows, aunque otros lo consideran sólido frente a algunos ecosistemas.