It's cool to see a link about learning OCaml so high on HN. I started teaching myself OCaml a few months ago and I really like it. Here's a few things I like so far and why I think anyone that uses Go or Rust should give OCaml a look:

1. OCaml compiles to a binary like Go and Rust do

2. The type system is helpful without being a huge burden on learning/productivity (unlike Rust and Haskell)

3. Garbage collection

4. Pattern matching and algebraic data types (like Rust)

5. OCaml is plenty fast at CPU bound work(slower than Rust, faster than Go) despite not being parallel (yet)

Those are my takeaways of what I enjoy about OCaml so far. It has been the most approachable typed functional language that I've looked at yet! Depending on the type of things you want to learn and problems you want to solve, Your Mileage May Vary.

Rust was originally implemented in OCaml, and takes a lot of cues from the ML family, as you've noted.

My power combo is F# and Rust. F# is fairly fast, has great tooling and rather expressive. And for the parts I need the speed, Rust fits in nicely. I can keep safety, while maintaining decent expressiveness. Something like Rust is needed, because when you need manual memory control, you really need it. With F#, I could measure the impact of every single allocation, even though short lived GC items are cheap.

Does F# have easy C interop, so you can call into Rust easily like you can from say, Python?

C interop is quite easy from .NET languages. Here's a simple example in F#:

https://msdn.microsoft.com/en-us/library/dd393785.aspx

That example is a bit Windows specific, but it works similarly with Mono on Linux and OS X:

http://www.mono-project.com/docs/advanced/pinvoke/

Those examples there are in C#, but PInvoke works almost identically in F#.

>1. OCaml compiles to a binary like Go and Rust do

And Haskell.

>2. The type system is helpful without being a huge burden on learning/productivity (unlike Rust and Haskell)

What? The type system is partly why my coauthor can use Haskell, unlike JS or Java. Haskell was her first time ever programming and now she's teaching Haskell to her 10 year old son.

I use Haskell in my day job, I couldn't do my job without the type system!

