Warum ich OCaml als meine Hauptsprache gewählt habe

 (xvw.lol)
8 Punkte von GN⁺ 2025-08-15 | 2 Kommentare | Auf WhatsApp teilen
  • Die sprachlichen Eigenschaften und das Ökosystem von OCaml sind hervorragend und eignen sich sowohl für persönliche als auch für professionelle Projekte
  • Statisches Typsystem, algebraische Datentypen, Modulsystem, Objektmodell, benutzerdefinierte Effekte und weitere fortgeschrittene Funktionen sind als Multiparadigma-Ansatz stabil integriert
  • Mit dem Paketmanager OPAM, dem Build-System Dune, der Editor-Unterstützung LSP/Merlin, dem Dokumentationswerkzeug Odoc und weiteren Komponenten steht eine ausgereifte Toolchain bereit; dazu kommt ein vielfältiges Bibliotheksökosystem für Web, Blockchain, Tooling und mehr
  • Die Community ist zugänglich, freundlich und professionell, was Lernen und Zusammenarbeit erleichtert, und dank kontinuierlicher Weiterentwicklung sind auch die Zukunftsaussichten vielversprechend

Warum ich OCaml als meine Hauptsprache gewählt habe

  • Der Autor hat über lange Zeit viele verschiedene Programmiersprachen verwendet und sich darunter für OCaml als Hauptsprache entschieden
  • Als größten Vorteil von OCaml nennt er das starke statische Typsystem sowie die im Vergleich zu C oder anderen funktionalen Sprachen besonders gute Unterstützung für funktionale Programmierung
  • Dank dieses Typsystems konnte er viele Bugs vermeiden und Code besser optimieren
  • In mehreren Entwicklungsprojekten hat der Einsatz von OCaml tatsächlich zu deutlich höherer Produktivität und Stabilität geführt

Vorteile von OCaml und Einsatz in der Praxis

  • Der Großteil des Codes lässt sich schnell schreiben, und durch Funktionskomposition sowie die Verwendung unveränderlicher Daten steigt die Sicherheit
  • In letzter Zeit entwickeln sich auch das Ökosystem und die Werkzeuge (IDE, Build-System usw.) von OCaml kontinuierlich weiter
  • Dank vielfältiger Bibliotheken und externer Pakete ist in der Praxis effiziente Entwicklung möglich
  • Im Vergleich zu Python oder Java ist OCaml weniger bekannt, aber bei Produktivität, Sicherheit und Flexibilität eine sehr starke Wahl

Sprachliche Eigenschaften

  • Aus der Verbindung von Forschungsursprung und industrieller Anwendung entsteht eine auf Ausdrucksstärke und Sicherheit ausgerichtete Weiterentwicklung der Sprache
    • Neuere Funktionen wie benutzerdefinierte Effekte und affine Sessions
  • Statische Typprüfung ist zugleich Sicherheitsnetz und Entwurfswerkzeug und räumt Missverständnisse aus, die aus schlechten Erfahrungen mit Typsystemen entstanden sind
  • Multiparadigma: funktional, imperativ, modular, objektorientiert, mit Multicore-Unterstützung
  • Die ML-artige Syntax ist knapp und konsistent; außerdem gibt es alternative Syntaxen wie ReasonML
  • Algebraische Datentypen (Produkt-, Summen- und Exponentialtypen), Pattern Matching und Polymorphismus sind stark für Daten- und Domänenmodellierung
  • Das Modulsystem unterstützt die Trennung von Schnittstelle und Implementierung, Abstraktion, Wiederverwendung bis hin zu fortgeschrittenem Polymorphismus
  • Dependency Inversion: bietet flexible Injektionsweisen über Module und Effekte

Ökosystem und Tooling

  • Kompilierungsziele: Native, Bytecode, JavaScript(Js_of_ocaml, Melange), WebAssembly
  • MirageOS bietet ein Regelwerk zum Schreiben von Bibliotheken für mehrere Kontexte
  • OCaml Platform:
    • OPAM: Versionsverwaltung, Switches, Paketindex, Unterstützung für CI
    • Dune: schnelle Builds, S-Expression-Konfiguration, vereinfachte Veröffentlichung über dune-release
    • LSP/Merlin: Code-Vervollständigung, Navigation und Formatierung in VSCode, Emacs usw.
    • Odoc: unterstützt Querverweise, manuelle Seiten, doctest usw.
  • Umfangreiche Bibliotheken: Web (Dream, Ocsigen), Blockchain und Kryptografie (HACL*), Tests (alcotest, qcheck usw.)
  • Die Standardbibliothek ist klein, aber es gibt Alternativen wie Batteries, Base/Core und Containers

