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

31–40 of 157 posts

Re: OCaml: a Rust developer's first impressions

#31

Post by weatherlight »

cmrdporcupine wrote: post #29
frodowtf wrote: post #10

Earlier quoted context omitted.

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

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

I agree, Standard ML's syntax feels a lot cleaner than that of OCamls.

Re: OCaml: a Rust developer's first impressions

#32

Post by dgacmu »

cmrdporcupine wrote: post #28
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…

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

IANASE (swift expert), but the rust ? operator is used for error propragation in the same way that the try operator in swift is. Swift's ?? operator is for unwrapping an option type: x ?? default, similar to x.unwrap_or(default) in Rust. (Swift's ? is the ternary operator, as in C; rust does not have a ternary operator, using expression-if instead). Applied to a type, swift's ? is the same as Option in Rust.

Rust's first mechanism for error propagation was the now-deprecated try!() macro, which did basically the same thing.

Re: OCaml: a Rust developer's first impressions

#33

Post by unstruktured »

satvikpendem wrote: post #2

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…

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.

Re: OCaml: a Rust developer's first impressions

#34

Post by satvikpendem »

unstruktured wrote: post #33
satvikpendem wrote: post #2

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…

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.

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

Re: OCaml: a Rust developer's first impressions

#35

Post by chmod600 »

whateveracct wrote: post #30
debo_ wrote: 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.

Can you explain "proper closures"?

Re: OCaml: a Rust developer's first impressions

#36

Post by steveklabnik »

cmrdporcupine wrote: post #29
frodowtf wrote: post #10

Earlier quoted context omitted.

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

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

From the presentation introducing Rust to Mozilla: http://venge.net/graydon/talks/intro-talk-2.pdf

> I have been writing a compiled, concurrent, safe, systems programming language for the past four and a half years.

Safety was always part of it.

Re: OCaml: a Rust developer's first impressions

#38

Post by stouset »

bmitc wrote: post #12
hardwaregeek wrote: post #3

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…

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

Re: OCaml: a Rust developer's first impressions

#39

Post by koito17 »

bmitc wrote: post #12
hardwaregeek wrote: post #3

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…

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

Re: OCaml: a Rust developer's first impressions

#40

Post by munchler »

hardwaregeek wrote: post #3

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

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.

Post reply on HN