Why I Like OCaml

# Why I Like OCaml People often ask me "Hey, teej, you're a cool streamer (on twitch.tv/teej_dv btw). Why do you like OCaml so much?"[^1]. Many such cases. ## Super Short Summary - Type Inference - Type System ## Type System: Inference OCaml has a Hindley-Milner type system, which is just a really fancy way of saying "Everything can always only be one type a time" and "Very cool type inference". Don't let the Haskellers trick you into thinking academic words are scary - that's how they keep their monopoly on writing academic papers. Instead, let's look at an example. The following code defines a `user` type, that has a `name` field, which contains a string and an `age` field, which contains an `int`. ```neovim {"update":true,"path":"_/code/1720462419143.ml","timestamp":1725485238759} <pre> type user = { name: string; age: int } </pre> ``` If we write a function in the same scope, like: ```neovim {"update":true,"path":"_/code/1720462815610.ml","timestamp":1725485238474} <pre> let make_user name age = { name; age } </pre> ``` The signature of the function will look like: ```neovim {"update":true,"path":"_/code/1720463027348.mli","timestamp":1725485238192} <pre> type user = { name : string; age : int } val make_user : string -> int -> user </pre> ``` Which is to say, pass a `string` and then an `int` and you'll get a `user` (You can read the arrows as "applications", which once again is fancy speak for "calling functions with parameters". So `make_user` takes two arguments and then returns a `user`). > [!NOTE] > You will **not** get any object with the fields `name` and `age`, you'll get a `user`. Now, this might not seem too interesting yet, but bear with me! If we continue to write more functions in the same scope as the type declaration for `user`, such as `average_age`, OCaml will continue to infer the types for us! ```neovim {"update":true,"path":"_/code/1720463217798.ml","timestamp":1725485237900} <pre> let average_age users = let total_age = List.fold_left (fun acc u -> acc + u.age) 0 users in let num_users = List.length users in total_age / num_users </pre> ``` ^average-age and the inferred type signature: ```neovim {"update":true,"path":"_/code/1720463253702.mli","timestamp":1725485237624} <pre> val average_age: user list -> int </pre> ``` This function can **only** take a `list of users`, which we know because we access the `u.age` field in the `fold_left` in [[Why I Like OCaml#^average-age|average-age]] and we know that it must return an integer because `age` is an int. It's not possible to have the scenario like you might have in "Type"script: If we start with a function like this: ```neovim {"update":true,"path":"_/code/1720463979332.ts","timestamp":1725485237295} <pre> interface User { name: string; age: number; } function average_age(users: User[]) { let age = 0; for (let user of users) { age += user.age; } return age / users.length; } </pre> ``` and then do: ```neovim {"update":true,"path":"_/code/1720464079589.ts","timestamp":1725485236959} <pre> interface User { name: string; age: number; } function average_age(users: User[]) { let age = 0; for (let user of users) { age += user.age; } if (age > 100) { return "lol types"; } return age / users.length; } </pre> ``` Typescript then just says "Oh, OK. You want a function that returns a `number | string`".... What?! No, Nobody actually wants that. And then don't get ThePrimeagen started on what you can do with `number | string` with arrays. It's not gonna be a good time for anyone. And also, I'm **NOT** going to start the twitter discourse again on whether you should annotate return types in Typescript. I don't care. I'm going to keep writing OCaml instead and trying to make it SAAS ready!!! On a serious note, I find this kind of thing a fundamental frustration in Typescript and often leads to sprawling unions of many different types, without exhaustive checking and complex type cross pollination. However, if you tried this in OCaml, you would get an error: ```neovim {"update":true,"path":"_/code/1721180769696.ml","timestamp":1725485236664} <pre> type user = { name: string; age: int } let average_age users = let total_age = List.fold_left (fun acc u -> acc + u.age) 0 users in let num_users = List.length users in if total_age > 100 then "types" else total_age / num_users </pre> ``` ^1721180769696 Since the first returned value of this function is a string, it says that now you can't return an `int`. If we had instead declared the function must return an int, you'd get a different error: ```neovim {"update":true,"path":"_/code/1721180922826.ml","timestamp":1725485236377} <pre> type user = { name: string; age: int } let average_age users : int = let total_age = List.fold_left (fun acc u -> acc + u.age) 0 users in let num_users = List.length users in if total_age > 100 then "types" else total_age / num_users </pre> ``` ^1721180922826 If you wanted to return a union of types in OCaml, we need to introduce my next favorite aspect of the type system. ## Type System: Variants Of course, because this is programming we can't have one name for things. You may have heard of these as: - [Tagged Unions](https://en.wikipedia.org/wiki/Tagged_union), which are related to [Disjoint Unions](https://en.wikipedia.org/wiki/Disjoint_union) - [Rust Enums](https://doc.rust-lang.org/rust-by-example/custom_types/enum.html) - `Sum Types`, which are related to [Algebraic Data Types](https://en.wikipedia.org/wiki/Algebraic_data_type) - The thing I constantly complain that Golang is missing ### Enumerations The first version of Variants we'll discuss are the simplest: they look just like simple enumerations. Consider the following. ```neovim {"update":true,"path":"_/code/1720464647402.ml","timestamp":1725485236091} <pre> type colors = | Red | Blue | Green </pre> ``` ^1720464647402 We define a type called `colors` (not `colours`, America btw) that is really just an [Enumerated Data Type](https://ocaml.org/docs/basic-data-types#enumerated-data-types). Which is to say, a list of possible options. This isn't anything too special at first glance, even C can do this: ```neovim {"update":true,"path":"_/code/1721181811482.c","timestamp":1725485235835} <pre> typedef enum Colors { RED, GREEN, BLUE } colors_t; </pre> ``` ^1721181811482 However, OCaml's variants are a lot different than C's enums ```neovim {"update":true,"path":"_/code/1721182061388.ml","timestamp":1725485235545} <pre> type color = Red | Green | Blue let print_color = function | Red -> print_string "Red" | Green -> print_string "Green" | Blue -> print_string "Blue" let incomplete = function | Red -> print_string "Red" | Green -> print_string "Green" </pre> ``` ```neovim ``` ^1721182061388 The OCaml compiler can detect both: - That we are pattern matching against the `color` type - That we have no matched against all the possible `color` variants. This is great! (and of course, doesn't suffer from footgun fallthrough choices from languages like C) ### Constructors But!! We can do more than just list an enumeration of options, we can actually store data in the variants as well! We can return to the typescript example from earlier: ```neovim {"update":true,"path":"_/code/1721182362295.ml","timestamp":1725485235262} <pre> type user = { name: string; age: int } type goofy = | Message of string | Average of int let average_age users = let total = List.fold_left (fun acc u -> acc + u.age) 0 users in let num_users = List.length users in match total with | total when total > 100 -> Message "wow, that's a lot of people!" | total -> Average (total / num_users) </pre> ``` ^1721182362295 Now the type signature of `average_user` is: ```neovim {"update":true,"path":"_/code/1721182580809.mli","timestamp":1725485234982} <pre> type user = { name: string; age: int } type goofy = | Message of string | Average of int val average_age : user list -> goofy </pre> ``` ^1721182580809 It's not `int | string`, it's **ONE TYPE**. It can **ONLY** be the `goofy` type. And anywhere that we access the `goofy` type, we **MUST** handle all the cases (or explicitly discard them). ### Polymorphism OK, the last variation of variants I'll talk about in this post, so please stick with me! While this kind of variant isn't **exactly** the same as generics in some other languages, I think it's a good enough starting point. Consider the following `option` type in OCaml: ```neovim {"update":true,"path":"_/code/1721183553138.ml","timestamp":1725485234693} <pre> type 'a option = | Some of 'a | None </pre> ``` ^1721183553138 In OCaml, the `'a` means a "type hole" - but that's basically like the `T` you would use in Typescript. So you can swap everywhere that you see `'a` with some concrete type and it would make sense. This makes the type `polymorphic` over type `'a`[^2]. Below are some examples of values that have the `'a option` type ```neovim {"update":true,"path":"_/code/1721183642179.ml","timestamp":1725485234399} <pre> type 'a option = | Some of 'a | None (* Explicit type signatures for clarity, they aren't required *) let value1 : int option = Some 100 let value2 : string option = Some "CrimsonMama" let value3 : string option = None </pre> ``` ^1721183642179 And here's some examples of functions that can operate on options: ```neovim {"update":true,"path":"_/code/1721232513155.ml","timestamp":1725485234117} <pre> type 'a option = | Some of 'a | None (* takes a function `f` and applies it to the value inside the option *) let map f = function | Some value -> Some (f value) | None -> None (* gets the value inside the option or raises an exception, like .unwrap() in rust (panics are just bad exceptions, btw) *) let unwrap = function | Some value -> value | None -> failwith "panic! #safety" </pre> ``` ^1721232513155 > [!NOTE] Possible Other Post > If you'd like to hear more about GADTs, Polymorphic Variants, or some other more advanced OCaml type stuff, [[contact|Tell Me!]] ## Pattern Matching OCaml's `match` statement has two properties that I miss every time I write in a different language: - (Builtin) Exhaustiveness Checking - Pattern Matching ### Exhaustiveness Checking We've seen an example earlier in the [[#Enumerations]] section about how OCaml has an error when you don't match against all the possibilities for a particular expression. ```neovim {"update":true,"path":"_/code/1721239000438.ml","timestamp":1725485233828} <pre> let reply (str : string) = match str with | "hello" -> "hey!" | "goodbye" -> "see you!" </pre> ``` ^1721239000438 Once we include a pattern that can match any string - which is just an identifier, to capture the variable, the compiler is happy again! ```neovim {"update":true,"path":"_/code/1721239174279.ml","timestamp":1725485233537} <pre> let reply (str: string) = match str with | "hello" -> "hey!" | "goodbye" -> "see you!" | other -> "not sure what to say" </pre> ``` ^1721239174279 ### Variant Matching ```neovim {"update":true,"path":"_/code/1721239371633.ml","timestamp":1725485233261} <pre> (* This is defined by the OCaml standard library *) type ('ok, 'err) result = | Ok of 'ok | Error of 'err (* Example of how you could encode an http error *) type http_error = { code: int; message: string; } (* Example of how you could encode an http response, where you're just interested in the body, and everything else is an error *) type response = (string, http_error) result let handle_response response = match response with | Ok message -> Format.printf "Success!: %s" message | Error { code = 404; message } -> Format.printf "!! 404 Not Found !! %s" message; | Error { code = 418; _ } -> Format.printf "LOL TEAPOTS"; | Error err -> Format.printf "Error: %d - %s\n" err.code err.message; </pre> ``` ^1721239371633 ## Immutability While the Javascript community argues about whether they should use `const` or `let` (since both are a lie) OCamlers are able to trust that they have have actual, real immutability. Everything in OCaml is immutable by default ```neovim {"update":true,"path":"_/code/1721237395872.ml","timestamp":1725485232994} <pre> (* In this example, `age` can be *mutated* because it's marked by `mutable` *) type mutable_user = { name: string; mutable age: int } let birthday user = (* Note, you don't use an `=` sign here, because you are mutating the value. *) user.age <- user.age + 1 </pre> ``` ^1721237395872 However, if you tried to do this with a struct without the `mutable` keyword, you would be unable to do this and get an error during compilation. ```neovim <pre> type user = { name: string; age: int } let birthday user = user.age <- user.age + 1 └──── The record field age is not mutable </pre> ``` (TODO: I don't actually like this sentence, it was just fun to write on stream) The fact that the Javascript community is fighting over `const` vs `let` shows that there is value in having this supported at the language feature but (as is usual) it's implemented in the wrong way for JS, so they completely miss the point. You can never be sure if someone is going to modify the array of users (or any of the users inside of the array) when you pass that to a function - in OCaml it's just not possible to change the originally passed data structure. ```neovim {"update":true,"path":"_/code/1721237913036.js","timestamp":1725485232729} <pre> const x = [1, 2, 3]; // You can append to the list x.push(4); // You can also change the value of an element x[1] = "hi"; // ... Not very `const` now, are we? console.log(x); </pre> ``` ^1721237913036 # TODO - Modules - Interfaces <3 - Everything is an expression <3 - Tooling - Incredibly fast compiler - Community # Conclusion Wow, you read all of that? You'd probably like OCaml then. Come hang out with us and make it SaaS ready. There are so many fun things to build and learn! As I've said before: > Everything that is currently built was once not built [^1]: Proof: - ![[Pasted image 20240704113210.png|400]] - ![[Pasted image 20240704123909.png|400]] [^2]: I know that there are also `polymorphic variants` in OCaml and that they are different., but I think this is still how you would describe this kind of polymorphism.