Neue Herausforderungen und Community

  • Die OCaml-Community ist klein, wächst aber kontinuierlich und zeigt eine benutzerfreundliche Entwicklung
  • Für Entwickler, die sich neuen Sprachen oder Paradigmen stellen möchten, ist OCaml eine Sprache, die sich intensiv zu erlernen lohnt
  • Viele Nutzer sagen, dass die Arbeit mit OCaml neue Perspektiven eröffnet und die Problemlösungskompetenz stärkt

Fazit

  • OCaml ist nicht auf bestimmte Bereiche wie Finanzen, Compiler oder Systementwicklung beschränkt, sondern eine starke Programmiersprache für den allgemeinen Einsatz
  • Die in der Praxis gewonnene Effizienz, Wartbarkeit und Fähigkeit zur Problemvermeidung belegen seinen Wert im realen Arbeitsalltag
  • Auch wenn die Sprache im Vergleich zu neueren Sprachen oder Trends etwas weniger bekannt ist, ist sie für alle, die Wert auf Zuverlässigkeit und Sicherheit legen, auf jeden Fall eine überlegenswerte Wahl

Verwandte Beiträge

2 Kommentare

 
ng0301 2025-08-17

Ich habe mich in der Graduiertenschule zwar einmal mit OCaml beschäftigt, aber das Ökosystem ist wirklich dürftig, es gibt kaum gute Referenzen, und vor allem gibt es praktisch niemanden, den man dazu fragen könnte. Nach meinem persönlichen Eindruck wird es hierzulande so gut wie nirgends verwendet, außer vielleicht im Umfeld von Tagungen zu Programmiersprachen. Von COBOL haben die Leute vielleicht schon einmal gehört, von OCaml dagegen wahrscheinlich nicht.
 
