OCaml: a Rust developer's first impressions • Hacker News Board

Re: OCaml: a Rust developer's first impressions

#111

Post by hurril » Sun, Nov 12, 2023, 10:42 AM UTC

fweimer wrote: post #100

hurril wrote: post #77

Earlier quoted context omitted.

Safe isn't the best word to describe it with. But it does mean that any expression or statement always has two possible control flows. You have the "surface flow" as well as the exceptional flow, so there's an added complexity. I never felt this was a problem when I did Java though (despite their awkwardness - basically forcing coders to not use checked exceptions.) Rust's control flow syntax for Results and Options…

I don't think panics are comparable to Java's VM errors. A lot of libraries (not just the standard library) seem to target panic-safety, avoiding unsafe behavior and resource leaks in case of panics. This means that the panic itself is not supposed to transition the process into an undefined state, like it happens with many VM errors in Java (where a stack overflow may mean that required cleanup action has not execut…

I'm relatively new to Rust. I use panic (and cousins) in fn main only. As in: I'll expect(), unwrap() or similarly handle missing bootstrapping circumstances. Outside of main, I'll never ever use any of them. Even when I "know" that a condition is Impossible(tm).

Re: OCaml: a Rust developer's first impressions

#112

Post by yodsanklai » Sun, Nov 12, 2023, 10:44 AM UTC

ReleaseCandidat wrote: post #109

yodsanklai wrote: post #97

Earlier quoted context omitted.

> Right but in practice most OCaml code does not have explicit types. Most OCaml code use .mli which does have types. This is the recommended practice but I noticed a lot of beginners coming from other languages are reluctant to use them (because of duplication). It's a simple idea but I think it's a strong point of OCaml and it makes easier to program "in the large" than Haskell for instance.

But .mli files do not help with the "no types in the source code" problém. You need LSP (Merlin) to "see" the types anyway. Only adding the signature in the samé (.ml) file helps against that problém. And I did not experience any advantage of separate signature files so far, but I also haven't written anything large in OCaml (>100 kLOC).

> But .mli files do not help with the "no types in the source code" problém

It partially helps since it forces you to have types where they matters most: exported functions

> And I did not experience any advantage of separate signature files so far,

100kLoc is already quite big! I'm starting to think I'm an outlier since a lot of people don't see the benefits :)

For me, it helps because I really don't want to see the implementation when I use an API. If I need to look at the implementation, it means the interface isn't well specified. All I need should be in the interface: types, docs, (abstract) types. And no more.

Typically, an .ml file will have more than what is exported, types won't be abstract but will have a concrete implementation, and type signatures may be missing. How would it feels like to use list if only https://github.com/ocaml/ocaml/blob/trunk/stdlib/list.ml was available, instead of https://github.com/ocaml/ocaml/blob/trunk/stdlib/list.mli? and that's not the most compelling example since it's a simple module where the main type isn't abstract. Generally speaking, giving up mli means giving up on encapsulation which is one of the primary tools to deal with large programs.

Haskell forces you to say what is exported from a module, but the module user can only see the names. To see the signatures, you need to rely on generated doc or look it up on the code.

Arguably, since OCaml has includes, it suffers from the same problem, your ".mli" may have tons of include and it becomes harder to see what's exported without an external tool

Re: OCaml: a Rust developer's first impressions

#113

Post by yodsanklai » Sun, Nov 12, 2023, 11:02 AM UTC

grumpyprole wrote: post #106

lapinot wrote: post #102

Earlier quoted context omitted.

> In fact, the standard library encourages Seq instead over List. Uhu? Never heard about Seq before! Seems to have been introduced in 4.07 which was released 5 years ago, which is basically yesterday in terms of stdlib api. Set and Map, sure, but Seq? Lists are ubiquitous and they are indeed a central data structure in ocaml code. For anybody also wondering, Seq is a datatype for iterators (ie thunked lists).

The Seq module has more functions than the List module. There are also more of_seq functions than of_list throughout. 5 years ago the compiler standard library was not a serious proposition, it is becoming more so now.

> the compiler standard library was not a serious proposition, it is becoming more so now.

This is actually one of my grief with OCaml. I wish I didn't have to use Core. I don't look much at the std library anymore.

My other grief is async (Lwt or Async). It forces to use monads which don't look very pretty in OCaml. That being said, I haven't looked at what OCaml 5.0 bring to the table on that front. This was my experience 5 years ago basically...

Re: OCaml: a Rust developer's first impressions

#114

Post by sadiq » Sun, Nov 12, 2023, 11:03 AM UTC

lapinot wrote: post #102

grumpyprole wrote: post #85

> Where are the types? OCaml supports type annotations practically anywhere, if you want to add them. Alternatively, you can use an editor that supports querying or showing types for bindings. VSCode and Emacs support this. > Remember recursion? How about linked lists? A lot of beginner material uses List to introduce algebraic data types, inductive and equational reasoning - but you don't have to use them. In fact,…

> In fact, the standard library encourages Seq instead over List. Uhu? Never heard about Seq before! Seems to have been introduced in 4.07 which was released 5 years ago, which is basically yesterday in terms of stdlib api. Set and Map, sure, but Seq? Lists are ubiquitous and they are indeed a central data structure in ocaml code. For anybody also wondering, Seq is a datatype for iterators (ie thunked lists).

There will also be DynArrays in the stdlib from 5.2: https://github.com/ocaml/ocaml/pull/11882

Re: OCaml: a Rust developer's first impressions

#115

Post by sadiq » Sun, Nov 12, 2023, 11:05 AM UTC

yodsanklai wrote: post #113

grumpyprole wrote: post #106

Earlier quoted context omitted.

The Seq module has more functions than the List module. There are also more of_seq functions than of_list throughout. 5 years ago the compiler standard library was not a serious proposition, it is becoming more so now.

> the compiler standard library was not a serious proposition, it is becoming more so now. This is actually one of my grief with OCaml. I wish I didn't have to use Core. I don't look much at the std library anymore. My other grief is async (Lwt or Async). It forces to use monads which don't look very pretty in OCaml. That being said, I haven't looked at what OCaml 5.0 bring to the table on that front. This was my exp…

For 5.0+ you might want to look at https://github.com/ocaml-multicore/eio for how effects can make async much more pleasant

Re: OCaml: a Rust developer's first impressions

#116

Post by ReleaseCandidat » Sun, Nov 12, 2023, 11:05 AM UTC

yodsanklai wrote: post #112

ReleaseCandidat wrote: post #109

Earlier quoted context omitted.

But .mli files do not help with the "no types in the source code" problém. You need LSP (Merlin) to "see" the types anyway. Only adding the signature in the samé (.ml) file helps against that problém. And I did not experience any advantage of separate signature files so far, but I also haven't written anything large in OCaml (>100 kLOC).

> But .mli files do not help with the "no types in the source code" problém It partially helps since it forces you to have types where they matters most: exported functions > And I did not experience any advantage of separate signature files so far, 100kLoc is already quite big! I'm starting to think I'm an outlier since a lot of people don't see the benefits :) For me, it helps because I really don't want to see the…

> It partially helps since it forces you to have types where they matters most: exported functions

But the problém the OP has is not knowing the types when reading the source (in the .ml file).

> How would it feels like to use list if only https://github.com/ocaml/ocaml/blob/trunk/stdlib/list.ml was available,

If the signature where in the source file (which you can do in OCaml too), there would be no problem - which is what all the other (for some definition of "other") languages except C and C++ (even Fortran) do.

No, really, I can't see a single advantage of separate .mli files at all. The real problém is that the documentation is often worse too, as the .mli is autogenerated and documented afterwards - and now changes made later in the sources need to be documented in the mli too, so anything that doesn't change the type often gets lost. The same happens in C and C++ with header files.

Re: OCaml: a Rust developer's first impressions

#117

Post by staunton » Sun, Nov 12, 2023, 11:05 AM UTC

yodsanklai wrote: post #101

sintheta wrote: post #65

Can't comment on the comparison to Rust, but I recently spent quite some time learning OCaml, working through the excellent and freely available cs3110 course https://cs3110.github.io/textbook/cover.html ; I really really wanted to like the language... I agree w/ the submitted article about the heavy reliance on linked lists and recursion, but what disillusioned me from it is that after many weeks of study I discover…

Not all languages are equaly suitable to all tasks. If your leetcode easy problem is to write a quick sort, you wouldn't use linked list + recursion. That being said, the OCaml idiomatic solution is to declare a mutable array and write your for-loop, just like you would do in C++. > given everything's immutability OCaml has a lot of mutable datastructures. It's perfectly fine to use them. Even though with experience,…

CppCon is a very niche audience in my experience. Most "C++ programmers" use a subset of C++11 with some UB sprinkled here and there. When you care about productivity I'm starting to suspect that's actually fine.

Re: OCaml: a Rust developer's first impressions

#118

Post by u320 » Sun, Nov 12, 2023, 11:10 AM UTC

tomca32 wrote: post #55

cmrdporcupine wrote: post #28

Earlier quoted context omitted.

The ? thing, didn't that get borrow from Swift, in fact?

Creator of the Rust language Graydon Hoare is working on Swift, so it’s probably the other way around

He left Rust long before ? was introduced.

Re: OCaml: a Rust developer's first impressions

#119

Post by zozbot234 » Sun, Nov 12, 2023, 11:26 AM UTC

bobbylarrybobby wrote: post #41

chmod600 wrote: post #35

Earlier quoted context omitted.

Can you explain "proper closures"?

I would hazard that this means closures that can capture (shared) state. In Rust, a closure’s data must either be moved into the closure or outlive the closure (dangling pointers etc etc). In most other languages, GC allows closures to keep a handle to any data at all.

If you want a closure to outlive the outside bindings of its captures and thus have shared control over their lifecycle (which is the default behavior of closures in most FP languages) you can easily use Rc or Arc to that effect. Rust just forces you to be explicit about it.

Re: OCaml: a Rust developer's first impressions

#120

Post by ernst_klim » Sun, Nov 12, 2023, 11:29 AM UTC

sintheta wrote: post #65

Can't comment on the comparison to Rust, but I recently spent quite some time learning OCaml, working through the excellent and freely available cs3110 course https://cs3110.github.io/textbook/cover.html ; I really really wanted to like the language... I agree w/ the submitted article about the heavy reliance on linked lists and recursion, but what disillusioned me from it is that after many weeks of study I discover…

> A straight forward, easy to read, performant C++ solution took me 10 minutes; an ugly unidiomatic OCaml version took me 30 minutes; and a beautiful idiomatic OCaml version using recursion that still no non-OCaml programmer could ever read took me something like an hour...

Replace C++ with English and OCaml with Japanese or Estonian and you'll get the idea.

OCaml is a vastly different language from what C++ is. Switching to OCaml from C++ is not at all like switching to Go or Java. If you switched to OCaml from SML or Haskell, you would write a completely different opinion.

Paradigm shift takes huge mental effort, that's something you have to deal with, unless you want to confine yourself into the comfy world of familiar languages.