Warum ich OCaml liebe (2023)

• Ein Entwickler, der funktionale Programmierung und statische Garantien schätzt, bewertet nach Erfahrungen mit mehreren Sprachen das ausgewogene Design von OCaml besonders hoch
• Im Vergleich zu Haskells komplexem Typsystem und langsamer Kompilierung bietet OCaml sowohl Einfachheit als auch Praxistauglichkeit
• Es ähnelt Go mit schneller Kompilierung und schlanker Runtime, bewahrt aber die Stärken funktionaler Sprachen wie Pattern Matching und Sum Types
• Schnelle Builds, statische Binärdateien, reichhaltige Dokumentationswerkzeuge (odig, utop) und mehr sorgen für hohe Produktivität und gute Zugänglichkeit
• Die Balance aus Einfachheit und Ausdrucksstärke sowie das elegante Sprachdesign werden als größter Reiz von OCaml hervorgehoben

---

Erfahrungen mit Programmiersprachen und Vergleich

• Aus Erfahrungen mit der Entwicklung von Amateur- und professioneller Software in verschiedenen Sprachen werden die Merkmale einer guten Sprache zusammengefasst
  • Als wichtige Faktoren werden schnelle Kompilierung, eine einfache Runtime, starke statische Garantien, funktionale Bausteine, gute Performance und die Qualität der Dokumentation genannt
• Haskell vermittelte zwar die Denkweise der funktionalen Programmierung, doch komplexe Syntax und langsame Kompilierung werden als Probleme genannt
  • Wegen der Tendenz der Community zur Komplexität und Runtime-Problemen wie space leaks sei die Wartung schwierig
• Go ermöglicht Einfachheit, schnelle Kompilierung, ein gutes Tooling und ein leicht verständliches Codeverständnis
  • Allerdings erhöhen konservatives Design, umständliche Fehlerbehandlung und das Fehlen expliziter Null-Prüfungen die Fehleranfälligkeit und wirken unpraktisch
  • Auch das Fehlen eines REPL und die negative Haltung gegenüber funktionalen Ideen werden als Grenzen erwähnt

Zentrale Stärken von OCaml

• OCaml wird als Sprache bewertet, die die meisten der oben genannten Kriterien erfüllt
  • Starke statische Garantien: Unterstützung für Sum Types, polymorphe Varianten und Pattern Matching
  • Einfache Runtime: Arbeitet trotz Garbage Collection wie eine systemnahe Sprache
  • Schnelle Kompilierung: Mit dem Build-System Dune schneller als Haskell oder Rust
  • Erzeugung statisch gelinkter Einzel-Binärdateien erleichtert die Bereitstellung
  • Hervorragende Dokumentationswerkzeuge: odig (Offline-Dokumentationssuche), utop (REPL), sowie die Trennung von Interface- und Implementierungsdateien
• Automatische Typinferenz steigert die Effizienz beim Schreiben von Code
  • Die Struktur, Typen in Interface-Dateien zu definieren, hilft bei einer klaren Navigation im Code

Sprachdesign und Eindruck

• OCaml ist zwar eine ältere Sprache, bewahrt aber ein raffiniertes Gespür für Design
  • Manche objektorientierten Funktionen oder komplexe Bibliotheken werden als unnötig bewertet
• Insgesamt sind die Balance aus Einfachheit und Ausdrucksstärke sowie das gute Dokumentations- und Tooling-Ökosystem die zentralen Reize von OCaml
• Der Autor schätzt OCaml sehr als eine „einfache, aber ausdrucksstarke Sprache“ und erwähnt eine Zufriedenheit, die sich in anderen Sprachen nur schwer finden lasse

[GN⁺]

Hacker-News-Kommentare

