Live data from Hacker News

OCaml: a Rust developer's first impressions

pthorpe92.github.io

81–90 of 157 posts

Re: OCaml: a Rust developer's first impressions

#81
post #12

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

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

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.

Re: OCaml: a Rust developer's first impressions

#82

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…

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

Re: OCaml: a Rust developer's first impressions

#83
post #73

Earlier quoted context omitted.

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

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.

But it isn't (just) a new programming language, it's a different way of solving problems.

Re: OCaml: a Rust developer's first impressions

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

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.

Jane Street just entered the room: https://blog.janestreet.com/oxidizing-ocaml-locality/

This part specially about closures: https://blog.janestreet.com/oxidizing-ocaml-ownership/

https://blog.janestreet.com/oxidizing-ocaml-parallelism/ And yes, their changes introduce quite some additional syntax.

Re: OCaml: a Rust developer's first impressions

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

Re: OCaml: a Rust developer's first impressions

#86

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

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.

Re: OCaml: a Rust developer's first impressions

#87
post #73

Earlier quoted context omitted.

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

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.

After having learned French, German and Spanish, I spent three months learning Chinese and could not speak it fluently, what a shoddy language

Re: OCaml: a Rust developer's first impressions

#88
post #73

Earlier quoted context omitted.

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

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.

Many of today's popular programming languages are variations on the same theme, leading people to think that their experience is broader than it actually is.

Re: OCaml: a Rust developer's first impressions

#89

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?

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.

Re: OCaml: a Rust developer's first impressions

#90

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

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.

Post reply on HN