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

21–30 of 157 posts

Re: OCaml: a Rust developer's first impressions

#21

Post by satvikpendem »

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…

For sure, I agree with your points, which is why I write Rust these days instead of OCaml. Sometimes you really just want to get stuff done, while also being faster in execution speed of both the machine and the human.

Re: OCaml: a Rust developer's first impressions

#22

Post by timschmidt »

bananapub wrote: post #13
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?

why do feel exceptions make a language unsafe?

Second, less-predictable execution path. Additional cognitive load in evaluating effects across both paths. Additional opportunity for bugs. Doesn't necessarily mean that exceptions make all software which uses them unsafe, but does tend to mean that exceptions significantly complicate the task of proving safety for any nontrivial program.

Re: OCaml: a Rust developer's first impressions

#23

Post by dan-robertson »

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…

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.

Re: OCaml: a Rust developer's first impressions

#24

Post by vips7L »

cglong wrote: post #17
preommr wrote: post #11

Earlier quoted context omitted.

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.

At least in my piece of corporate software engineering, I'm looking at Rust as a "gateway drug" for FP. Management doesn't want to take the risk of investing in FP, so reliable choices like Java and C++ are usually endorsed; the safety aspects of Rust are a much stronger argument for them.

I don't think the safety aspects are a much stronger argument. Managed languages like Java and C# are safe. The garbage collector isn't going to let you ++ your way into remote code execution and most corporate software engineering isn't heavily concurrent. I think a stronger argument would be to advocate for a more functional language on the same runtime, like Scala or F#.

Re: OCaml: a Rust developer's first impressions

#25

Post by bmitc »

debo_ wrote: post #20
bmitc wrote: post #14

Earlier quoted context omitted.

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

In OCaml the type checker won't force you to handle exceptions (from what I remember.) See e.g. https://ocaml.org/docs/error-handling#exceptions

That's true, but at least in my experience, it is rarely a problem. Because if you're at a point in your program where you don't want to bubble up, you can just pattern match against the exceptions just as you would a Result type, which F# also has.

I don't know Rust, but after searching, it seems that it has a panic facility which seems even more escaping than an exception. Happy to be corrected there.

Re: OCaml: a Rust developer's first impressions

#26

Post by frodowtf »

bmitc wrote: post #25
debo_ wrote: post #20

Earlier quoted context omitted.

In OCaml the type checker won't force you to handle exceptions (from what I remember.) See e.g. https://ocaml.org/docs/error-handling#exceptions

That's true, but at least in my experience, it is rarely a problem. Because if you're at a point in your program where you don't want to bubble up, you can just pattern match against the exceptions just as you would a Result type, which F# also has. I don't know Rust, but after searching, it seems that it has a panic facility which seems even more escaping than an exception. Happy to be corrected there.

`panic` has nothing to do with error handling though. If you use it, you know that your callers cannot recover from it.

Throwing an exception implicitly delegates error handling back to the caller, but they are not even notified about it. (talking about OCaml)

Re: OCaml: a Rust developer's first impressions

#27

Post by cmrdporcupine »

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

Re: OCaml: a Rust developer's first impressions

#28

Post by cmrdporcupine »

satvikpendem wrote: post #5
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.

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?

Re: OCaml: a Rust developer's first impressions

#29

Post by cmrdporcupine »

frodowtf wrote: post #10
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…

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

Re: OCaml: a Rust developer's first impressions

#30

Post by whateveracct »

debo_ wrote: post #4
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 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.
Post reply on HN