• Ich habe ein wenig mit OCaml gearbeitet und hatte dabei verschiedene Probleme.
  Die Windows-Unterstützung ist miserabel; erst mit OCaml 5 wurde sie auf „ziemlich schlecht“ verbessert.
  Die Syntax ist für Menschen schwer zu lesen, und bei Syntaxfehlern führt schon ein einziges falsches Zeichen zu einer 1000 Zeilen langen Fehlermeldung.
  Ocamlfmt macht selbst komplexe match-Ausdrücke zu einer einzigen Zeile, was die Lesbarkeit verschlechtert.
  Auch die Dokumentation ist übertrieben knapp und enthält kaum Beispiele.
  OPAM sieht in der Theorie gut aus, ist in der Praxis aber voller Bugs; es gab sogar einen Bug, bei dem curl nicht gefunden wurde, wenn man zu mehr als 32 Unix-Gruppen gehörte.
  Typannotationen in Funktionssignaturen sind optional, was die Vorteile statischer Typisierung schmälert.
  Auch das Ökosystem ist klein, und nicht einmal das Kopieren von Dateien hat eine eingebaute Funktion.
  Auch die Fixierung auf einfach verkettete Listen ist ineffizient.
  Trotzdem besser als C oder Python, aber ich würde es wohl nicht gegenüber Rust wählen.

  • Wenn man OCaml unter Windows nutzen will, würde ich eher F# empfehlen.
    Da es auf die CLR abzielt, ist Deployment viel einfacher, und man kann das .NET-Ökosystem direkt nutzen.
    NuGet-Bibliotheken für C# oder VB.NET lassen sich fast unverändert verwenden, daher ist das Ökosystem riesig.
    Die F#-Dokumentation ist viel umfangreicher und enthält deutlich mehr Beispiele.
    Referenzlinks: F# Language Reference, F# Core Docs, F# Cheatsheet
  • Ich habe nachgesehen, ob es den curl-Bug in OPAM wirklich gibt, und ihn in Issue #5373 bestätigt gefunden.
    Tatsächlich handelt es sich um ein musl-bezogenes Problem, das dadurch entstand, dass OPAM mit diesem Binary gebaut wurde.
  • Das meiste davon ist ein Problem der Lernkurve, aber selbst wenn man sich eingearbeitet hat, bleibt die Abkopplung des Ökosystems bestehen.
    ocamlformat ist mit dem janestreet-Profil deutlich besser als in der Standardkonfiguration.
    Das Problem mit Typannotationen in Funktionssignaturen lässt sich durch .mli-Dateien lösen, aber die meisten machen das nicht.
    Stattdessen bietet das OCaml-Plugin für VS Code für Einsteiger die beste Erfahrung.
  • Ich kann die Bemerkung zur Fixierung auf einfach verkettete Listen gut nachvollziehen.
    Auf heutiger Hardware sollte die Standard-Collection meiner Meinung nach eher ein vector sein.
  • Ich stimme voll zu, dass die Windows-Unterstützung schlecht ist.
    Früher war nicht einmal eine direkte Installation über ocaml.org möglich; man musste über mingw oder wsl gehen.
    Insofern gab es praktisch kein OCaml für Windows.

• Warum die Sprachdesigner von Go Ideen aus der funktionalen Programmierung fast gar nicht übernommen haben, ist klar.
  Wie Rob Pike sagte, waren Googles Entwickler größtenteils jung und an Sprachen der C-Familie gewöhnt, also brauchte man eine leicht erlernbare Sprache.
  Da der Perspektivwechsel funktionaler Sprachen viel Zeit kostet, wollte Go diese Kosten vermeiden.

  • Tatsächlich gibt es viele Googler, die mit den Entscheidungen des Go-Teams unzufrieden sind.