So in terms of learning and productivity in Haskell (can't speak for Rust), I will strongly disagree here.

The rest of the points apply for Haskell as well.

Haskell doesn't need to be hard to learn at all, it hasn't had the learning resources it deserves and expectations weren't being set properly. It's more like learning a new way to program (functionally) rather than a dialect of an existing paradigm (imperative, but we give you a map and a reduce function).

That paradigm (functions alone) is very simple but the implications are non-obvious and require a method of introduction that involves a lot of exercises.

I'm sorry if this sounds rude, but what's the point you're trying to make? I can't quite figure it out.

OP suggests Haskell's type system interferes with productivity. GPP disagrees.

> OCaml is [...] faster than Go

On what basis do you say this? I'm not claiming to know the answer, but the (terrible) internet benchmarks I can find put them roughly neck-to-neck.

This is also great cheat sheet for someone still getting used to the OCaml syntax.

I usually advise people to pretend that double semicolons don't exist for anything but the interactive top level. In source files, you can forget about double semis entirely as long as you just remember to always assign the result of an imperative statement to the dummy "_" name.

    let _ = print_string "hi"

Then you can think of ;;<enter> as merely a fancy way of hitting the return key in the interactive REPL. There's also a way to use a different key mapping (control+enter) instead of ;; in utop, so there would be no reason to even acknowledge the existence of double semis. https://github.com/diml/utop/issues/131

This is one thing I'm on the fence about F# doing "better", double semis are replaced by requiring you do something with your result, either assigning the result of piping it to the "ignore" builtin.

In some way, OCaml can be thought of doing this as well: https://xivilization.net/~marek/blog/2014/12/28/reinventing-... You can consider the ; operator as a binary operator evaluating the left side, throwing away the result and then avaluating the right side and returning that result.

So in this case, you can just imagine you are using F# then you should be happy with OCaml. (Configure utop as I suggested for the full effect).

That should at least clear up a small distraction for you so that you can make your decision based on fundamental strengths/weaknesses instead of aesthetics made inconsequential by configuration.

I never use double semi colons for anything, but you'd use a simple semi colon after that statement:

    let msg = "hi" in
    print_string msg;

What's better about using "let _"?

Single semicolons simply evaluates several expressions and returns the last one, but if you use them in a module definition (like every file is by default), you'll be coerced into using double semis.

The advantage over your version (with the single semicolon) is that in your version, you cannot now create a standard exported module value binding after that single semicolon, because the parser interprets that next let binding as a continuation of the single semicolon expression, so your only hope is to use double semis to escape back to normal module body parser context.

Function bodies (or any other expression really) don't have that same issue, but I might suggest avoiding single semicolons even in that case so that you have fewer edge cases to memorize. Here is the simplest possible convention I can think of that requires the smallest amount of memorization:

- Forget about all semicolons, single or double (just think of ;; as a way to press enter in the top interactive REPL).

- Module bodies (like every file by default) are just exporting a series of bindings. If you want to evaluate an imperative command inside a module body, export its result to "_".

- Function bodies are expressions. If you want to evaluate an imperative command inside a function body (or any other expression), use `let in` like you would for any other temporary variable, but use the variable name "_" and simply don't use it.

The idea is you can write this:

    let _ = print_string "foo"
    let _ = print_string "bar"

at the top level.

Of course you can write

    let msg = "foo" in print_string msg
    let msg = "bar" in print_string msg

(which isn't at issue, except no semicolons are needed.)

But you can't write

    print_string "foo"
    print_string "bar"

without semicolons.

> The idea is you can write this:

>

> let _ = print_string "foo"

> let _ = print_string "bar"

>

> at the top level.

Ah. Well, the solution is not use "let _" or ";;", the solution is to avoid sociopathic code like that. Module definition with built-in, unavoidable side effects are evil.

You need at least one module that does something at top-level, otherwise your program won't do anything.

For serious development, yes, but consider the people who are learning OCaml. One of the first programs is going to be some kind of side effecting hello world etc.

im quite amazed that ocaml seems to be on a rise (judging from how often i've recently seen it on here). it reminds me of the time i started to dig into it more than a decade ago when mldonkey [0] was a thing.

also, this is the way to briefly introduce a programmer to a new language. just show the commented syntax. i just hate reading all the prefaces and texts of language manuals. it's good they're there but i'm just loosing interest too quickly if you don't show me code.

[0] https://en.wikipedia.org/wiki/MLDonkey

You might want to give this a look: https://realworldocaml.org/v1/en/html/a-guided-tour.html

There are also more links/resources on the OCaml website.

http://ocaml.org/learn/books.html

It seems `int_of_float` and `float_of_int` are deprecated by the Jane Streets Core library. It even throws errors on utop. I believe they need to be replaced by `Int.of_float` and `Float.of_int` respectively.

EDIT: Some more corrections:

1. `List.hd []` doesn't raise an error as its return type is an option. So the result is a `None`.

2. `List.map` and `List.filter` arguments should be reversed. First argument should be a list and the second should be the mapping function.

The code examples doesn't use Jane Streets Core as the primary standard library. If you do, for example by adding `open Core.Std` to your .ocamlinit, you'll get the behaviour you're describing.

It is probably a good idea to use Core, but for this introduction I wanted as little requirements as possible.

edit: spelling

Right. Since you mention the installation instructions from Real World OCaml and the examples in the book need you to use Core, it is likely that beginners would experience these issues.

That's a good point. I'll add a note to explicitly say that the examples doesn't use Core.

I do really like OCaml, although Rust is the one I'm starting to look to where in the past I'd consider OCaml (yes, two different languages, but similar in practical function approach and safety).

The one things that I absolutely can't stand about OCaml is the lack of an easy, available, include-in-the-standard-library, debugging function. Every damn time I work with OCaml, I end up having to write annoyingly time-consuming "print_blah_blah" functions to handle debugging. And such a debugging feature should handle errors already, and not return the Option type. I shouldn't have to write a function to handle errors on a debugging statement.

And yes, I'm sure there are some nice versions of this already available in 3rd-party libraries, but this should be in the standard library.

How does OCaml compare to F# from a language point of view?

It's easy to get a quick comparison by searching stackoverflow so I won't reitterate those answers, but I would just mention a couple of my favorite things from OCaml that F# doesn't have that those answers tend to leave out:

- Polymorphic variants

- GADTs

- Named arguments (that are still curried if you can believe it!)

- Last time I checked OCaml had better record label scoping. F# doesn't allow two record types in scope that share a record label name. Does anyone know if F# has plans to implement what OCaml has (or have they already?) OCaml used to have the same problem but it was fixed and now dealing with OCaml records has been massively improved as a result.

Also, OCaml has functors.

On the other hand, interop with C# means instantly much larger ecosystem.

I'm mostly only experienced with F#, but it has a few features that OCaml doesn't (type providers, units of measure, computation expressions) and is missing a few that OCaml has (functors). F# has a bit of a cleaner syntax in some ways IMO[0], but that's offset by .NET interop - the standard libraries are pretty much all borrowed from C#, and therefore tend to be more OO-first than functional-first.

Also, because it runs on .NET/Mono, you can do multicore stuff in F# very easily, whereas OCaml's multicore support is very immature (and actually not present at all until the next release, 4.03).

[0] See https://msdn.microsoft.com/en-us/library/dd233199.aspx The "verbose" syntax is almost exactly OCaml, the "Lightweight" syntax is what's commonly used in F#.

I would not actually compare them from language point of view but ecosystem point of view - but then again, I like simplistic stuff. Give me algebraic datatypes, pattern matching and type inference and I'm happy.

That said, F# in my opinion benefits hugely from the Visual Studio tooling (if one can use it). The main benefits for me are:

- the integrated F# command line facilitates pretty much similar development as with lisps - one can instantiate a context, and then develop ones program code at the same time as the context is live. With static types. I.e. create a function, interpret in repl, run function, observe the side-effects etc. Once done compile. Then load dll in repl, build new functionality on top of previous module etc etc.

- Visual Studio intellisense debugs my logic as I type it. Having the IDE proofreading my sources as I type it is a huge productivity win. Of course, if the program logic is built around types, that is - but with F# this is the easiest way to write stuff any way.

- This is a fringe issue but one can write Unity scripts in F# :)

> the integrated F# command line facilitates pretty much similar development as with lisps

OCaml has Utop, and that's a pleasure to work with.

> Visual Studio intellisense debugs my logic as I type it. Having the IDE proofreading my sources as I type it is a huge productivity win. Of course, if the program logic is built around types, that is - but with F# this is the easiest way to write stuff any way.

You can use Merlin to do the same thing in vim or emacs. This doesn't grant you the rest of IDE features, but you still get typechecking, you can check the type of a variable, and you get intelligent renaming (within the same file).

How does concurrency in OCaml compare to Go, Clojure, Rust, etc?

Thanks

Concurrency is not built-in, you can get monadic concurrency from libraries (either lwt or Async). There is no parallelism support yet, but multicore support should be there by the end of the year.

You might be interested in this thread: https://news.ycombinator.com/item?id=9582980