5 ms·

Having coded a lot in both OCaml (I used to lead OCaml Batteries Included) and Rust (I'm a contributor to the Rust compiler and stdlib), I believe that they hav

by Yoric 7y ago

Having coded a lot in both OCaml (I used to lead OCaml Batteries Included) and Rust (I'm a contributor to the Rust compiler and stdlib), I believe that they have very different targets. Rust is really, really good at systems-level programming, it has great concurrency, but closures are more restricted than OCaml and it doesn't have general garbage-collection. OCaml shines to implement really complicated algorithms. Anything that requires symbolic manipulation/pattern-matching, for instance, or manipulating large graphs, or maintaining extremely complex invariants. Garbage-collection that just works is invaluable but it doesn't play nicely with multicore yet. In other words, I believe that there's room for both in our world! I could see myself developing applications in which some components are implemented in Rust and others in OCaml.

giornogiovanna 7y ago
Besides GC and the lightweight syntax (relative to Rust), what is it about OCaml that makes it so wonderful for implementing complicated algorithms?
- pjmlp 7y ago
  Exactly that, lock-free algorithms are specially hard to get a correct implementation without tracing GC support.
  - terminaljunkid 7y ago
    Why?
    - pjmlp 7y ago
      Here is an overview, read also the comments. https://concurrencyfreaks.blogspot.com/2017/08/why-is-memory-reclamation-so-important.html?m=1 https://concurrencyfreaks.blogspot.com/2017/08/why-is-memory...
- Yoric 7y ago
  Well, the big one is GC. Here are a few others: - both polymorphic variants and GADTs are extremely powerful mechanisms to let you keep track of invariants, in a manner that cannot be replicated readably in Rust so far; - OCaml's pattern-matching is a bit more flexible than Rust's ; - (thanks to the GC) OCaml's closures are much more flexible than Rust closures; - I guess OCaml's blindingly fast exceptions can be useful for some algorithms, although I haven't really experienced the need for them myself. Again, that's not to say that Rust doesn't have great stuff for it (affine types 4eva!) or that OCaml doesn't have its own limitations – Rust is currently my main language and I do not regret it. But there are some algorithms that I really don't want to write in Rust. Recently, for instance, I stumbled upon this: http://weblog.jamisbuck.org/2010/12/29/maze-generation-eller-s-algorithm http://weblog.jamisbuck.org/2010/12/29/maze-generation-eller... . Trivial algorithm, trivial to write in OCaml, feasible but much less straightforward in Rust.
polskibus 7y ago
What's your opinion on F# ? Does it share enough of OCaml goodness to be worth using in .Net world or instead of OCaml?
- Yoric 7y ago
  I never seriously used F#, so I can't tell for sure, but it looks pretty good!
- Jorge1o1 7y ago
  I’ve used F# and USING it feels very similar to OCaml in all of the important ways. The lightweight type structure where you can easily make Union types and the pattern matching are pretty much identical to how OCaml does it. Of course, the big difference is going to be in how easily you can interop with the .Net stuff in each language, obviously much easier in F#. This is great if you happen to have some kind of weird C# code that generates an IEnumerable, just pop that into F# and start working with it. For example, I have C# classes to read files to an IEnumerable of strings, you can just call List.ofSeq on it, and then start doing some really elegant things in F# with it. You can pattern match log files based on how the line starts and then run different functions whether it’s an error, info, debug, etc
- gameswithgo 7y ago
  F# is very much like a .NET port of OCaml. It is very nice to use and offers (usually) low effort interop with all of the worlds C# libraries. We use it in production at Olo, and I used it in production at my last company. Since learning F#, languages where if statements aren't expressions and that don't have option types feel broken to me =)
  - polskibus 7y ago
    I can see that F# still does not support GADTs. Did you find it a serious limitation?
    - daxfohl 7y ago
      Depends on what you're trying to do. I've never found it to be a limitation but I don't do anything terribly intricate. Just web dev for work, and I wrote a toy language parser and type inferencer in it. There are maybe three lines of code that GADTs might have let me avoid casting in the type inferencer, but oh well. Different use cases that use GADTs to a greater extent, of course, you might miss them. What is your use case, and how much are you reliant on GADTs in your existing daily life?

by Yoric 7y ago

giornogiovanna 7y ago

Besides GC and the lightweight syntax (relative to Rust), what is it about OCaml that makes it so wonderful for implementing complicated algorithms?

pjmlp 7y ago
Exactly that, lock-free algorithms are specially hard to get a correct implementation without tracing GC support.
- terminaljunkid 7y ago
  Why?
  - pjmlp 7y ago
    Here is an overview, read also the comments. https://concurrencyfreaks.blogspot.com/2017/08/why-is-memory-reclamation-so-important.html?m=1 https://concurrencyfreaks.blogspot.com/2017/08/why-is-memory...
Yoric 7y ago
Well, the big one is GC. Here are a few others: - both polymorphic variants and GADTs are extremely powerful mechanisms to let you keep track of invariants, in a manner that cannot be replicated readably in Rust so far; - OCaml's pattern-matching is a bit more flexible than Rust's ; - (thanks to the GC) OCaml's closures are much more flexible than Rust closures; - I guess OCaml's blindingly fast exceptions can be useful for some algorithms, although I haven't really experienced the need for them myself. Again, that's not to say that Rust doesn't have great stuff for it (affine types 4eva!) or that OCaml doesn't have its own limitations – Rust is currently my main language and I do not regret it. But there are some algorithms that I really don't want to write in Rust. Recently, for instance, I stumbled upon this: http://weblog.jamisbuck.org/2010/12/29/maze-generation-eller-s-algorithm http://weblog.jamisbuck.org/2010/12/29/maze-generation-eller... . Trivial algorithm, trivial to write in OCaml, feasible but much less straightforward in Rust.

polskibus 7y ago

What's your opinion on F# ? Does it share enough of OCaml goodness to be worth using in .Net world or instead of OCaml?

Yoric 7y ago
I never seriously used F#, so I can't tell for sure, but it looks pretty good!
Jorge1o1 7y ago
I’ve used F# and USING it feels very similar to OCaml in all of the important ways. The lightweight type structure where you can easily make Union types and the pattern matching are pretty much identical to how OCaml does it. Of course, the big difference is going to be in how easily you can interop with the .Net stuff in each language, obviously much easier in F#. This is great if you happen to have some kind of weird C# code that generates an IEnumerable, just pop that into F# and start working with it. For example, I have C# classes to read files to an IEnumerable of strings, you can just call List.ofSeq on it, and then start doing some really elegant things in F# with it. You can pattern match log files based on how the line starts and then run different functions whether it’s an error, info, debug, etc
gameswithgo 7y ago
F# is very much like a .NET port of OCaml. It is very nice to use and offers (usually) low effort interop with all of the worlds C# libraries. We use it in production at Olo, and I used it in production at my last company. Since learning F#, languages where if statements aren't expressions and that don't have option types feel broken to me =)
- polskibus 7y ago
  I can see that F# still does not support GADTs. Did you find it a serious limitation?
  - daxfohl 7y ago
    Depends on what you're trying to do. I've never found it to be a limitation but I don't do anything terribly intricate. Just web dev for work, and I wrote a toy language parser and type inferencer in it. There are maybe three lines of code that GADTs might have let me avoid casting in the type inferencer, but oh well. Different use cases that use GADTs to a greater extent, of course, you might miss them. What is your use case, and how much are you reliant on GADTs in your existing daily life?