• Jedes Mal, wenn ich das Wort „ML“ sehe, schlägt mein Herz noch immer kurz höher, und dann bin ich enttäuscht, wenn ich merke, dass nicht Meta Language, sondern Machine Learning gemeint ist.

  • ML steht für Meta Language, LLM für die Forschungsgruppe Languages and Logic Montreal.
  • Ich finde sogar, dass diese Verwechslung noch besser ist.
    Noch mehr stört mich, wie inflationär das Wort „AI“ heute verwendet wird.
    Ich wünschte, man würde den Begriff AI erst verwenden, wenn es echte AGI gibt.
  • Als ich ML Ende der 1980er auf einer 80286-Maschine zum ersten Mal benutzt habe, war ich wirklich schockiert.
  • Ich habe früher schon einmal etwas Ähnliches gepostet und jede Menge Downvotes bekommen; umso schöner, dass die Reaktion diesmal positiv ist.

• Wenn man sich den Vortrag von Richard Feldman ansieht, wird gut erklärt, warum funktionale Sprachen nicht Mainstream geworden sind.
  Man braucht entweder eine plattformbeherrschende Sprache, eine Killer-App oder enorme Marketingbudgets.
  Einer der Gründe für den Aufstieg von Python war, dass es zur zentralen Sprache des AI-Ökosystems wurde.
  Ich selbst habe mit OCaml funktionale Programmierung gelernt und Projekte mit Haskell und Zig gemacht, bin am Ende aber wieder bei der Realität gelandet: Man nutzt die Werkzeuge, die man einsetzen kann.
  OCaml, Rust und Haskell sind als „Sprachen, die man lernen möchte“ beliebt, aber nicht als „Sprachen, die tatsächlich breit genutzt werden“.

  • Ich stimme der Behauptung nicht zu, dass Python wegen AI populär wurde.
    Torch basierte ursprünglich auf Lua und wurde in das bereits sehr populäre Python portiert.
  • Ich glaube, dass funktionale Programmierung wegen einer elitären Haltung nicht Mainstream geworden ist.
    Das FP-Lager war gegenüber realen technologischen Veränderungen gleichgültig, während in der Zwischenzeit Sprachen wie C, Pascal, Perl, Tcl den Markt besetzten.
    Am Ende blieb FP bei den „Priestern in der Kathedrale“, während imperative Sprachen die Massen gewannen.

• Ich habe F# benutzt und fand Actor-basierte Nebenläufigkeit leicht verständlich.
  Sobald jedoch mutable Arrays auftauchten, wurde es kompliziert.
  Ich frage mich, warum man OCaml in der Praxis F# vorziehen würde.

  • F# verliert durch CLR-Veränderungen zunehmend an Kompatibilität, der Compiler ist langsam und das Tooling instabil.
    OCaml dagegen bietet die Entfernung des globalen Locks, schnelle Kompilierung und mächtige Features wie Module, GADT und Effects.
    F# liegt bei Windows-Unterstützung, SIMD und unboxed types zwar noch vorn, aber OCaml holt allmählich auf.
  • Die .NET-Integration von F# ist ein zweischneidiges Schwert.
    Es gibt viele Bibliotheken, aber die meisten fühlen sich nicht nach F# an.
    OCaml hat ein größeres natives Ökosystem.
  • In meiner Firma haben wir die rechenintensiven Teile in F# entwickelt.
    Die Interoperabilität mit C# ist gut, aber F#-Bibliotheken aus C# zu nutzen war ein Albtraum.
    Am Ende behält man eine C#-Hülle, und die Codebasis wird zu einem Mischwesen.
    Das .NET-Ökosystem ist reichhaltig, aber der starke OOP-Fokus kollidiert mit dem FP-Stil.
    Visual Studio ist bequem, aber für CLI-basierte Workflows unpraktisch.
    Die Kompiliergeschwindigkeit wird immer langsamer, und auch Tests fühlen sich sperrig an.
    Als ich OCaml ausprobierte, wirkte die ergonomische Sprachgestaltung viel natürlicher.
  • OCaml ist mit Funktoren, erstklassigen Modulen, GADT und Objektsystem deutlich mächtiger als F#.
    F# wird zwar oft „OCaml for .NET“ genannt, ist in Wirklichkeit aber nur eine Sprache der ML-Familie und fast eine andere Sprache.