GN⁺ 2025-08-15
Hacker-News-Kommentare

  • Ich habe einmal einen Vortrag darüber gesehen, wie Google Rust ins Android-Team eingeführt hat. Zwei Dinge daran fand ich bemerkenswert: Viele verschiedene Projekte wurden von Python nach Rust migriert, also scheint Performance nicht das große Problem gewesen zu sein, und die beliebtesten Features unter Rust-Nutzern waren eher grundlegende Dinge wie Pattern Matching und ADTs (Algebraic Data Types). Daher hatte ich den Eindruck, dass Rust seinen größten Beitrag nicht durch einzigartige Features wie Lifetimes geleistet hat, sondern eher durch Elemente, die ML-Sprachen schon in den 1990ern boten. Wenn OCaml um 2010 herum Unannehmlichkeiten wie Multicore gelöst hätte, wäre es vielleicht so populär wie Rust geworden. Leider ist OCaml zwischen Wissenschaft und Industrie in einer Lücke hängen geblieben. Noch ein Nachtrag: 31-Bit-Integer sind bei Bit-Operationen praktisch unerquicklich, und ästhetisch haben mir doppelte Semikolons wirklich nie gefallen

    • Ich finde, OCaml war damals schon in ziemlich guter Verfassung. 2010 habe ich es beruflich deutlich angenehmer als Python genutzt. Man muss sich nur ansehen, was JaneStreet erreicht hat. Der größte Grund, warum OCaml nicht breit adaptiert wurde, ist meiner Meinung nach, dass es nicht in den USA entwickelt oder geführt wurde. Man möchte gern glauben, dass die Popularität einer Sprache aus technischer Überlegenheit entsteht, aber am Ende ist es eine Frage von Trends. Rusts Durchbruch in der breiten Öffentlichkeit kam auch durch massive Öffentlichkeitsarbeit und eine sehr aktive Community zustande. Es gab sogar dedizierte Leute, die den Namen offensiv bekannt gemacht haben

    • Google versucht, die Liste offiziell zugelassener Sprachen für produktiven Service-Code möglichst kurz zu halten. Rust wurde wohl gewählt, weil es C++ ersetzen oder ergänzen kann. OCaml war schwer in so eine Position zu bringen (Go vielleicht schon, aber eher unwahrscheinlich). Daher war der wichtigste Grund für die Wahl von Rust vermutlich, dass es unter den offiziell zugelassenen Sprachen als einziges ADTs bot, und nicht etwa, dass Build-Geschwindigkeit unwichtig gewesen wäre. Dass OCaml Rust nicht ersetzt hat, ist ebenfalls naheliegend. GC-Sprachen gab es bereits viele, etwa Go oder Haskell, und um 2010 war C++ die einzige wirklich ausdrucksstarke Sprache, mit der man Bare Metal anvisieren konnte (und selbst das war vor C++11 und C++17 noch deutlich schwächer)

    • Stimme völlig zu. Wenn OCaml ein paar kleinere Probleme gelöst hätte, hätte es ein wirklich wichtiger Player werden können. Die Build-Geschwindigkeit ist selbst heute noch viel besser als bei Rust. Aber OPAM (der Paketmanager) ist oft fehlerhaft und berüchtigt dafür, verwirrend zu sein. Der Windows-Support ist erschreckend schlecht, sogar schlimmer als früher bei Perl unter Windows. Die offizielle Dokumentation ist so knapp, dass sie fast nutzlos wirkt. Auch die Syntax selbst ist schwer zu durchschauen, und schon ein kleiner Tippfehler führt oft zu Meldungen, dass die halbe Datei Syntaxfehler enthalte. Rusts bestehende C-artige Syntax ist viel zugänglicher. Kurz gesagt: OCamls Vorteil sind schnelle Builds, aber das allein reicht als Grund zur Nutzung kaum aus

    • Deshalb greife ich, wenn ich im ML-Stil programmieren will, eher zu Kotlin, Scala oder F# als zu Rust. Und inzwischen haben sogar Java oder C# schon genug ML-Elemente übernommen, dass ich wenig Abwehr empfinde. Ich kenne das ML-Typsystem seit Caml Light und Objective Caml, und wenn ich sehe, wie sehr Leute heute Rust feiern, wirkt es fast so, als glaubten sie, Rust habe das ML-Typsystem neu erfunden

    • Zu der Meinung, OCaml hätte besser vorbereitet sein sollen: Ich denke, der größte Vorteil ist in Wirklichkeit, dass es viele verschiedene Sprachoptionen gibt. Allein im Vereinigten Königreich koexistieren trotz geringerer Bevölkerung sehr viele Sprachen. Zum Beispiel wurde Cornisch, eine in Europa ausgestorbene Sprache, in letzter Zeit von Einheimischen wiederbelebt, und unter Hirten gibt es noch eine Zählsprache namens Kubrick. Ich selbst habe begonnen, für den Familienstammbaum der nächsten Generation ein OCAML-basiertes Programm namens Geneweb zu verwenden (nachdem ich von einer Windows-App namens TMG gewechselt bin). Darin stecken Daten zu 140.000 Personen. Weil Geneweb in OCAML geschrieben ist, ist mein Interesse an der Sprache gewachsen. Wenn dir Programmiersprachen schwer vorkommen, probier es mal mit Ahnenforschung/Genealogie. Bald wird dir wegen eines Standards namens GEDCOM der Kopf schwirren

  • OCaml gehört zu meinen Lieblingssprachen. Das meiste habe ich für die Organisation eines Writer's Festival gebaut: eine CRUD-App komplett in OCaml (ReasonML-basiertes JSX), Dream, HTMX und DataTables. Ich habe Module genutzt, um Frontend-Templates wiederzuverwenden, und wenn sich am Datenmodell etwas änderte, zeigte mir der Compiler sofort, wo etwas kaputtging — das fand ich großartig. Ich habe sogar Excel-Daten in eine richtige Datenbank überführt und Dinge wie Zeitpläne aus Vorlagen im .odt-Format oder ZIP-Dateien direkt exportiert, ohne über die Serverplatte zu gehen; überraschend viel ließ sich im OCaml-Ökosystem umsetzen. Allerdings musste ich alle DB-Queries als Strings schreiben und Typkonvertierungen von Hand machen, was extrem ermüdend war (keine Typprüfung zur Compile-Zeit). Auch das Auth-System musste ich selbst implementieren, sodass oft zu viel Zeit für Dinge draufging, die nicht zur eigentlichen Produktentwicklung gehörten. Nachdem ich mir mehrere Sprachen angesehen habe, ist mein Eindruck: Eine perfekte Sprache gibt es nicht. Jede hat ihre ganz eigenen Nachteile. Im Moment baue ich eine App für mich selbst in Rails, und dort ist fast alles, was ich brauche, schon im Standard enthalten, sodass ich viel zufriedener bin, weil ich mich statt auf die Sprache auf die eigentliche Arbeit konzentrieren kann — etwa auf Layout-Design oder das echte Deployment

    • Mich würde interessieren, wie man in stark typisierten funktionalen Sprachen idiomatisch mit DB-Ergebnissen umgeht

  • DarkLang wurde anfangs in OCaml entwickelt und später auf F# umgestellt. Hauptgründe waren das Bibliotheks-Ökosystem und Concurrency (siehe dazu). Ich bin mit .NET vertraut und daher womöglich etwas voreingenommen, aber für die langweiligen Teile gibt es dort viele gute Optionen, sodass man sich auf die eigentlichen Probleme konzentrieren kann. Ich habe F# ziemlich viel beruflich genutzt und pflege sogar eine populäre UI-Bibliothek, aber weil das Sprach-Ökosystem klein ist, hat man selbst auf .NET nicht immer sofort eine Lösung parat. Wenn man also eine Sprache abseits des Mainstreams wählt (z. B. F# statt C#), sollte man die Kosten im Blick behalten. Für OCaml gilt dasselbe: Es bietet eine starke Sprache, bringt aber allerlei Reibung mit, weil es nicht Mainstream ist. Einige Firmen nutzen es zwar in produktiven Systemen, aber das sind meist Fälle mit sehr speziellen Anforderungen

  • Ich habe mehrere Jahre lang versucht, OCaml zu mögen, aber am unerquicklichsten fand ich, dass man nicht einfach „irgendein Objekt“ ausgeben kann. Mit ppx kann man zwar automatisch to_string-Funktionen ableiten, aber das Setup ist mühsam und die Ergonomie kommt nicht an Rust heran. Um Typen wie Set, Map usw. auszugeben, ist zusätzliche Arbeit nötig (Beispiel). In golang kann man mit dem %v-Formatting fast alles bequem ausgeben; in OCaml muss man dafür deutlich mehr Hand anlegen

    • Auch Gos %v-Formatting ist nicht perfekt; wenn man Pointer tiefer traversieren will, braucht man zusätzlich Bibliotheken wie go-spew. Pythons __repr__ ist für mich bis heute die angenehmste Variante

  • Ich habe OCaml selbst nie benutzt, aber die Arbeit mit F# war sehr angenehm. Im Zeitalter der LLMs wäre es vielleicht sinnvoll, funktionale Sprachen wieder stärker zu betrachten. In funktionalen Paradigmen wie OCaml oder Haskell kann man Information sehr effizient in wenig Text komprimieren; vielleicht lässt sich dadurch mehr Bedeutung in das Kontextfenster eines LLM packen. Im Vergleich zu Java, C# oder Ruby könnte man womöglich auch komplexere Änderungen in einem Zug anwenden. Das wäre einen Versuch wert

    • Das dachte ich anfangs auch, aber die Arbeit an einer großen Haskell-Codebasis hat meine Meinung geändert. Vielleicht liegt es daran, dass im Trainingsdatensatz zu wenig FP enthalten ist, aber kompaktere Sprachen scheinen für LLMs eher schlechter zu funktionieren. Wenn Code wortreicher ist, hat ein LLM nach einer falschen Token-Vorhersage mehr Chancen, sich selbst wieder zu korrigieren, und erzeugt dadurch am Ende eher richtigen Code

    • In meinem eigenen kleinen Experiment habe ich ein einfaches CLI-Spiel in C++ und Haskell gebaut. Haskell hatte zwar weniger Zeilen, aber fast gleich viele Wörter, also sieht der Code nur „breiter“ aus. Mit Java oder anderen expliziteren Sprachen habe ich es nicht verglichen, aber ich denke, dass je nach Art des Programms unterschiedliche Stile besser passen. Für manches eignet sich ein imperativer Stil besser, für anderes ein funktionaler

    • Wenn die Codegenerierung durch LLMs noch ein bisschen besser wird, hätte ich gern wirklich starke Typsysteme und Effektsysteme, um den erlaubten Verhaltensraum von Code einzuschränken. Mit abhängigen Typen könnte man zum Beispiel zur Compile-Zeit prüfen, dass „diese Funktion immer eine sortierte Liste zurückgibt“ oder „diese Funktion immer eine gültige Sudoku-Lösung zurückliefert“. Mit einem Effektsystem könnte man zusätzlich angeben: „Diese Funktion liefert eine gültige Sudoku-Lösung zurück, greift aber nicht auf Netzwerk oder Dateisystem zu.“ Wenn LLMs sich weiterentwickeln, könnten sie vielleicht irgendwann auch so etwas in Python leisten. Falls die Fortschritte aber langsam bleiben, ist die Zukunft aus meiner Sicht eher, unverlässliche LLMs durch verlässliche deterministische Systeme einzurahmen und nutzbar zu machen

    • Beim Einsatz von cats-effect (der Effekt-Bibliothek) in Scala hat mich die Unterstützung durch LLMs enorm schneller gemacht. cats-effect-Code lässt selbst einfache Konzepte oft unnötig schwer wirken, aber wenn man ein LLM einfach fragt: „Wie mache ich X in cats-effect?“, sind 80 % sofort gelöst. Für die übrigen 20 % reicht meist zusätzlicher Kontext. Unter Wartungsgesichtspunkten teste ich das noch, aber die Frustration bei effektbasiertem funktionalem Programmieren ist stark gesunken. Als Nächstes würde ich gern ausprobieren, wie gut Claude Code das kann

    • Haskell hat bei LLM-generiertem Code zwei große Vorteile. Erstens fängt das ausdrucksstarke Typsystem viele Fehler ab, und die entstehenden Compilerfehler kann man direkt wieder als Feedback ans LLM geben. Zweitens lassen sich durch Property-based Testing (QuickCheck usw.) Codeverbesserungen effizient und präzise vornehmen. LLMs schreiben die Tests selbst nicht unbedingt gut, aber wenn man sie händisch ergänzt, lassen sich Bugs im generierten Code schnell finden

  • Dieser Artikel beendet für mich endgültig die Frage „Warum nicht einfach F# statt OCaml?“. In fast jedem Thread zu OCaml kommt der Vorschlag: „Löst F# nicht die Tooling-Probleme?“ Mich hat OCaml auch interessiert, und der Spitzname „Go with types“ hatte meine Neugier geweckt, aber OCaml selbst wirkt auf mich noch nicht voll überzeugend. Es fühlt sich anders an als die Begeisterung in Communities wie Erlang, Ruby, Rust oder Zig

    • Ich bin eher von F# zu OCaml gewechselt, um dem F#-Tooling-Ökosystem zu entkommen. Als ich F# verwendet habe, war der Compiler langsam, das Ökosystem stark auf C# fokussiert, MSBuild schwach und schlecht dokumentiert, Ionide stürzte ständig ab, und Fantomas war unzuverlässig. OCaml ersetzt allerdings auch nicht alle leistungsorientierten Features von F# (z. B. Value Types und anderes, was die CLR unterstützt). Insofern habe ich bis heute noch keine einfache ML-artige Sprache gefunden, die alles abdeckt. Ich hoffe, dass Projekte wie OxCaml das künftig lösen können

    • In letzter Zeit nutze ich OCaml nicht mehr viel, aber den Kern der Sprache bevorzuge ich nach wie vor am meisten. Mein Codestil tendiert dazu, sich in eine einzige große Funktion zu verlagern, und in OCaml vermeide ich das ganz natürlich. Rust nutze ich zwar für Side Projects, aber eigentlich ist OCaml für mich angenehmer. Aus genau diesem Grund würde ich F# unbedingt gern einmal ausprobieren

  • Eine Frage zur Terminologie: Im Artikel werden Funktionstypen als „exponential types“ bezeichnet. Ich verstehe nicht ganz, warum Typen höherer Funktionen Exponentialtypen heißen

    • Es gibt schon gute Erklärungen, aber der tiefere Grund ist, dass Funktionstypen algebraisch den Exponentialgesetzen folgen. Zum Beispiel ist A → (B → C) über Currying isomorph zu (A × B) → C. Das ist analog zu (cᵇ)ᵃ = cᵇ˙ᵃ. Und (A + B) → C ist isomorph zu (A → C) × (B → C), was der Regel cᵃ⁺ᵇ = cᵃ·cᵇ entspricht

    • Schon erstordentliche Funktionstypen sind exponentiell. Bei Sum Types gibt es zum Beispiel so viele Werte wie Fälle. (A of bool | B of bool → 2+2=4 Fälle). Dasselbe gilt für Produkt- und Exponentialtypen. Bei bool -> bool gibt es 2^2 = 4 mögliche Werte (wenn man Side Effects außer Acht lässt)

    • Wenn von ADTs (Algebraic Data Types) die Rede ist, spricht man meist nur über Sum und Product. Funktionen werden seltener erwähnt, weil sie keine Daten sind. Aber ein Typ a -> b hat b^a mögliche Fälle, also kann man ihn auf dieselbe Weise betrachten

    • Ich hatte dieselbe Frage. Mathematisch kommen nach Summe und Produkt eben Exponent und Potenz, daher wird der Begriff wohl metaphorisch so verwendet

    • Die anderen Antworten sind alle richtig, aber tatsächlich nennt die Kategorientheorie Funktionstypen auch „exponential product“. Der Name kommt ebenfalls daher, dass sich die Anzahl der Funktionen von A nach B als Kardinalität(B)^Kardinalität(A) berechnet

  • Sum types: Kotlin, Java und C# können z. B. über Sealing (versiegelte Vererbung) bestimmte Fälle wie eigene Typen behandeln
    die Behauptung, die Deklaration von Sum Types sei so wortreich, dass sie schwer verständlich werde
    Sum Types deklariert man normalerweise einmal und verwendet sie dann vielfach. Wenn sich die Fälle sauberer benutzen lassen, ist ein wenig zusätzliche Wortreichheit bei der Deklaration völlig vertretbar

    • Die Fälle eines Sum Types sind Werte (Expressions) über Type Constructors und haben natürlich selbst einen Typ. Zum Beispiel:

      datatype shape =
   Circle of real
  | Rectangle of real * real
  | Point

      Jeder einzelne Fall ist typisiert. Durch Pattern Matching werden die Parameter des Type Constructors ohnehin direkt entpackt. Wenn man die Fälle als eigene Typen herauszieht, verliert man gerade den Vorteil der Vollständigkeitsprüfung, den ein Sum Type bietet, und kann dadurch eher ungültige Programmzustände ausdrücken. Sum Types deklariert man einmal und benutzt sie mehrfach, und oft sind sie eher wegwerfbar. Lesbarkeit von Code ist ebenfalls wichtig; Wortreichheit wird in dieser Hinsicht manchmal unterschätzt. Nebenbei: C#/Java unterstützen keine echten Sum Types. Im folgenden Beispiel ist C# wegen seiner OOP-Art unnötig kompliziert

      public abstract record Shape;
