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

41–50 of 157 posts

Re: OCaml: a Rust developer's first impressions

#41

Post by bobbylarrybobby »

chmod600 wrote: post #35
whateveracct wrote: post #30

Earlier quoted context omitted.

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"?

I would hazard that this means closures that can capture (shared) state. In Rust, a closure’s data must either be moved into the closure or outlive the closure (dangling pointers etc etc). In most other languages, GC allows closures to keep a handle to any data at all.

Re: OCaml: a Rust developer's first impressions

#42

Post by Georgelemental »

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?

Rust has panics that could appear anywhere.

Re: OCaml: a Rust developer's first impressions

#43

Post by vlovich123 »

debo_ wrote: post #15
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…

True. In this case the author is speaking specifically about OCaml, which is quite comfortable to write imperatively. I think the thing that tickles most people about Rust is the thoroughness of the type inference and type checking, which one generally gets from any ML.

Yeah but traditional ML languages are ass slow. If I want to write applications that are that slow, why not use something that targets the browser or something like Ruby or Python that has a much deeper ecosystem to leverage? Unless you’re just playing around with building a language and trying out different ideas or you think it’s better at some other axis (eg lower defect rate). But I’ve generally found that my incident rate for bugs doesn’t change with languages. What rust has done successfully and “ML” languages have not is how to engage a broader community by exploiting a weakness in some class of problems they can do better on that existing languages cannot. That’s why they shifted into systems languages. Memory safety in systems languages was critically important and ML languages are typically too slow and memory hungry so Rust adopted some of the C/C++ communities obsession with speed and memory usage philosophies while allowing for much safer code to be written. I think it’s safe to say they’ve finally dealt a “COBOL” like blow in that completely new code being written is unlikely to be C++ and C++ developer salaries will keep going up because it’s a difficult niche. will take a few decades to play out because C and C++ is so heavily entrenched. And who knows, maybe the memory safety efforts the standards body is taking will help but I think ultimately it will only be useful for hardening existing codebases but that’s a temporary patch on a bleed. Rust used that initial wedge to jam in a code repository, making testing and benchmarking easier, etc etc. some of the Rust libraries are insanely high quality and waaay easier to work with than in C++ land (even at Google and Facebook where it was a record level of easy)

Re: OCaml: a Rust developer's first impressions

#44

Post by cmrdporcupine »

steveklabnik wrote: post #36
cmrdporcupine wrote: post #29

Earlier quoted context omitted.

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.

But those "Safety" definitions are all not like what Rust folks mean by safety now. He's talking about immutability and bounds checking and avoiding memory corruption but not at all about borrowing.

I guess I should have been more specific. If that's what we mean by safe, then OCaml is safe as well.

Anyways, I followed it at the time. The borrow checker came later.

Re: OCaml: a Rust developer's first impressions

#45

Post by cmrdporcupine »

vips7L wrote: post #24
cglong wrote: post #17

Earlier quoted context omitted.

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

Java and C# will not provide any sanity check on your use of locks and shared mutable state though. But the Rust borrow checker will. It won't prevent deadlock or race conditions, but it will at least guide you there much better than those pass-by-mutable-reference OO languages will.

Re: OCaml: a Rust developer's first impressions

#46

Post by [deleted] »

cmrdporcupine wrote: post #44
steveklabnik wrote: post #36

Earlier quoted context omitted.

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.

But those "Safety" definitions are all not like what Rust folks mean by safety now. He's talking about immutability and bounds checking and avoiding memory corruption but not at all about borrowing. I guess I should have been more specific. If that's what we mean by safe, then OCaml is safe as well. Anyways, I followed it at the time. The borrow checker came later.

[deleted]

Re: OCaml: a Rust developer's first impressions

#47

Post by steveklabnik »

cmrdporcupine wrote: post #44
steveklabnik wrote: post #36

Earlier quoted context omitted.

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.

But those "Safety" definitions are all not like what Rust folks mean by safety now. He's talking about immutability and bounds checking and avoiding memory corruption but not at all about borrowing. I guess I should have been more specific. If that's what we mean by safe, then OCaml is safe as well. Anyways, I followed it at the time. The borrow checker came later.

I absolutely agree the borrow checker came later. I think of it as that the goals have always been the same, but the enforcement mechanism changed over time, as more and more static ways were found to achieve the goal.

Re: OCaml: a Rust developer's first impressions

#48

Post by hardwaregeek »

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…

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.

Re: OCaml: a Rust developer's first impressions

#49

Post by zogrodea »

vlovich123 wrote: post #43
debo_ wrote: post #15

Earlier quoted context omitted.

True. In this case the author is speaking specifically about OCaml, which is quite comfortable to write imperatively. I think the thing that tickles most people about Rust is the thoroughness of the type inference and type checking, which one generally gets from any ML.

Yeah but traditional ML languages are ass slow. If I want to write applications that are that slow, why not use something that targets the browser or something like Ruby or Python that has a much deeper ecosystem to leverage? Unless you’re just playing around with building a language and trying out different ideas or you think it’s better at some other axis (eg lower defect rate). But I’ve generally found that my inc…

I don't think ML languages tend to be that slow, depending on what you compare them with and which member of the family you are using for comparison.

If we have three stages: (1) system languages, (2) higher level languages like Dart, Java, C#, (3) very high level languages like Python and Ruby, then the those among the most popular languages in the ML family (OCaml and F#) comfortably occupy the same level as (2).

Maybe that's not what you're after. OCaml's more rare bytecode implementation (instead of native code) is about on par with Python and SML/NJ is pretty slow as well (although faster SML implementations like MLTon exist).

Re: OCaml: a Rust developer's first impressions

#50

Post by [deleted] »

steveklabnik wrote: post #47
cmrdporcupine wrote: post #44

Earlier quoted context omitted.

But those "Safety" definitions are all not like what Rust folks mean by safety now. He's talking about immutability and bounds checking and avoiding memory corruption but not at all about borrowing. I guess I should have been more specific. If that's what we mean by safe, then OCaml is safe as well. Anyways, I followed it at the time. The borrow checker came later.

I absolutely agree the borrow checker came later. I think of it as that the goals have always been the same, but the enforcement mechanism changed over time, as more and more static ways were found to achieve the goal.

[deleted]
Post reply on HN