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.
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.
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.
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"
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.
let msg = "hi" in
print_string msg;
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.
let _ = print_string "foo"
let _ = print_string "bar"
Of course you can write
let msg = "foo" in print_string msg
let msg = "bar" in print_string msg
But you can't write
print_string "foo"
print_string "bar"
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.
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.
It is probably a good idea to use Core, but for this introduction I wanted as little requirements as possible.
edit: spelling
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.
- 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.
On the other hand, interop with C# means instantly much larger ecosystem.
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#.
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# :)
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).
Thanks