OCaml: a Rust developer's first impressions

https://pthorpe92.github.io/ocaml/ocaml-first-thoughts/

by qsantos • 3 years ago

173 152 3 years ago

pthorpe92.github.io

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.

debo_6• 3 years ago

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.

satvikpendem6• 3 years ago

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.

preommr• 3 years ago

Almost like people want some functional features without all the extra baggage.

I guess I would even say it's like... most people just want the banana, but got a gorilla holding the banana and the rest of the jungle as well.

whateveracct2• 3 years ago

ML with a borrow checker is a bit of an oxymoron though. Because proper closures (the kind Rust can't do) are essential for the classic functional programming that ML represents.

frodowtf2• 3 years ago

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

bananapub• 3 years ago

why do feel exceptions make a language unsafe?

bmitc6• 3 years ago

F# has exceptions. You can just pattern match on them.

cmrdporcupine7• 3 years ago

Safety was something added to Rust as it developed, not one of the original goals. As I recall it.

And you're working with multiple definitions of "safety" here, and Rust sorta conflates them all via borrow checker, but the one people are usually most concerned with is memory safety which is not a concern for a garbage collected language.

I do seem to recall that StandardML did not have exceptions though. And I always felt that SML was the better language.

OCaml adding OO classes and exceptions and other 90s trends that actually have ended up not aging well...

Georgelemental• 3 years ago

Rust has panics that could appear anywhere.

nextaccountic5• 3 years ago

Rust has panics as well and they appear pretty much everywhere, because the Rust stdlb made a conscious decision to panic on allocation failures (later non-panicking APIs were added, but most people dont use them, and in special, most dependencies will not use this and will panic on random occasions), and also because common operations like integer division and array indexing will panic on bugs (and also integer overflow on debug builds)

In any case OCaml has memory safety, sort of (it has data races but as described in the paper "data races bounded in time and space", data races in OCaml doesn't lead to unrestricted UB like in Rust, C, C++, and most other languages actually) (unless you opt into OCaml's unsafe constructs like Obj.magic, which is like Rust's unsafe without using unsafe {} block), because it has a GC

So when you talk about safety in the context of exceptions, you probably mean exception safety rather than memory safety. Exception safety basically means you code works even if an exception is raised. Which is really hard to assure since as you said, exceptions are everywhere

But Rust suffer from this same problem! In Rust this is called panic safety and mitigating it has taken a great deal of complexity, with things like lock poisoning, which adds overhead but limit the scope of panics in multithreaded programs, and the UnwindSafe trait, which is probably a good attempt but is ignored in most of the ecosystem. Many people think such measures are inadequate and insufficient and prefer to run programs with panic=abort, which means to just terminate the program when there is any panic. (many C++ projects disable exceptions in the same way for example)

Which is kind of unfortunate because now there are many Rust programs that are only correct if you run with panic=abort, and will break if you enable stack unwinding (which is the default)

ReleaseCandidat14• 3 years ago

I don't like Exceptions in OCaml (or Haskell or C++ or JS/TS) either. But they aren't unsafe, except for bugs in the compiler/runtime (in OCaml, in C++ there are of course some footguns ;). Of course they add "bottom" to any function where an Exceptions can occur (and other things, see for example https://markkarpov.com/tutorial/Exceptions) but for stuff like `0/0` there are 3 possibilities:

use something like `Maybe` for the result - clumsy.

return (for example) 0, which is what most theorem provers (like Coq or Lean and dependently typed languages like Idris) do, that need their functions to be total

or throw an exception.

(C's solution of declari g it undefined behavior is missing).

Now, with OCaml's effect systém, there also is no need to use exceptions for control flow - which you should have never done anyway.

cmrdporcupine7• 3 years ago

I kinda just think of Rust as C++ with a vaguely MLish inspired syntax & some aspects of the type & module system -- which is sort of how it explicitly started TBH -- and the borrow checker just grew out of what you end up needing to do if you rip the garbage collector out of a language like that.

trealira2• 3 years ago

Rust was originally garbage collected. From Graydon Hoare's post, he didn't want explicit lifetimes originally either. He agreed because he thought they would always be inferred by the compiler.

https://graydon2.dreamwidth.org/307291.html

It seems to me that Rust evolved into a better C++, but it did not start out that way.

unstruktured• 3 years ago

I like both OCaml and Rust, especially OCaml, but even after 2 years of Rust I'm still way more productive in OCaml. Unless it's absolutely essentially, I really don't want to have track the life times of my objects so explicitly.

Thus, Rust for me serves mostly as a C/C++ alternative. I don't plan to ever write anything in C again, and even if it's not my goto language otherwise, for that I'm thankful.

satvikpendem6• 3 years ago

I just clone and don't worry about it, works well.

LAC-Tech• 3 years ago

Always felt zig was a lot closer to ocaml than rust was.

hardwaregeek3• 3 years ago

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

satvikpendem6• 3 years ago

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.

bmitc6• 3 years ago

But they can just be auto-generated in documentation. It gets pretty annoying to type annotate everything for nothing but warm fuzzies when the compiler can figure it all out for you.

Also, any decent IDE will show the types any way.

The complaint about the types is just strange and shows a failure in getting Rust out of their head. Once you get used to F# and OCaml, then going back to a language that forces type annotations everywhere gets old and seems archaic because you spend all this time telling the compiler what it already knows (in a language like F# and OCaml). However, there are times in which type annotations are needed, especially in F# when dealing with objects. I generally type annotate when I feel the name of the argument doesn't capture the type.

Writing F# often feels very Pythonic or Scheme-y, but at the end of the day, everything is being statically typechecked, so it's the best of both worlds.

dan-robertson3• 3 years ago

In OCaml most people are writing signatures to which their modules conform (usually in separate mli files). The problem is that checking the signature happens after all the type inference so you can’t use it to disambiguate constructors for function arguments/results, and they can’t be used much to guide users who make type errors in their functions. I think it was a good idea that rust put the types in arguments to non-anonymous function.

stouset• 3 years ago

It gets pretty annoying to type annotate everything for nothing but warm fuzzies when the compiler can figure it all out for you.

This is sometimes fine for internal code, but for external interfaces you want a human to determine the interface contract you’re agreeing to, rather than the minimal set or the maximal set of types the function supports as currently-written.

koito17• 3 years ago

The complaint about the types is just strange and shows a failure in getting Rust out of their head.

I second this a lot. It's very strange to me that the author is complaining about powerful type inference. In my limited experience with ReScript, I've found the type inference to drastically reduce boilerplate while providing the same type safety guarantees as TypeScript. Moreover, your editor or IDE can always tell you what the inferred type is. I am really not sure what I am missing. The author headlines the paragraph with "Where are the types? [sic]" but the types are there! They're inferred and visible in your IDE!

The provided code snippet doesn't really help illustrate the point either, IMO. It will look unfamiliar to those who've never used OCaml before, and to those who have done more than a fizzbuzz in OCaml, it will look okay.

hardwaregeek3• 3 years ago

Well there's also the fact that the types flow downward from the interface. Like the source of truth comes from your function parameter types that are always explicitly written. One thing that tripped me up writing OCaml is that you could have a mistake in your function that'd show up as a bug in a completely different location due to the inference algorithm. Like dumb example but say I have `foo` instead of `foo()` that changes the function return type to be a () -> int instead of int. You'll get the error when you use the function result instead of inside the function.

pjmlp3• 3 years ago

Unfortunately in the 21st century still too many people like to program the hard way without tools that improve their workflows.

Maybe they should do batch compilations as well, why bother with interactive programming.

IlliOnato• 3 years ago

because you spend all this time telling the compiler what it already knows

But a program should be optimized not for reading by a compiler but for reading by a human. This is essential for maintainability.

The question is not how hard it is for a compiler to deduce types, but how hard it is for a human (and a human that hasn't necessary written this ode, and hasn't necessary read and remembered the whole codebase) to figure it out.

It is not a simple question in general. Too much "infrastructure" clutter can hide the logic and intent of the code too. So to get the right balance in a language or in the code is non-trivial.

Shoop• 3 years ago

OCaml has a separate language for module interfaces where types are required. Even better, it allows you to abstract over types and make them entirely opaque, so that users of an interface never have to look at any of the implementation details.

munchler2• 3 years ago

As you get more comfortable with functional programming, the type signatures tend to get more complex for sophisticated code. Those "nasty generics" become reliable friends.

For example, since functions are first-class objects, they are often passed around as parameters to other "higher-order" functions. Explicitly declaring the types of all these functions is tedious at best, and confusing at worst.

hardwaregeek3• 3 years ago

I'm not convinced that these type signatures have to be that bad. You could probably make them pretty tenable, especially with a good code formatter.

Also, I'm confused. We're using type driven development and writing the type signatures as part of the documentation, we should be thinking in terms of types, why would they be difficult to write?

kragen2• 3 years ago

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 = <fun>

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 = <fun>

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

dazed_confused• 3 years ago

There is a vscode extension for the ocaml-lsp that will show type annotations above each line of code.

kragen2• 3 years ago

so, no keystrokes, but you can only fit half as much code on your screen?

sintheta• 3 years ago

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 discovered competitive programming and on a whim started doing some easy problems.

Since I was spending most of my time w/ OCaml at that point I thought it could also be a way to practice it further. So for a particularly easy problem it would go something like this: 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...

It really dawned on me that after weeks of studying OCaml I barely knew how to write anything particularly useful in it from scratch. Dealing with user input/output still seemed cumbersome, given everything's immutability... from an intellectual perspective it feels interesting, and I had fun with it, but for now I decided I couldn't see myself becoming productive enough in it to justify further sinking time into it. There's so much to still learn for me (doing a network related project at the moment learning a ton about networking, sockets, etc), that trying to become an unproductive OCaml programmer probably shouldn't be high up my list of priorities... and that is not to say people aren't productive in it, that's to say that I don't see myself becoming productive in it any time soon, compared to being productive in C++ while being far away from being any expert in it.

Maybe I'm too stupid for it, am not suited for it, need a few years of further programming to appreciate some things about it... but for now, sadly, I feel like I've wasted significant time I should have better spent on studying other topics and actually working on projects. And addendum: Never comment on downvotes, I know, but how I immediately got one for this comment... surprising.

tempodox• 3 years ago

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.

MaxBarraclough• 3 years ago

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)

misja1112• 3 years ago

OCaml is not a very good fit for competitive programming, you're better off with a language like Python there.

Writing code in a functional language like OCaml requires a mind switch. This can take quite a while. It took me years to really 'get it' after having programmed for 30 years in imperative languages. Now I prefer writing code in FP for a lot of things, but not for everything. E.g. for coding some algorithms you have a much easier time when you can use mutable arrays.

A nice advantage of OCaml is, IMO, that it is not so strict about pure FP. E.g. unlike in Haskell, arrays are mutable by default.

tromp• 3 years ago

While Haskell's Array type indeed immutable, there is an incremental update function

    (//)            :: (Ix a) => Array a b -> [(a,b)] -> Array a b

that gives you a new updated array. As long as you no longer refer to the old instance, this is as efficient as a mutable array.

But Haskell also offers the mutable STArray and STUArray, for boxed and unboxed types [1]. These preserve their purity by being monadic.

[1] https://hackage.haskell.org/package/array-0.5.6.0/docs/Data-...

hurril4• 3 years ago

After a few weeks, I am disappointed in not being an expert at $new_thing. $new_thing bad!

hurril4• 3 years ago

Downvote it all you want. I've spent the last decade writing in this style and to me it's second nature. Starting Rust I've had to basically relearn solving problems with loops and iterators. Solving problems with loops is not the way I think.

Never once thought negatively of Rust for this.

serial_dev• 3 years ago

After a few weeks (and I believe it was written many weeks, so to me, that sounds like a couple of months), it's not unreasonable for experienced programmer with already a couple of languages in their toolbelt to expect to get _some_ things done in a new programming language.

ReleaseCandidat14• 3 years ago

Dealing with user input/output still seemed cumbersome, given everything's immutability...

This sentence baffled mé, why would immutability be a problém with user input or output?

But changing the way how you solve problems takes time.

yodsanklai5• 3 years ago

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, you realize there's often a a better/safer way to do it.

Also, I'm surprised that in 2023, functional programming still sounds like a mystery to some people. Python/Rust/C++ all have closures, immutable datastructures, their versions of the usual functional combinators, some form of variant types / pattern-matching (maybe not python?). C++23 even has monads. CppCon is full of talks of people realizing that they can write simpler code using this things. I believe all this FP tools should be in the bag of any proficient programmer.

staunton• 3 years ago

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.

aeonik• 3 years ago

I'm not surprised people still don't know functional programming at all. It is really such a different way of programming, and if you don't try to write an entire project using the style, it's just too easy to fall back into mutable code, depriving your self of the greater benefits.

Most of the code I used to write was just gluing libraries together, even heavily Object Oriented stuff was too complicated and becomes a spider web of dependencies, so I always hunted for better libraries, rather than try to extend existing ones.

Now, I've been writing Clojure for about 3 or 4 years, and I still struggle with certain functional and immutable algorithms. But, now when I go back to Python I occasionally get bit very hard from the surprising mutability. So my brain is definitely adjusting to the safety.

I'm still not fluent with a lot of higher order functional concepts. Though I think I'm finally understanding Monads and Transducers.

It's hard to break 10+ years of imperative habit. What really helped me was diving down into the core of how parsers and code evaluation works. I didn't read SICP, but understanding the plumbing of these languages can help ease the transition, at least for me...

Regardless, it's a lot of dedicated work that a lot of people don't want to invest.

bmitc6• 3 years ago

Not all languages are equaly suitable to all tasks.

That is true. Although, I would make the argument that F# and OCaml are two of the best most general purpose languages available. They support the imperative, OOP, and functional paradigms effectively equally. About the only thing you wouldn't use them for is embedded real-time programming. Other than that, they're statically typed with great type inference and sane scoping and syntax (I find F# to be the "cleaner" language) and are performant.

ernst_klim• 3 years ago

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.

nazka• 3 years ago

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.

iopq3• 3 years ago

Horizontal scrolling code does make it quite impossible for me to follow the examples

oconnor663• 3 years ago

heavy use of chained iterator methods in favor over traditional loops. This is one of the more intimidating hurdles for newcomers to [Rust], but after getting used to it, rarely will you see anyone write a for loop again.

I think this varies a lot from person to person. Rust includes syntactic sugar for imperative code (like `if let` and `let else`), and personally I prefer to use that when it's not too much trouble. I find it's pretty rare that I reach for map/and_then/etc.

ReleaseCandidat14• 3 years ago

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

Jaxan• 3 years ago

In Haskell you typically don’t allocate any memory when using the default list type, because of laziness. The it’s totally fine and efficient. Just don’t use it to store data for later retrieval.

momentoftop• 3 years ago

You use them all the time in Haskell and OCaml. Cache locality isn't such an issue. You're not mallocing linked list nodes. You allocate by a pointer bump of the minor heap, and if the GC copies your list into the major heap, it's going to copy the list elements together.

You also use recursion all the time, and no, recursion is not generally straightforwardly optimised into iteration unless you're doing trivial tail recursion.

ReleaseCandidat14• 3 years ago

Yes I know and at least GHC optimizes lists better than most other data structures (I guess even isomorphic ones). But I guess your definition of "all the time" is not the samé as mine (yes, I use them in every project too). What I wanted to express is that lists are way less used than beginner tutorials may make it seem and there are other data structures available (like in other languages ;).

dvektor3• 3 years ago

Notice the ! in "!significant whitespace"

I thought I was being slick

ReleaseCandidat14• 3 years ago

Oh, sorry. I've read that as "non-lazy whitespace" ;)

grumpyprole5• 3 years ago

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, the standard library encourages Seq instead over List.

It's a shame the author did not get past the basics, as there are many interesting comparisons to be made. For example, OCaml 5 effect handlers are a very interesting alternative to Rust's Async.

IshKebab5• 3 years ago

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.

ReleaseCandidat14• 3 years ago

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 `<poly>` instead of the "real" value

yodsanklai5• 3 years ago

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.

grumpyprole5• 3 years ago

You're also correct that you don't have to use lists, but again most OCaml code does.

If the list is not being used in a critical section, what's the problem? The implication here is that OCaml is slow or inefficient. OCaml is often orders of magnitude faster than other high-level languages (e.g. Python). Arrays in OCaml can result in some very fast code.

lapinot• 3 years ago

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

grumpyprole5• 3 years ago

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.

sadiq2• 3 years ago

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

dvektor3• 3 years ago

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 :)

grumpyprole5• 3 years ago

Glad to hear there is more to come! I do think OCaml 5 not only keeps the language relevant but also makes it even more interesting.

MrJohz2• 3 years ago

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, the standard library encourages Seq instead over List.

I have repeatedly found this the hardest part of learning OCaml - it seems really difficult to find a tutorial that explains how to write OCaml as a real developer would working with production OCaml. Like, I don't need another explanation of sum types or recursion, these are things I'm already using regularly. I'm more interested in the things that OCaml does uniquely that I won't have seen in other languages.

For example, which sequence type should I be using most often? And how often should I be using refs/mutability? And there's lots of alternate stdlibs - should I be dipping into those? What does unit testing typically look like for an OCaml project (and what about other forms of testing)?

It's also very difficult to search for these sorts of things, because I feel like a lot of the results I get are for students learning OCaml as an introduction to functional programming, so questions like "how do I reverse a list" are answered by showing a clever recursive function that reverses a list, as opposed to the List.rev function.

I am not the author, but I'm in a similar situation (right down the Rust background and trying out OCaml for AoC), and I'd love to get past the basics, but it's very difficult trying to find worthwhile resources to do that with.

i_don_t_know• 3 years ago

Some of your questions might be answered in this book (free online version): https://dev.realworldocaml.org/

dvektor3• 3 years ago

Cool to see I'm not the only one in this situation...

I want to like the language very much, so that is helping. That CIS310something or other course that is on Youtube is pretty cool, although a little slow for me (this is usually my issue with tutorials) but I did find the book online and that is great. I definitely hear you on the search results thing...

I started declaring all my types manually just because that's what I'm used to but switched back just because I feel like matching the 'standard'. I will definitely admit to a dodgy AOC solution (hard-coding with magic values).. but overall I'm enjoying it quite a bit.

bmitc6• 3 years ago

I would personally recommend trying out F#. :) Answers below are for F#.

For example, which sequence type should I be using most often?

You should basically default to list. If you need assignment and indexing or a 2D structure, use array. If you're writing generic processing code, use sequences if you can. Use sequence if you need lazy sequences.

And how often should I be using refs/mutability?

Only when you need. I most often use mutability when interacting with unmanaged code, translating some Python or other imperative code before transitioning it to be more functional, and inside classes to manage internal state. Otherwise, I don't.

And there's lots of alternate stdlibs - should I be dipping into those?

I'm not familiar enough with the OCaml ecosystem, but F# doesn't have this problem. F# has its own core library and for everything else, you just reach out to .NET.

What does unit testing typically look like for an OCaml project (and what about other forms of testing)?

I personally use FsUnit, specifically the XUnit flavor. https://fsprojects.github.io/FsUnit/xUnit.html. FsUnit is an F# DSL over NUnit and XUnit, so it fits in well with F# and functional thinking but also plugs into the IDEs and `dotnet test`.

IshKebab5• 3 years ago

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 company that is written in OCaml and I ended up spending so much time helping people fight OPAM that I eventually implemented a build cache system so they didn't need to actually compile the OCaml code at all. Saved a bunch of hassle.

It seems like a pretty decent language, aside from the issues the author of this article mentioned which are 100% true. But OPAM means I would never pick it.

Similar issue to Python, which isn't really a bad language (I'd say it's mediocre-to-ok), but the packaging and tooling story is abysmal.

More languages need to learn from Go, Deno and to a slightly lesser extent Rust which have all prioritised having a packaging system that doesn't make you want to tear your eyes out.

ReleaseCandidat14• 3 years ago

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 problém, not a solution either).

IshKebab5• 3 years ago

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

forgotpwd16• 3 years ago

Interestingly the original Rust compiler was written in OCaml. Or to be more precise the one used for bootstrapping rustc.

sgt• 3 years ago

Seeing his picture, I figured this guy almost looks like a thug, and sure enough he's in prison, albeit not a thug anymore. His story:

https://pthorpe92.github.io/intro/my-story/

Looks like he's got everything lined up for success when he one days is let out of prison. Great attitude and lots of experience.

ReleaseCandidat14• 3 years ago

https://news.ycombinator.com/item?id=38229231

OCaml: a Rust developer's first impressions

Related Stories