Live data from Hacker News

A brief introduction to OCaml

lexicallyscoped.com

11–20 of 39 posts

Re: A brief introduction to OCaml

#11

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. P…

> 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.

Re: A brief introduction to OCaml

#12

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. P…

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

Re: A brief introduction to OCaml

#15

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 ;; as me…

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.

Re: A brief introduction to OCaml

#16

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

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#.

Re: A brief introduction to OCaml

#17
post #15

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 ;; as me…

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.

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.

Re: A brief introduction to OCaml

#18
post #16

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

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…

[deleted]

Re: A brief introduction to OCaml

#19

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.

Re: A brief introduction to OCaml

#20

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. P…

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.
Post reply on HN