9 ms·

OCaml for the Skeptical: OCaml in a Nutshell (2006)

108 points by ColinWright 6y ago

S4M 6y ago
Last updated in 2006.
- sweeneyrod 6y ago
  Yes, it has a very 2006-era "OCaml as an alternative to C/C++" attitude, hence the claims that OCaml has an extensive library ecosystem and developer tooling: compared to C this is true but not compared to Python/Java in 2020. The suggested tools are also out of date. If you want to try OCaml nowadays you should probably install it with opam and use dune as a build system.
steev 6y ago
This [1] is a a much more detailed course that gives a great introduction to OCaml. [1] https://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/intro/ocaml.html https://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/in...
- johnisgood 6y ago
  There is also https://www.cs.cornell.edu/courses/cs3110/2019fa/textbook/ https://www.cs.cornell.edu/courses/cs3110/2019fa/textbook/. Yours is 2019 Spring, this is 2019 Fall. This version covers many more topics.
ocamlskeptic 6y ago
Curious question: If you are picking OCaml over Rust in 2020 for a new project, what is your reason for doing so (other than being already familiar with OCaml through college courses, or wanting to try out something new for fun) ? The only reason I could think of was being able to compile to JS, but other than that Rust seems to be a superior choice for all the use cases I could have used practically used OCaml for.
- vbrandl 6y ago
  There is some cool stuff for OCaml, that is not (yet) possible in Rust, e.g. building a unikernel using MirageOS (https://mirage.io/ https://mirage.io/)
  - sidkshatriya 6y ago
    It’s very much possible to build a unikernel in rust. Google ‘rust unikernel’ and you’ll get results. In fact I would argue that rust is much more suited to write low level things like operating systems and unikernels than ocaml. Having said that mirage is very cool. It is a unikernel and it has garbage collection. So it’s easy to write robust and secure services! Yeah anything written in rust will probably be faster but then unless you’re a mega company and have mega size deployments this should not really matter to you. Mirage should serve your needs well if you need unikernels
- dwdz 6y ago
  1. No borrow checker 2. Compilation times
- smabie 6y ago
  I've never really seen them as comparable. But I would choose Ocaml over Rust because OCaml is easier, less complex, and more expressive. Also, Rust doesn't support functional programming. OCaml's performance is really quite good and I've never had problems with the GC. Unless the project absolutely couldn't tolerate GC, why would I choose a low level language like Rust over a high level language like Ocaml?
  - Ar-Curunir 6y ago
    Rust offers a better alternative to functional programming: you can mix and match imperative and functional programming without the pitfalls of arbitrary mutable state (which is where most attempts to mix and match run into problems)
    - scns 6y ago
smabie 6y ago
I like Ocaml and it would be a good choice of language for most kinds of projects, especially if good performance is desired. OCaml is dead simple to learn (I always recommend it as the first FP language they should learn) and eminently practical. If you're coming from Haskell or Scala though, OCaml's type system is going to come off as pretty primitive. And in many ways it is primitive, the idea of "type-level" programming isn't really a thing in the OCaml community. My favorite part of OCaml though is that the compiler generates fast, native binaries, which in my opinion is reason enough to choose it over Scala or F#. The language is on par with F#, but notably less expressive than Scala. But if you want a simple language that anyone can pick up quickly, one with a well defined performance profile and a practical, concrete ecosystem, OCaml might be the perfect choice. Just don't expect a Haskell or Scala like experience.
- michaelcampbell 6y ago
  > The language is on par with F#, Isn't F# an Ocaml derivative?
  - smabie 6y ago
    I wouldn't call F# an OCaml derivative, but rather they are both ML derivatives.
    - brmgb 6y ago
      F# literally started as a Caml port to .Net by Don Syme. It's hard to be more derivative than that. It's right there in the historical acknowledgements part of the F# website [1]. [1] https://www.microsoft.com/en-us/research/project/f-at-microsoft-research/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fcambridge%2Fprojects%2Ffsharp%2Fack.aspx https://www.microsoft.com/en-us/research/project/f-at-micros...
    - atombender 6y ago
      It's more fair to say that F# originated as a heavily OCaml-influenced Caml implementation. It was originally called Caml.net [1], after all: "The early conception of F# was simple: to bring the benefits of OCaml to .NET and .NET to OCaml: a marriage between strongly typed functional programming and .NET. Here 'OCaml' meant both the core of the language itself, and the pragmatic approach to strongly-typed functional programming it represented. The initial task was relatively well-defined: the author would re-implement the core of the OCaml language and a portion of its base library to target the .NET Common Language Runtime. The implementation would be fresh, i.e. not using any of the OCaml codebase, for legal clarity. The first lines of the F# implementation were written in December 2001, a front-end for a re-implementation of the core Caml syntax targeting ILX as a back end, and thus to .NET. The initial compiler was written using OCaml." The initial version of F# was very much OCaml without functorial modules or object extensions. [1] https://fsharp.org/history/hopl-draft-1.pdf https://fsharp.org/history/hopl-draft-1.pdf
deleted 6y ago
[deleted]
modernerd 6y ago
Is there a good reason to learn ReasonML instead of OCaml these days, or should I just learn OCaml + js_of_ocaml? I'm interested in building web apps, web servers, and simple WebSocket servers. OCaml appeals to me because it has more escape hatches than Haskell and is higher level than Rust, but I've always found the ReasonML vs OCaml story confusing.
- wk_end 6y ago
  I'm one of the weirdos who likes OCaml syntax, but in my eyes ReasonML is unfortunate. It fractures the community for (ironically) no real reason - not only is it a new syntax, they're now writing a new standard library for it (Belt), as though the three existing ones (plus the JS one!) weren't enough! I don't think the new syntax is particularly nice either. I don't think js_of_ocaml supports any kind of JSX. That's the only real reason to use Reason over OCaml that I know of, and it's a good one. But if I'm being frank, even if OCaml/Reason is a nicer language overall, TypeScript is a statically-typed frontend development story that has way more community buy-in and way fewer rough edges in the ecosystem. Just use it.
  - zbaylin 6y ago
    Belt isn't a standard library for Reason, it's a standard library for Bucklescript that has specific optimizations since it knows it's going to be compiled to JS. Reason uses the same Pervasives/Stdlib as OCaml.
  - modernerd 6y ago
    That's helpful, thanks. The recent syntax switch[1] does feel like it will further fragment the community. And TypeScript has some pretty attractive functional projects: https://github.com/gcanti/fp-ts https://github.com/gcanti/fp-ts https://github.com/Matechs-Garage/matechs-effect https://github.com/Matechs-Garage/matechs-effect [1]: https://reasonml.org/blog/bucklescript-8-1-new-syntax https://reasonml.org/blog/bucklescript-8-1-new-syntax
    - brmgb 6y ago
jopython 6y ago
Wake me up when OCaml get multi-core support.
- shakow 6y ago
  They are actively working on it (https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/5898 https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/...) (HN discussion here, https://news.ycombinator.com/item?id=23380370 https://news.ycombinator.com/item?id=23380370).
- UncleOxidant 6y ago
  They're definitely making progress lately. For a few years there it seemed like it would never happen, but now I'm starting to have some hope.
- dklsf 6y ago
  What will you use multicore support for?
WalterBright 6y ago
I tried to use OCaml once. My main difficulty was the compiler error messages were very primitive, and I had an awful time figuring out what was wrong with the code I was writing. I finally just gave up.
- yawaramin 6y ago
  Ah that's too bad, it really does offer an elegant and efficient programming stack. Admittedly the syntax errors are historically bad but the editor support tool, Merlin, offers more help with those, with messages like "Syntax error after ... expecting `=' "

108 points by ColinWright 6y ago

S4M 6y ago

Last updated in 2006.

sweeneyrod 6y ago
Yes, it has a very 2006-era "OCaml as an alternative to C/C++" attitude, hence the claims that OCaml has an extensive library ecosystem and developer tooling: compared to C this is true but not compared to Python/Java in 2020. The suggested tools are also out of date. If you want to try OCaml nowadays you should probably install it with opam and use dune as a build system.

steev 6y ago

This [1] is a a much more detailed course that gives a great introduction to OCaml. [1] https://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/intro/ocaml.html https://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/in...

johnisgood 6y ago
There is also https://www.cs.cornell.edu/courses/cs3110/2019fa/textbook/ https://www.cs.cornell.edu/courses/cs3110/2019fa/textbook/. Yours is 2019 Spring, this is 2019 Fall. This version covers many more topics.

ocamlskeptic 6y ago

Curious question: If you are picking OCaml over Rust in 2020 for a new project, what is your reason for doing so (other than being already familiar with OCaml through college courses, or wanting to try out something new for fun) ? The only reason I could think of was being able to compile to JS, but other than that Rust seems to be a superior choice for all the use cases I could have used practically used OCaml for.

vbrandl 6y ago
There is some cool stuff for OCaml, that is not (yet) possible in Rust, e.g. building a unikernel using MirageOS (https://mirage.io/ https://mirage.io/)
- sidkshatriya 6y ago
  It’s very much possible to build a unikernel in rust. Google ‘rust unikernel’ and you’ll get results. In fact I would argue that rust is much more suited to write low level things like operating systems and unikernels than ocaml. Having said that mirage is very cool. It is a unikernel and it has garbage collection. So it’s easy to write robust and secure services! Yeah anything written in rust will probably be faster but then unless you’re a mega company and have mega size deployments this should not really matter to you. Mirage should serve your needs well if you need unikernels
dwdz 6y ago
1. No borrow checker 2. Compilation times
smabie 6y ago
I've never really seen them as comparable. But I would choose Ocaml over Rust because OCaml is easier, less complex, and more expressive. Also, Rust doesn't support functional programming. OCaml's performance is really quite good and I've never had problems with the GC. Unless the project absolutely couldn't tolerate GC, why would I choose a low level language like Rust over a high level language like Ocaml?
- Ar-Curunir 6y ago
  Rust offers a better alternative to functional programming: you can mix and match imperative and functional programming without the pitfalls of arbitrary mutable state (which is where most attempts to mix and match run into problems)
  - scns 6y ago

smabie 6y ago

I like Ocaml and it would be a good choice of language for most kinds of projects, especially if good performance is desired. OCaml is dead simple to learn (I always recommend it as the first FP language they should learn) and eminently practical. If you're coming from Haskell or Scala though, OCaml's type system is going to come off as pretty primitive. And in many ways it is primitive, the idea of "type-level" programming isn't really a thing in the OCaml community. My favorite part of OCaml though is that the compiler generates fast, native binaries, which in my opinion is reason enough to choose it over Scala or F#. The language is on par with F#, but notably less expressive than Scala. But if you want a simple language that anyone can pick up quickly, one with a well defined performance profile and a practical, concrete ecosystem, OCaml might be the perfect choice. Just don't expect a Haskell or Scala like experience.

michaelcampbell 6y ago
> The language is on par with F#, Isn't F# an Ocaml derivative?
- smabie 6y ago
  I wouldn't call F# an OCaml derivative, but rather they are both ML derivatives.
  - brmgb 6y ago
    F# literally started as a Caml port to .Net by Don Syme. It's hard to be more derivative than that. It's right there in the historical acknowledgements part of the F# website [1]. [1] https://www.microsoft.com/en-us/research/project/f-at-microsoft-research/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fcambridge%2Fprojects%2Ffsharp%2Fack.aspx https://www.microsoft.com/en-us/research/project/f-at-micros...
  - atombender 6y ago
    It's more fair to say that F# originated as a heavily OCaml-influenced Caml implementation. It was originally called Caml.net [1], after all: "The early conception of F# was simple: to bring the benefits of OCaml to .NET and .NET to OCaml: a marriage between strongly typed functional programming and .NET. Here 'OCaml' meant both the core of the language itself, and the pragmatic approach to strongly-typed functional programming it represented. The initial task was relatively well-defined: the author would re-implement the core of the OCaml language and a portion of its base library to target the .NET Common Language Runtime. The implementation would be fresh, i.e. not using any of the OCaml codebase, for legal clarity. The first lines of the F# implementation were written in December 2001, a front-end for a re-implementation of the core Caml syntax targeting ILX as a back end, and thus to .NET. The initial compiler was written using OCaml." The initial version of F# was very much OCaml without functorial modules or object extensions. [1] https://fsharp.org/history/hopl-draft-1.pdf https://fsharp.org/history/hopl-draft-1.pdf

deleted 6y ago

[deleted]

modernerd 6y ago

Is there a good reason to learn ReasonML instead of OCaml these days, or should I just learn OCaml + js_of_ocaml? I'm interested in building web apps, web servers, and simple WebSocket servers. OCaml appeals to me because it has more escape hatches than Haskell and is higher level than Rust, but I've always found the ReasonML vs OCaml story confusing.

wk_end 6y ago
I'm one of the weirdos who likes OCaml syntax, but in my eyes ReasonML is unfortunate. It fractures the community for (ironically) no real reason - not only is it a new syntax, they're now writing a new standard library for it (Belt), as though the three existing ones (plus the JS one!) weren't enough! I don't think the new syntax is particularly nice either. I don't think js_of_ocaml supports any kind of JSX. That's the only real reason to use Reason over OCaml that I know of, and it's a good one. But if I'm being frank, even if OCaml/Reason is a nicer language overall, TypeScript is a statically-typed frontend development story that has way more community buy-in and way fewer rough edges in the ecosystem. Just use it.
- zbaylin 6y ago
  Belt isn't a standard library for Reason, it's a standard library for Bucklescript that has specific optimizations since it knows it's going to be compiled to JS. Reason uses the same Pervasives/Stdlib as OCaml.
- modernerd 6y ago
  That's helpful, thanks. The recent syntax switch[1] does feel like it will further fragment the community. And TypeScript has some pretty attractive functional projects: https://github.com/gcanti/fp-ts https://github.com/gcanti/fp-ts https://github.com/Matechs-Garage/matechs-effect https://github.com/Matechs-Garage/matechs-effect [1]: https://reasonml.org/blog/bucklescript-8-1-new-syntax https://reasonml.org/blog/bucklescript-8-1-new-syntax
  - brmgb 6y ago

jopython 6y ago

Wake me up when OCaml get multi-core support.

shakow 6y ago
They are actively working on it (https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/5898 https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/...) (HN discussion here, https://news.ycombinator.com/item?id=23380370 https://news.ycombinator.com/item?id=23380370).
UncleOxidant 6y ago
They're definitely making progress lately. For a few years there it seemed like it would never happen, but now I'm starting to have some hope.
dklsf 6y ago
What will you use multicore support for?

WalterBright 6y ago

I tried to use OCaml once. My main difficulty was the compiler error messages were very primitive, and I had an awful time figuring out what was wrong with the code I was writing. I finally just gave up.

yawaramin 6y ago
Ah that's too bad, it really does offer an elegant and efficient programming stack. Admittedly the syntax errors are historically bad but the editor support tool, Merlin, offers more help with those, with messages like "Syntax error after ... expecting `=' "