Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OCaml: a Rust developer's first impressions

pthorpe92.github.io

Post reply on HN
Print view View original

1–10 of 157 posts

Re: OCaml: a Rust developer's first impressions

#2

Post by satvikpendem »

OCaml is great, we learned it in class back in college, then we learned Rust right afterwards. Oftentimes people say OCaml is Rust without the borrow checker (or that Rust is OCaml with a borrow checker), but that's not quite true. Since it is entirely functional and recursive, it takes more time to wrap your head around. Now with OCaml 5, we also have algebraic effect support, something that Rust is looking to add in as well, in a more moderate capacity.

Also, if you don't like the OCaml syntax, check out ReasonML, which is an alternative OCaml syntax that Facebook developed several years ago. It has the Algol-style that many modern languages today use.

Re: OCaml: a Rust developer's first impressions

#4

Post by debo_ »

satvikpendem wrote: post #2

OCaml is great, we learned it in class back in college, then we learned Rust right afterwards. Oftentimes people say OCaml is Rust without the borrow checker (or that Rust is OCaml with a borrow checker), but that's not quite true. Since it is entirely functional and recursive, it takes more time to wrap your head around. Now with OCaml 5, we also have algebraic effect support, something that Rust is looking to add i…

I think about it the other way; Rust is an ML with a borrow checker. Most of the stuff I hear people gushing about in Rust is IMO them experiencing what's it's like to write ML.

Re: OCaml: a Rust developer's first impressions

#5

Post by satvikpendem »

debo_ wrote: post #4
satvikpendem wrote: post #2

OCaml is great, we learned it in class back in college, then we learned Rust right afterwards. Oftentimes people say OCaml is Rust without the borrow checker (or that Rust is OCaml with a borrow checker), but that's not quite true. Since it is entirely functional and recursive, it takes more time to wrap your head around. Now with OCaml 5, we also have algebraic effect support, something that Rust is looking to add i…

I think about it the other way; Rust is an ML with a borrow checker. Most of the stuff I hear people gushing about in Rust is IMO them experiencing what's it's like to write ML.

Yes and no, Rust is ML inspired but it is still way too imperative and not as functional to be called a true ML. But yes, things like Result and Option types, do-notion via "?," at least for Results and Options, algebraic data types are all part of the appeal. There sadly are still no higher kinded types though, but that is a difficult problem to solve and most won't encounter such problems anyway in day-to-day coding, so the contributors made generic associated types instead as an alternative.

Re: OCaml: a Rust developer's first impressions

#6

Post by greydius »

satvikpendem wrote: post #5
debo_ wrote: post #4

Earlier quoted context omitted.

I think about it the other way; Rust is an ML with a borrow checker. Most of the stuff I hear people gushing about in Rust is IMO them experiencing what's it's like to write ML.

Yes and no, Rust is ML inspired but it is still way too imperative and not as functional to be called a true ML. But yes, things like Result and Option types, do-notion via "?," at least for Results and Options, algebraic data types are all part of the appeal. There sadly are still no higher kinded types though, but that is a difficult problem to solve and most won't encounter such problems anyway in day-to-day codin…

> still way too imperative and not as functional to be called a true ML

As a Haskell fanboy, this is how I feel about Ocaml and F#.

Re: OCaml: a Rust developer's first impressions

#7

Post by satvikpendem »

greydius wrote: post #6
satvikpendem wrote: post #5

Earlier quoted context omitted.

Yes and no, Rust is ML inspired but it is still way too imperative and not as functional to be called a true ML. But yes, things like Result and Option types, do-notion via "?," at least for Results and Options, algebraic data types are all part of the appeal. There sadly are still no higher kinded types though, but that is a difficult problem to solve and most won't encounter such problems anyway in day-to-day codin…

> still way too imperative and not as functional to be called a true ML As a Haskell fanboy, this is how I feel about Ocaml and F#.

What are your thoughts on Idris and other Haskell derivatives? As well as the HVM and its Lisp-like Haskell-like combo of a language [0]?

[0] https://github.com/HigherOrderCO/hvm

Re: OCaml: a Rust developer's first impressions

#8

Post by satvikpendem »

hardwaregeek wrote: post #3

Yeah my semi-hot take is that type annotations in functions is a feature not a bug. It forces legible interfaces (with the exception of nasty generics I suppose).

I think that is not a hot take at all, haha. For some reason, in TypeScript people like to have return types inferred, and while I do that just because I'm lazy in my own projects, we enforce explicit return types in our work codebases simply because you never know when something might change in the function body.

Re: OCaml: a Rust developer's first impressions

#9

Post by kragen »

i had some of the same problems; here's how i solved them, though keep in mind i am no ocaml expert, just a dabbler

at some point i got sick of trying to debug mysterious compile errors about types in ocaml and started declaring types for all of my function arguments; ocaml lets you do that. an example is http://canonical.org/~kragen/sw/dev3/mukanren.ml (an implementation of a tiny logic programming language, sort of like prolog with superpowers; cw inappropriate intimacy) where, for example, instead of writing

    let rec disj g1 g2 t = mplus (g1 t) (g2 t)
i write

    let rec
        disj (g1 : goal) (g2 : goal) (t : state) = mplus (g1 t) (g2 t)
which is more code, to be sure, but i think easier to understand because it's more explicit. and the compiler doesn't report your type errors in the wrong function anymore when you do that

if you aren't sure what the types should be (easy when parametric polymorphism gets involved) you can paste the code without type declarations into the repl and see what it says

in this case that looks like this

    # let rec disj g1 g2 t = mplus (g1 t) (g2 t) ;;
      val disj : ('a -> 'b stream) -> ('a -> 'b stream) -> 'a -> 'b stream =
and in fact my `goal` type is more specific, `state -> state stream`, thus favoring comprehensibility a bit over flexibility (i can always go back and generalize the type more later)

this makes the code a bit more verbose but most functions are more than five words long so it's not actually that bad

maybe i should declare the return type too

    let rec
        disj (g1 : goal) (g2 : goal) (t : state) : state stream = mplus (g1 t) (g2 t)
but so far parameter declarations seem like about the right balance

declaring parameter types in your own code doesn't help with code you didn't write, but you can use the repl to find out what types the compiler inferred for it

    # List.map ;;
    - : ('a -> 'b) -> 'a list -> 'b list =
presumably editors with lsp support have some magic keystroke to display this on demand in your editor or something, maybe an lsp user can tell us what it is

Re: OCaml: a Rust developer's first impressions

#10

Post by frodowtf »

satvikpendem wrote: post #2

OCaml is great, we learned it in class back in college, then we learned Rust right afterwards. Oftentimes people say OCaml is Rust without the borrow checker (or that Rust is OCaml with a borrow checker), but that's not quite true. Since it is entirely functional and recursive, it takes more time to wrap your head around. Now with OCaml 5, we also have algebraic effect support, something that Rust is looking to add i…

People say that OCaml is like Rust, but unlike Rust, OCaml has Exceptions that could appear everywhere. How is that safe?
Post reply on HN