I read the first edition and it was basically “how to use janestreet libraries and its tools to write programs”
It was insightful and nice (I actually enjoy using Janestreet’s libraries when programming in OCaml since they feel a litlle “Haskell-y”), but I felt that the amount of Janestreet promotion in the book was unfortunate for a book about OCaml. (I would be fine if it was titled “OCaml at Janestreet”)
Skimming through this version, it looks like this is the same book but rewritten to be up to date with the Core/Base split in Janestreet’s libraries. Am I missing something?
No, this is the same Jane Street book, and it’s very unfortunate that OCaml doesn’t have good introductory books other than this one. I really think it’s one of the things holding OCaml back.
The book is not bad, it’s pretty decent actually, but every time I tried to teach OCaml to someone their inevitably stumbled upon this book and their response has always been along the lines of “oh, the standard library is so bad that I have to use this other 3rd party standard library? this language is a joke”.
I’ve been working on one, and I used a strong copyleft license (CC-BY-SA) and thus closed the door for myself for ever profiting from that work, in hope that people will join, but they are much happier to contribute to the proprietary (CC-BY-NC-ND) Jane Street book somehow. ;)
The Poignant Guide might have gone too far, but I feel like “Learn You a Haskell” and “Clojure for the Brave and True” and similar books have done a good job of including “cute” elements that helped with memory/visualization without stealing attention or hiding important information.
A decade ago I’ve spent a lot of time learning Haskell and trying to apply that knowledge solving practical problems. Maybe my brain was already wired in a different direction, but I’ve failed to finish every non-trivial project I was starting. During this time I was showing the same amount of zeal and evanghelism in praising Haskell whenever I got the chance, the rust community is giving us nowadays.
Then I’ve tried Scala, and things were better, but I was cheating writing Scala the Java way.
To this day I believe that the masses don’t need Functional programming in its fullest, but maybe a few functional features here and there that can make the code more compact. Or maybe I am failed and bitter functional developer :).
Both Scala and Haskell are very complex languages. If you want to learn statically typed functional programming, Elm can be a cool first experience. If you prefer dynamic, Elixir is good too.
Then you’re in luck, because OCaml is not purely functional :-). It offers you a blend of imperative and functional that allows you to pick the best flavor for a particular task (a bit like Java-style Scala, I’d say). You can have actual pure values where it simplifies your life (caches, messages in concurrent programming, etc.) but you also don’t need to embed in a monad to perform IO.
Ditto. I learned a lot of cool and important concepts from Haskell, and I try to apply those ideas in other languages, but overall I spent too much time fighting with the language to make it worthwhile for me to use Haskell itself.
Haskell, Smalltalk, and Erlang are all languages that I think everyone should learn, but very few people should use. They all take a useful idea to its extreme and learning to think in the ways that they encourage gives you a useful set of tools that can be applied almost anywhere.
Will the addition of multicore and algebraic effects make OCaml gain more traction?
It’s difficult to make predictions, especially about the future, but in my opinion, I very much doubt these things would have any effect on traction. In my experience people will not use OCaml because they don’t know, or don’t want to know functional programming, or simply don’t want it for various personal or organizational reasons. It’s almost never about the lack of any particular feature. In fact, people who reject OCaml outright very rarely have any idea what feature OCaml has or lacks.
Where does it stand compared to F#, Haskell, Scala or Rust right now?
I am not sure comparing any of those languages makes sense.
F# is .NET tech, yes you can run it on Linux or whatever, but realistically speaking, if you are not into Windows/.NET you would never use this. Also F# has the fewest features of the bunch, which is not necessarily a bad thing, but you mentioned fancy features like algebraic effects whereas F# is late 80s level of sophistication. F# doesn’t even have ML-style modules. And btw, this is not a me taking at jab at F#, 80s level of sophistication is great when the industry is still stuck in the 60s. Of course, F# is great if you are stuck in the .NET ecosystem.
Haskell is a non-strict language. OCaml makes it much easier to reason about performance, and to get good performance. Haskell has many features OCaml will never have (too many to list here), but now they have linear functions, and are discussing ways of adding dependent types. Very cool stuff, but unrelated to the reason people use OCaml.
Scala is in the Java ecosystem. Just like with F#, Scala is a non-option if you are not already in the Java ecosystem. And if you are, all the other languages you mention will not be an option, so it’s all moot.
Rust is not a functional language and has a very different applicability domain compared to any of the languages mentioned so far which makes any comparison difficult and pointless. It’s the only one specifically targeting low-level stuff. Yes, I am very aware of MirageOS, it’s a very niche thing, and has far less applicability than Rust in general. E.g. people use rust to run code on microcontrollers today. Feature wise, its type system is the most limited compared to all languages discussed above. I very much doubt Rust will ever get algebraic effects, because algebraic effects are hard without a GC. And I have no idea if OCaml will ever get linear types, or if they even want them. Linear types are difficult to mix with effects.
Algebraic effects and linear types are very different things, but both can be employed to tame IO-effects, and both OCaml (with effects) and Rust (with linear types) do exactly that. So since they solved “the IO problem”, I very much doubt they would be interested in adding more features, especially Rust.
For the record, I am working on a language that has both effects and linear types.
One of the killers of D’s momentum over a decade ago was the conflict between two (three?) possible standard libraries.
While a lot of other problems have been solved, Ocaml still suffers from this one. Until the whole mess with multicore/lwt/async sorts itself out (which will also impact any standard library), and the community completely settles on a single standard library, I do not think there is that much hope for increased traction. Also: documentation that isn’t just type signatures, which (especially) many third-party libraries suffer from.
For better or worse, Rust is a better option for the time being, mostly due to better tooling and a vastly larger library ecosystem. I’ve been down this road several times, and ecosystem size almost always wins out, unless you’re tinkering.
Until the whole mess with multicore/lwt/async sorts itself out (which will also impact any standard library), and the community completely settles on a single standard library …
Effects mean you don’t need monadic libraries like lwt and async now, and most “concurrent” code can just be written as plain OCaml, so things will likely converge. Porting code is straight-forward and can be done incrementally. See e.g. the migration instructions at lwt_eio (which allows running Lwt code under the (effects-based) Eio event loop).
For context, u/talex5 is the main dev of Eio. I think a lot of us (OCaml users) are looking forward to a world without monadic IO libraries, and Eio is exactly that, along with clean primitives for byte streams, structured concurrency, etc. If there’s a time where OCaml can gain more interest, I think OCaml 5.0 (or 5.1) is exactly that time.
I read the first edition and it was basically “how to use janestreet libraries and its tools to write programs”
It was insightful and nice (I actually enjoy using Janestreet’s libraries when programming in OCaml since they feel a litlle “Haskell-y”), but I felt that the amount of Janestreet promotion in the book was unfortunate for a book about OCaml. (I would be fine if it was titled “OCaml at Janestreet”)
Skimming through this version, it looks like this is the same book but rewritten to be up to date with the Core/Base split in Janestreet’s libraries. Am I missing something?
No, this is the same Jane Street book, and it’s very unfortunate that OCaml doesn’t have good introductory books other than this one. I really think it’s one of the things holding OCaml back.
The book is not bad, it’s pretty decent actually, but every time I tried to teach OCaml to someone their inevitably stumbled upon this book and their response has always been along the lines of “oh, the standard library is so bad that I have to use this other 3rd party standard library? this language is a joke”.
I’ve been working on one, and I used a strong copyleft license (CC-BY-SA) and thus closed the door for myself for ever profiting from that work, in hope that people will join, but they are much happier to contribute to the proprietary (CC-BY-NC-ND) Jane Street book somehow. ;)
https://ocamlbook.org/
The Poignant Guide might have gone too far, but I feel like “Learn You a Haskell” and “Clojure for the Brave and True” and similar books have done a good job of including “cute” elements that helped with memory/visualization without stealing attention or hiding important information.
Thanks for your work on that and for linking it!
A decade ago I’ve spent a lot of time learning Haskell and trying to apply that knowledge solving practical problems. Maybe my brain was already wired in a different direction, but I’ve failed to finish every non-trivial project I was starting. During this time I was showing the same amount of zeal and evanghelism in praising Haskell whenever I got the chance, the rust community is giving us nowadays.
Then I’ve tried Scala, and things were better, but I was cheating writing Scala the Java way.
To this day I believe that the masses don’t need Functional programming in its fullest, but maybe a few functional features here and there that can make the code more compact. Or maybe I am failed and bitter functional developer :).
Both Scala and Haskell are very complex languages. If you want to learn statically typed functional programming, Elm can be a cool first experience. If you prefer dynamic, Elixir is good too.
Then you’re in luck, because OCaml is not purely functional :-). It offers you a blend of imperative and functional that allows you to pick the best flavor for a particular task (a bit like Java-style Scala, I’d say). You can have actual pure values where it simplifies your life (caches, messages in concurrent programming, etc.) but you also don’t need to embed in a monad to perform IO.
Ditto. I learned a lot of cool and important concepts from Haskell, and I try to apply those ideas in other languages, but overall I spent too much time fighting with the language to make it worthwhile for me to use Haskell itself.
Haskell, Smalltalk, and Erlang are all languages that I think everyone should learn, but very few people should use. They all take a useful idea to its extreme and learning to think in the ways that they encourage gives you a useful set of tools that can be applied almost anywhere.
Other forms of this book:
The first edition of this book was published in 2013.
Will the addition of multicore and algebraic effects make OCaml gain more traction?
Where does it stand compared to F#, Haskell, Scala or Rust right now?
It’s difficult to make predictions, especially about the future, but in my opinion, I very much doubt these things would have any effect on traction. In my experience people will not use OCaml because they don’t know, or don’t want to know functional programming, or simply don’t want it for various personal or organizational reasons. It’s almost never about the lack of any particular feature. In fact, people who reject OCaml outright very rarely have any idea what feature OCaml has or lacks.
I am not sure comparing any of those languages makes sense.
F# is .NET tech, yes you can run it on Linux or whatever, but realistically speaking, if you are not into Windows/.NET you would never use this. Also F# has the fewest features of the bunch, which is not necessarily a bad thing, but you mentioned fancy features like algebraic effects whereas F# is late 80s level of sophistication. F# doesn’t even have ML-style modules. And btw, this is not a me taking at jab at F#, 80s level of sophistication is great when the industry is still stuck in the 60s. Of course, F# is great if you are stuck in the .NET ecosystem.
Haskell is a non-strict language. OCaml makes it much easier to reason about performance, and to get good performance. Haskell has many features OCaml will never have (too many to list here), but now they have linear functions, and are discussing ways of adding dependent types. Very cool stuff, but unrelated to the reason people use OCaml.
Scala is in the Java ecosystem. Just like with F#, Scala is a non-option if you are not already in the Java ecosystem. And if you are, all the other languages you mention will not be an option, so it’s all moot.
Rust is not a functional language and has a very different applicability domain compared to any of the languages mentioned so far which makes any comparison difficult and pointless. It’s the only one specifically targeting low-level stuff. Yes, I am very aware of MirageOS, it’s a very niche thing, and has far less applicability than Rust in general. E.g. people use rust to run code on microcontrollers today. Feature wise, its type system is the most limited compared to all languages discussed above. I very much doubt Rust will ever get algebraic effects, because algebraic effects are hard without a GC. And I have no idea if OCaml will ever get linear types, or if they even want them. Linear types are difficult to mix with effects.
Algebraic effects and linear types are very different things, but both can be employed to tame IO-effects, and both OCaml (with effects) and Rust (with linear types) do exactly that. So since they solved “the IO problem”, I very much doubt they would be interested in adding more features, especially Rust.
For the record, I am working on a language that has both effects and linear types.
Sounds interesting - have you published anything about it so far?
Not yet.
One of the killers of D’s momentum over a decade ago was the conflict between two (three?) possible standard libraries.
While a lot of other problems have been solved, Ocaml still suffers from this one. Until the whole mess with multicore/lwt/async sorts itself out (which will also impact any standard library), and the community completely settles on a single standard library, I do not think there is that much hope for increased traction. Also: documentation that isn’t just type signatures, which (especially) many third-party libraries suffer from.
For better or worse, Rust is a better option for the time being, mostly due to better tooling and a vastly larger library ecosystem. I’ve been down this road several times, and ecosystem size almost always wins out, unless you’re tinkering.
Effects mean you don’t need monadic libraries like lwt and async now, and most “concurrent” code can just be written as plain OCaml, so things will likely converge. Porting code is straight-forward and can be done incrementally. See e.g. the migration instructions at lwt_eio (which allows running Lwt code under the (effects-based) Eio event loop).
You can even run both Lwt and Async code together, along with new effects based Eio code, in a single domain. See e.g. https://github.com/talex5/async-eio-lwt-chimera!
For context, u/talex5 is the main dev of Eio. I think a lot of us (OCaml users) are looking forward to a world without monadic IO libraries, and Eio is exactly that, along with clean primitives for byte streams, structured concurrency, etc. If there’s a time where OCaml can gain more interest, I think OCaml 5.0 (or 5.1) is exactly that time.