public sealed record Circle(double Radius) : Shape;
...
double Area(Shape shape) => shape switch {...};

      In ML geht das viel knapper

      datatype shape = Circle of real | Rectangle of ... | Point
val result = case shape of ...

      Die beiden Ansätze sind fast gleichwertig, aber die OOP-Elemente in C# stehen eher im Weg

    • In OCaml kann man mit GADTs, polymorphen Varianten (Polymorphic Variants) usw. Fälle auch so verwenden, als wären es separate Typen. Meistens wird es aber schwerer zu verallgemeinern und schwerer zu verstehen, wenn man einen Sum Type aufspaltet. Dazu kommen Probleme mit Type Equality und Variance

    • Ich verstehe nicht, warum überhaupt so verbissen über Sum Types versus Sealed Types gestritten wird. Ich bevorzuge zwar funktionale Sprachen, aber dank Unterscheidbarkeit auf Type-Ebene kann man mit Sealed Types im Grunde alle Sum Types modellieren, und durch Subtyping sind Definition und Nutzung teils sogar einfacher. Die Paradigmen des Systems unterscheiden sich stark, aber mathematisch sind sie fast gleichwertig, und die meisten Type-Tricks aus OOP oder FP lassen sich im Rahmen dessen, was die Sprache erlaubt, ohnehin nachbauen

    • Ich stimme nicht zu, dass sich die Wortreichheit von Sum-Type-Deklarationen in Java/Kotlin lohnt. Das wirkt für mich eher wie das übliche Boilerplate von JVM-Sprachen

  • Es wäre gut, wenn jemand, der ReasonML-Syntax wirklich gut kennt, einmal Vor- und Nachteile vergleichen könnte. (Im Artikel wurde das nur kurz erwähnt)

    • Was mir am meisten gefehlt hat, waren let-Bindings (offizielle Doku). In ReasonML konnte man Operatoren wie >>= für Monaden leicht selbst anpassen und gut damit arbeiten. rescript (ein Fork von ReasonML) hat das bis heute nicht. Dafür unterstützt es async/await gut, was bei asynchronem Code hilft. Melange (im Artikel kurz erwähnt) unterstützt in der Reason-Syntax let-Bindings. Deshalb ist Reason ML mit Melange im React-Frontend sehr stark. Dank let-Bindings kann man dort zusammen mit JSX auch asynchronen Code im monadischen Stil sauber schreiben. In OCaml-Syntax kann man sich zwar mit PPX behelfen, aber das Syntax-Highlighting im Editor funktioniert dann oft nicht gut. Fürs Backend mag ich persönlich eher den Python-Stil, deshalb stören mich die geschweiften Klammern immer noch, und ich mag Funktionsaufrufe und -definitionen lieber ohne Klammern. Als OCaml-Anfänger finde ich Argumente ohne Variablennamen und die nötigen Klammern aber nach wie vor verwirrend. Ich hoffe, diese Erfahrung hilft weiter

    • Ich habe ReasonML kaum benutzt und konnte seinen Mehrwert nie richtig erkennen. Abgesehen davon, dass es in vier Jahren gleich zweimal gestorben ist ...

    • Ich wünschte, die Reason-Syntax hätte sich stärker verbreitet, aber wenn man mit der OCaml-Community kommunizieren will, lernt man besser einfach die Standardsyntax. Der meiste Code und die meiste Dokumentation sind nun einmal in der Standardsyntax, also kommt man am Ende ohnehin nicht daran vorbei

    • Das Nervigste an ReasonML war für mich, dass LSP nicht richtig funktionierte

  • Ich hätte gern eine ausführlichere Erklärung dazu, wie dependency injection mit einem Effects-System umgesetzt wird. Die Idee, Testwerte und Produktionswerte per Pattern Matching zu binden, klingt interessant, aber allein aus dem Text bekomme ich kein rechtes Gefühl dafür. Und dass das Module-System ein eigenes Typsystem hat, war mir auch neu und ziemlich faszinierend

    • Ich bin Haskeller!

      Zur Frage, warum die Bindung von Test- und Produktionswerten per Pattern Matching im Beispiel nicht ganz klar ist ... Was im Artikel gemeint ist, ist das Free-Monad-plus-Interpreter-Muster: Die Business-Logik führt Aktionen nicht direkt aus, sondern macht aus ihnen Nomen und sammelt sie als AST. Sobald dieses AST existiert, kann man mit ProdAstVisitor und TestAstVisitor echte Ausführung und Tests trennen. Konkret heißt das, dass an jedem AST-Knoten ausgewählt wird, ob Test.ReadFile/WriteFile oder die Produktionsvariante verwendet wird; Test und Prod werden nicht direkt miteinander vermischt. In der Haskell-Community geht der Trend etwas weg vom Free-Monad-plus-Interpreter-Muster, weil der Tagless-Final-Ansatz mit weniger Ceremony denselben Effekt liefert. Zur Bitte, mehr zur Umsetzung von DI mit einem Effects-System zu zeigen ... Ich mache DI mit Effects. Eine Methode, mit der ich zufrieden bin, sieht so aus: Ganz unten liegen Capability-Interfaces wie readTextFile, writeTextFile usw., jeweils pro Fähigkeit getrennt. Diese Klassen sollen keinerlei Fachwissen über die Domäne haben. Darüber kombiniert man Domänenlogik und Capabilities zu Business-Funktionen wie fetchStoredCommands. Ganz oben gibt es dann einen Typ CliApp, und dort werden die konkreten Implementierungen der Capability-Interfaces gebunden. Wenn man etwa einen Logger separat mit einer Mock-Version verdrahtet, lässt sich die Trennung von Produktions- und Testumgebung über Typeclasses modellieren. Entscheidend ist, dass der komplette Effekt-Typ einer Funktion (z. B. ob sie IO ausführt) im Typsystem ausgewiesen wird. Die echte Produktionsimplementierung darf IO verwenden, die Testimplementierung dagegen nicht. Wenn man eine neue Capability (z. B. Caching) ergänzt und die Testimplementierung vergisst, bekommt man einen Compile-Time-Fehler — das sorgt für starke Sicherheit. Ich frage mich, ob sich so etwas Ähnliches auch in OCaml machen lässt. In dem Artikel hieß es, dass Effekt-Propagation dort bislang noch nicht vom Typsystem verfolgt wird