• Da OCaml eine alte Sprache ist, könnte man denken, dass OOP-Funktionen überflüssig wären, aber ich halte Standard ML für vollständiger.

  • Ich mag SML auch, aber das Objektsystem von OCaml wird unterschätzt.
    Es ist nützlich für structural typed records, open recursion und JS-Bindings wie Js_of_ocaml.
  • Ich schreibe gerade einen Compiler in SML, und dort gibt es seltsame Einschränkungen wie int/real overloading oder die value restriction.
    Auch Record-Updates werden nicht unterstützt, was unpraktisch ist.
  • Früher mochte ich SML lieber, aber damals waren Sprachen „mit einem O davor“ in Mode, daher bekam OCaml mehr Aufmerksamkeit.

• OCaml war seit den frühen 2000ern immer eine „fast perfekte Sprache“.
  Aber bis die Reibungspunkte gelöst waren, hatten andere Sprachen die Ideen bereits übernommen.

  • OCaml ist eine Sprache wie The Velvet Underground.
    Wenige lernen sie, aber jeder, der sie lernt, baut eine neue Sprache.
    Quelle
  • Trotzdem betreibt OCaml in der Praxis Handelssysteme im Milliardenbereich.
  • Ich weiß nicht, was mit „Reibung“ gemeint ist.
    Schon jetzt laufen viele Projekte gut mit OCaml,
    und mit dem Effect-System ist es eher noch weiter voraus.

• Popularität und Qualität sind nicht dasselbe.
  Popularität ≠ Qualität, in der Musik ist es genauso.
  Es wird nur durch Trends und Trägheit entschieden.

  • Popularität und Beliebtheit sind eher negativ korreliert.
    Je verbreiteter eine Sprache ist, desto mehr Menschen mögen sie nicht,
    und je unbekannter eine Sprache ist, desto eher wird sie überschätzt.
  • Ob Musik „gut“ ist, ist subjektiv, aber ob eine Sprache „gut“ ist, lässt sich anhand der Effizienz beim Lösen von Problemen objektivieren.
    Dass OCaml weniger populär ist, liegt daran, dass die Nutzergruppe, die diese Effizienz spürt, klein ist.
    Und auch die dogmatische Haltung des FP-Lagers trägt ihren Teil dazu bei.

• Ich denke, Elixir ist eine OCaml ähnliche Sprache mit Potenzial für den Mainstream.
  Sie bringt Vorteile funktionaler Programmierung wie Immutability, Pattern Matching und das Actor-Modell mit
  und läuft stabil auf der BEAM-Runtime.
  Statische Typisierung hat sie zwar nicht, aber eine schrittweise Typprüfung wird derzeit eingeführt.

  • Eigentlich interessiert mich noch mehr, warum F# nicht populärer ist.
    Obwohl man das .NET-Ökosystem direkt nutzen kann, ist es noch unbekannter als OCaml.
  • Elixir hat ein hervorragendes Ökosystem und Tooling, und die Syntax ist zugänglicher als die von Erlang.
    Tatsächlich gibt es viele Firmen, die es für SaaS-Backends einsetzen.
  • Aber die meisten Organisationen empfinden das funktionale Paradigma (rekursionszentriert) als belastend.
    Deshalb bleiben FP-Sprachen weiterhin Nischenprodukte.
  • Persönlich finde ich Elixir weniger geistig anstrengend und flexibler als OCaml.
  • Gleam ist auch interessant, aber eine Sprache, die nicht kompiliert, passt nicht zu meiner Arbeit.

• OCaml ähnelt Go insofern, als es eine GC-basierte Systemsprache ist.
  Ich ziehe GC manueller Speicherverwaltung oder Borrow Checking vor.
  Auch der GC von D war hervorragend, aber das Problem war, dass schon das Wort „GC“ die Leute abgeschreckt hat.