2021 at OCamlPro | Hacker News Reader

2021 at OCamlPro

ocamlpro.com

104 pointsgjadi23 comments

OCaml is one of my favourite languages. It's such a sweet spot in terms of conciseness and performance - yes there are a few language more concise and a few that have faster implementations but I can't think of any that are both as fast and as concise.

Tooling has come a long way too - very impressed by dune, it lets me do my favourite thing in the world which is hit save and run my tests automatically.

I'd use it a lot more if the ecosystem was bigger. Just can't justify a better language when I'd have to implement my own, idk, mutable ordered dictionary.

Have you worked with Elixir? Not trying to hijack the thread into an Elixir one, I'm more interested in what you think of Elixir so that I have a benchmark from which to consider your praise of OCaml :-)

It's great to hear that Opam is making progress! I just wished that it would be more deeply integrated with Dune. A package manager that doesn't build is not very useful to be honest. Currently the only way to not have to care about switches and be able to clearly specify dependencies is to use the esy package manager[1] (which had lock files a while ago). With their work on Rust I can only hope they get inspired by Cargo.

It's also interesting to see that they're working a lot with Rust. I've seen a lot of OCaml people switching to Rust or getting more and more into Rust, I'm wondering what this means for OCaml.

[1]: https://github.com/esy/esy/

They do, they are developing drom[1], a wrapper over opam and dune to provide a cargo-like experience.

[1]: https://ocamlpro.github.io/drom/

What’s wrong with opam? Since version 2 it also supports local switches and locking, and the opam repository has become much more stable than in the past. Full disclosure: I am biased here, since I am one of the opam-repository maintainers and I am quite happy with opam itself.

> What’s wrong with opam?

I'd say the main problem is that local switches and lock files are still not the default mode of operation.

Also opam lacks a global cache of built packages which esy provides (esy's cache is modelled after Nix package manager). So every new opam local switch effectively compiles everything from scratch. Though, as I understand this aspect is going to be addressed by dune at some point (though esy caches not just OCaml built artefacts but also C/C++).

(Full disclosure: I'm biased as I'm one of the original developers of esy)

I’ve tried using drom and it’s not really close to what Cargo provides. Instead it builds a lot of boilerplate config.

being able to pipe dune through opam would be cool – write human stuff to stderr and opam input to stdout. And then run e.g.

  $ dune runtest | opam

dune and opam would have to agree on how to talk with each other, however.

Learn OCaml is a cool platform to play with OCaml and I'm excited about their work on TLA+ !

It would be interesting to know more about the COBOL migration and the parser. I am sure, many other companies with the legacy codebase would be interested in this.

Rust at OCamlPro?

Rust is heavily influenced by OCaml. The first Rust compiler was written in Rust.

Yes, I know this, but this is going the other direction and seems kind of noteworthy: OCamlPro exists to promote OCaml, and it looks like they're making some forays into Rust?

OCaml - Rust interop would be very cool, whatever low-level stuff you can throw into Rust while being able to use it from OCaml would be interesting.

There are a number of interesting projects already doing this, either doing it manually via the c FFI or using projects like ocaml-rs [1] or ocaml-interop [2] for example

[1]: https://github.com/zshipko/ocaml-rs [2]: https://github.com/tezedge/ocaml-interop

We use ocaml-rs[1] and ocaml-gen[2] for that, it works pretty well although there’s room for improvement.

[1]: https://github.com/zshipko/ocaml-rs

[2]: https://github.com/o1-labs/proof-systems/tree/a4b06e71106704...

> The first Rust compiler was written in Rust.

That's impressive!

(yeah, it could have been interpreted)

Fuck I meant OCaml.

I think Rust and Ocaml are very different languages.

I went into Rust thinking I could use it like a kind of curly brace Ocaml, and that's totally off. It's much more like a very strict modern C++ with a lot of historical cruft removed.

OCaml is much more concise and higher level. It also doesn't let you reason about memory layout really well. Plus Ocaml has parametric polymorphism and higher order modules, compared with rusts ad-hoc polymorphism and traits. In Ocaml the idiomatic solution is often recursion but that will blow the rust stack.

(full disclaimer, I'm much better at Ocaml than I am Rust, and I'm really not great at Ocaml)

rust has parametric polymorphism, it just calls it generics—and traits correspond to ocaml signatures. These aren't useful juxtapositions.

I'll take your word that I'm misusing the terms.

Key difference - as a user - is in Ocaml I'd write a module with a bunch of functions. In rust I'd write a struct with a bunch of methods. It feels very different even if it solves the same things.

> The first Rust compiler was written in Rust

I think you meant "was written in OCaml"

I did, haha.

They specialize in both, they should probably change name from "OCamlPro SAS" to something like "R&D SAS" or whatever.

Reply on news.ycombinator.com