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

121–130 of 157 posts

Re: OCaml: a Rust developer's first impressions

#121

Post by nazka »

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…

What about back when you started to sturdy C++. Will that not have taken you more than an hour to do an performant and elegant C++ solution?

I feel what is critical is to practice it more often and also to do a jump into how we think as a developer because OCaml is a functional language from the ML family. The way we have to design and think is not exactly the same as all the other mainstream languages.

Re: OCaml: a Rust developer's first impressions

#122

Post by MaxBarraclough »

tempodox wrote: post #68
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…

You're not stupid. Functional programming requires its own way of thinking and it's different from procedural languages with mutable-state soup, like C++. It's less that OCaml is hard to learn, and more that you have to leave old habits of thinking and learn new ones. Don't give up just yet.

Right. Same goes for learning any radically unfamiliar style of programming. There are people who say once you've learned one programming language it's easy to learn any other programming language, but this just isn't true. The differences between languages aren't always skin deep.

On the plus side these are the learning curves most worth climbing, as it broadens your understanding. That might be reason enough itself, but it might also make you a better programmer in your usual wheelhouse. Haskell, Forth, and assembly, are worth taking a look at for this reason.

If you want to go further down the exotic language rabbit hole, there's Mercury [0] and Joy, [1] both of which I keep meaning to learn. (Hadn't realised until today that they're both from the University of Melbourne.)

[0] https://en.wikipedia.org/wiki/Mercury_(programming_language)

[1] https://en.wikipedia.org/wiki/Joy_(programming_language)

Re: OCaml: a Rust developer's first impressions

#123

Post by IshKebab »

ReleaseCandidat wrote: post #94
IshKebab wrote: post #91

The biggest issue for me with OCaml is OPAM. It's pretty awful. Simple things like "install this code" don't work reliably - often installing a different branch or just ignoring edits you've made, even after you discover the flag that says it should include them (it seems to be simply broken). It also doesn't work on Windows in any meaningful way. It's not just me that has these issues. We introduced a tool into my c…

The biggest problém with Opam and OCaml on Windows is that most of the packages won't work. Officially, Opam does not support Windows at all, that is going to be included with 2.2 (which is still in alpha AFAIK) https://opam.ocaml.org/blog/opam-2-2-0-alpha/#Windows-Suppor... I always thought of Opam as the best feature of OCaml (especially compared to Haskell with two no-working package managers - and no, Nix is a pr…

Yeah in fairness at least it has one package manager and it does seem well designed even if it doesn't actually work properly half the time. So it is fixable!

Which is more than you can say for Python and C++.

Re: OCaml: a Rust developer's first impressions

#124

Post by dvektor »

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,…

Author here: Totally hear you there, the post was literally just like it says 'first impressions'. Will most definitely be posting a few updates as I progress farther and try to make some comparisons :)

Re: OCaml: a Rust developer's first impressions

#125

Post by IshKebab »

ReleaseCandidat wrote: post #96
IshKebab wrote: post #90

Earlier quoted context omitted.

Right but in practice most OCaml code does not have explicit types. Using an editor that shows type inlays (e.g. VSCode) helps a lot but not fully because a lot of types are inferred as generics. You're also correct that you don't have to use lists, but again most OCaml code does .

> Using an editor that shows type inlays (e.g. VSCode) helps a lot but not fully because a lot of types are inferred as generics. That is because they are generic most of the time. This is also fun when using `#trace`in the REPL and all you see is ` ` instead of the "real" value

Right but being overly generic makes them hard to understand. Generics are kind of like "compile time dynamic types" and they have many of the downsides of runtime dynamic types:

* intent of the author not clear

* auto-complete etc. doesn't work as well

* type errors not caught as early (for generics this means you get super confusing type errors)

Obviously some functions are intended to be generic (e.g. operations on containers) but typical OCaml code seems to contain functions that are actually only called with one type - and the author only intended for them to be called with one type - yet they get inferred as generic.

Re: OCaml: a Rust developer's first impressions

#126

Post by yodsanklai »

ReleaseCandidat wrote: post #116
yodsanklai wrote: post #112

Earlier quoted context omitted.

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

How do you do encapsulation without an mli? can you hide the type implementation to the module user? can you ensure the exported functions (which are all of them without an mli) maintain your type invariant?

> the real problém is that the documentation is often worse too, as the .mli is autogenerated and documented afterwards

Of course, that would defeat the purpose of having interfaces and is incredibly bad practice. People do that when they try to fix an already broken codebase. It's actually pretty ironic that people who care about type safety (which I is why they use OCaml in the first place) don't value (or understand) things like encapsulation.

Re: OCaml: a Rust developer's first impressions

#127

Post by [deleted] »

staunton wrote: post #117
yodsanklai wrote: post #101

Earlier quoted context omitted.

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 .

[deleted]

Re: OCaml: a Rust developer's first impressions

#128

Post by dvektor »

ReleaseCandidat wrote: post #75

>... linked lists are slow and inefficient with modern CPU caches, and you should almost never use them You should not use them most of the time in functional languages (like OCaml and Haskell and...) for this reasons either, it's just that (almost) all examples for beginners use them because they are "easier" than for example trees. Oh, by the way, OCaml does not have significant whitespace (but e.g.F# and Haskell d…

Notice the ! in "!significant whitespace"

I thought I was being slick

Re: OCaml: a Rust developer's first impressions

#129

Post by ReleaseCandidat »

yodsanklai wrote: post #126
ReleaseCandidat wrote: post #116

Earlier quoted context omitted.

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

How do you do encapsulation without an mli? can you hide the type implementation to the module user? can you ensure the exported functions (which are all of them without an mli) maintain your type invariant? > the real problém is that the documentation is often worse too, as the .mli is autogenerated and documented afterwards Of course, that would defeat the purpose of having interfaces and is incredibly bad practice…

> How do you do encapsulation without an mli?

In OCaml you can't. If I could I wouldn't care about interface files, because I wouldn't need them.

Re: OCaml: a Rust developer's first impressions

#130

Post by ReleaseCandidat »

IshKebab wrote: post #125
ReleaseCandidat wrote: post #96

Earlier quoted context omitted.

> Using an editor that shows type inlays (e.g. VSCode) helps a lot but not fully because a lot of types are inferred as generics. That is because they are generic most of the time. This is also fun when using `#trace`in the REPL and all you see is ` ` instead of the "real" value

Right but being overly generic makes them hard to understand. Generics are kind of like "compile time dynamic types" and they have many of the downsides of runtime dynamic types: * intent of the author not clear * auto-complete etc. doesn't work as well * type errors not caught as early (for generics this means you get super confusing type errors) Obviously some functions are intended to be generic (e.g. operations o…

> Right but being overly generic makes them hard to understand.

Oh yes, I'm not arguing against that or your other points. I just wanted to express that the types being inferred as generic is not an error, but by design.

Post reply on HN