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

101–110 of 157 posts

Re: OCaml: a Rust developer's first impressions

#101

Post by yodsanklai »

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

Re: OCaml: a Rust developer's first impressions

#102

Post by lapinot »

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

Re: OCaml: a Rust developer's first impressions

#104

Post by andrepd »

serial_dev wrote: post #80
hurril wrote: 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.

I'd say one thing in your defense, it's absolutely true that the ocaml standard library is atrocious. Replace it with something like Base and you will at least stop struggling with basic stuff like simple IO.

Re: OCaml: a Rust developer's first impressions

#105

Post by sakras »

dan-robertson wrote: post #18
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…

I think the ‘is or is not a true ML’ argument is a bit unwinnable so I won’t comment on it. Regarding ‘functional’, Rust makes it harder to write in a traditional functional style because (a) it doesn’t offer tail-call elimination and (b) the resource-ownership tracking makes most normal functions feel side-effecty. I think it’s pretty hard to have a natural-feeling functional style without cheap allocation and some…

> it doesn’t offer tail-call elimination

Why not? I’ve heard people say this about C too and I never understood it: LLVM and GCC both have optimization passes that perform tail-call elimination.

Re: OCaml: a Rust developer's first impressions

#106

Post by grumpyprole »

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

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.

Re: OCaml: a Rust developer's first impressions

#107

Post by sgt »

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.

Re: OCaml: a Rust developer's first impressions

#108

Post by ReleaseCandidat »

sgt wrote: post #107

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.

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

Re: OCaml: a Rust developer's first impressions

#109

Post by ReleaseCandidat »

yodsanklai wrote: post #97
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 .

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

Re: OCaml: a Rust developer's first impressions

#110

Post by toolslive »

ReleaseCandidat wrote: post #83
serial_dev wrote: post #80

Earlier quoted context omitted.

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.

yes: paradigm shifts are not easy.
Post reply on HN