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

91–100 of 157 posts

Re: OCaml: a Rust developer's first impressions

#91

Post by IshKebab »

The biggest issue for me with OCaml is OPAM. It's pretty awful. Simple things like "install this code" don't work reliably - often installing a different branch or just ignoring edits you've made, even after you discover the flag that says it should include them (it seems to be simply broken). It also doesn't work on Windows in any meaningful way.

It's not just me that has these issues. We introduced a tool into my company that is written in OCaml and I ended up spending so much time helping people fight OPAM that I eventually implemented a build cache system so they didn't need to actually compile the OCaml code at all. Saved a bunch of hassle.

It seems like a pretty decent language, aside from the issues the author of this article mentioned which are 100% true. But OPAM means I would never pick it.

Similar issue to Python, which isn't really a bad language (I'd say it's mediocre-to-ok), but the packaging and tooling story is abysmal.

More languages need to learn from Go, Deno and to a slightly lesser extent Rust which have all prioritised having a packaging system that doesn't make you want to tear your eyes out.

Re: OCaml: a Rust developer's first impressions

#92

Post by ReleaseCandidat »

momentoftop wrote: post #86
ReleaseCandidat wrote: post #75

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

Yes I know and at least GHC optimizes lists better than most other data structures (I guess even isomorphic ones). But I guess your definition of "all the time" is not the samé as mine (yes, I use them in every project too). What I wanted to express is that lists are way less used than beginner tutorials may make it seem and there are other data structures available (like in other languages ;).

Re: OCaml: a Rust developer's first impressions

#93

Post by _xivi »

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.

"An NFL player found that he managed to be good at rugby after 2 months of practice, but when he tried to do gymnastics (or cycling or tennis or motorsports or ...) in the same time frame, the results were terrible."

What does that tell you the sports he tried to do? Not much. It's all about his previous experience and skills.

Re: OCaml: a Rust developer's first impressions

#94

Post by ReleaseCandidat »

IshKebab wrote: post #91

The biggest issue for me with OCaml is OPAM. It's pretty awful. Simple things like "install this code" don't work reliably - often installing a different branch or just ignoring edits you've made, even after you discover the flag that says it should include them (it seems to be simply broken). It also doesn't work on Windows in any meaningful way. It's not just me that has these issues. We introduced a tool into my c…

The biggest problém with Opam and OCaml on Windows is that most of the packages won't work. Officially, Opam does not support Windows at all, that is going to be included with 2.2 (which is still in alpha AFAIK) https://opam.ocaml.org/blog/opam-2-2-0-alpha/#Windows-Suppor...

I always thought of Opam as the best feature of OCaml (especially compared to Haskell with two no-working package managers - and no, Nix is a problém, not a solution either).

Re: OCaml: a Rust developer's first impressions

#95

Post by tromp »

misja111 wrote: post #69
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…

OCaml is not a very good fit for competitive programming, you're better off with a language like Python there. Writing code in a functional language like OCaml requires a mind switch. This can take quite a while. It took me years to really 'get it' after having programmed for 30 years in imperative languages. Now I prefer writing code in FP for a lot of things, but not for everything. E.g. for coding some algorithms…

While Haskell's Array type indeed immutable, there is an incremental update function

    (//)            :: (Ix a) => Array a b -> [(a,b)] -> Array a b
that gives you a new updated array. As long as you no longer refer to the old instance, this is as efficient as a mutable array.

But Haskell also offers the mutable STArray and STUArray, for boxed and unboxed types [1]. These preserve their purity by being monadic.

[1] https://hackage.haskell.org/package/array-0.5.6.0/docs/Data-...

Re: OCaml: a Rust developer's first impressions

#96

Post by ReleaseCandidat »

IshKebab wrote: post #90
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,…

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 .

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

That is because they are generic most of the time.

This is also fun when using `#trace`in the REPL and all you see is `` instead of the "real" value

Re: OCaml: a Rust developer's first impressions

#97

Post by yodsanklai »

IshKebab wrote: post #90
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,…

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.

Re: OCaml: a Rust developer's first impressions

#98

Post by grumpyprole »

IshKebab wrote: post #90
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,…

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 .

> You're also correct that you don't have to use lists, but again most OCaml code does.

If the list is not being used in a critical section, what's the problem? The implication here is that OCaml is slow or inefficient. OCaml is often orders of magnitude faster than other high-level languages (e.g. Python). Arrays in OCaml can result in some very fast code.

Re: OCaml: a Rust developer's first impressions

#99

Post by fweimer »

nextaccountic wrote: post #59
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?

Rust has panics as well and they appear pretty much everywhere, because the Rust stdlb made a conscious decision to panic on allocation failures (later non-panicking APIs were added, but most people dont use them, and in special, most dependencies will not use this and will panic on random occasions), and also because common operations like integer division and array indexing will panic on bugs (and also integer over…

Rust currently cannot reliably panic on allocation failures because the error object is inside a Box, which itself requires allocation. This means that if memory is tight, panicking itself might fail.

For reference, this is the type that is returned from catch_unwind: https://doc.rust-lang.org/std/thread/type.Result.html

But I completely agree that Rust has exceptions. They are even used in the toolchain implementation for non-local control flow.

Re: OCaml: a Rust developer's first impressions

#100

Post by fweimer »

hurril wrote: post #77
bananapub wrote: post #13

Earlier quoted context omitted.

why do feel exceptions make a language unsafe?

Safe isn't the best word to describe it with. But it does mean that any expression or statement always has two possible control flows. You have the "surface flow" as well as the exceptional flow, so there's an added complexity. I never felt this was a problem when I did Java though (despite their awkwardness - basically forcing coders to not use checked exceptions.) Rust's control flow syntax for Results and Options…

I don't think panics are comparable to Java's VM errors. A lot of libraries (not just the standard library) seem to target panic-safety, avoiding unsafe behavior and resource leaks in case of panics. This means that the panic itself is not supposed to transition the process into an undefined state, like it happens with many VM errors in Java (where a stack overflow may mean that required cleanup action has not executed, for example).

With Rust, the overall situation is a bit strange: as a library author, you are expected to deal with the possibility of panics (which gives you all the headaches associated with dealing with exception safety), but as a user, you are not supposed to rely on them. (I expect that most request handler loops will have catch_unwind handlers, to avoid a faulty request taking down the entire process.)

Post reply on HN