51–60 of 296 posts
If I wanted to program in OCaml, id program in F# instead
Hi! Thank you for your interest (and for potentially reading this). Yes, F# is a very nice language, however, it seems to me that I am making a somewhat forced comparison between OCaml and F# in the following section: https://xvw.lol/en/articles/why-ocaml.html#ocaml-and-f
Earlier quoted context omitted.
There is a lot of work on Dune Package Management that will fix some legacy issues related to OPAM, https://dune.readthedocs.io/en/stable/tutorials/dune-package... !! Stay tuned!
Dune is not a dependency manager, it is a build tool. Opam is the dependency manager. By default, Dune doesn't fetch dependencies, opam does that. That said, Dune does use opam, yeah.
Earlier quoted context omitted.
And even if you do get opam working for a project, it's not at all reproducible and will just randomly break at some point in the future. For instance, I had this in a Dockerfile for one project: RUN eval $(opam env) && opam install --yes dune=3.7.0 One day the build just randomly broke. Had to replace it with this: RUN eval $(opam env) && opam install --yes dune=3.19.1 Not a big change, but the fact that this happen…
Use "opam lock" and "opam pin". Additionally, Dune's lockdir feature uses opam's solver internally to generate a lock directory containing ".opam.locked" files for every dependency. This is Dune's way of having fully reproducible builds without relying on opam's switch state alone. Additionally, see: https://dune.readthedocs.io/en/stable/tutorials/dune-package... .
I saw a talk by someone from Google about their experiences using Rust in the Android team. Two points stuck out: they migrated many projects from Python, so performance can't have been that much of a concern, and in their surveys the features people liked most were basics like pattern matching and ADTs. My conclusion is that for a lot of tasks the benefit from Rust came from ML cicra 1990, not lifetimes etc. I feel…
doesnt rust still have the advantage of having no gc? I dont like writing rust, but the selling point of being able to write performative code with memory safety guarantees has always stuck with me
When I see Rust topping the "most loved language" on Stack Overflow etc. what I think is really happening is that people are using a "modern" language for the first time. I consistently see people gushing about, e.g., pattern matching in Rust. I agree pattern matching is awesome, but it is also not at all novel if you are a PL nerd. It's just that most commercial languages are crap from a PL nerd point of view.
So I think "no gc but memory safe" is what got people to look at Rust, but it's 1990s ML (ADTs, pattern matching, etc.) that keeps them there.
[1]: https://github.com/oxcaml/oxcaml
[2]: https://docs.scala-lang.org/scala3/reference/experimental/cc...
I saw a talk by someone from Google about their experiences using Rust in the Android team. Two points stuck out: they migrated many projects from Python, so performance can't have been that much of a concern, and in their surveys the features people liked most were basics like pattern matching and ADTs. My conclusion is that for a lot of tasks the benefit from Rust came from ML cicra 1990, not lifetimes etc. I feel…
No way OCaml could have stolen the Rust's thunder: we have a number of very decent and performant GC-based languages, from Go to Haskell; we only had one bare-metal-worthy expressive language in 2010, C++, and it was pretty terrible (still is, but before C++11 and C++17 it was even more terrible).
I’ve always been curious about OCaml, especially since some people call it “Go with types” and I’m not a fan of writing Rust. But I’m still not sold on OCaml as a whole, its evangelists just don’t win me over the way the Erlang, Ruby, Rust, or Zig folks do. I just cant see the vision
Some years ago I also wanted to make ocaml my primary language, but rapidly encountered problems: difficulty to install (on Linux due to the requirement of a very unusual tool which name and function I forgot), no response from community regarding how to solve that problem, no solid postgresql driver, .... Wanting to use a functional language I pivoted to fsharp, which was not the expected choice for me as I use Linu…
I haven't worked in OCaml but I have worked a bit in F# and found it to be a pleasant experience. One thing I am wondering about in the age of LLMs is if we should all take a harder look at functional languages again. My thought is that if FP languages like OCaml / Haskell / etc. let us compress a lot of information into a small amount of text, then that's better for the context window. Possibly we might be able to p…
That was my optimistic take before I started working on a large Haskell code base. Aside from the obvious problem that there's not enough FP in the training corpus, it seems like terser languages don't work all that well with LLMs. My guess is that verbosity actually helps the generation self-correct... if it predicts some "bad" tokens it can pivot more easily and still produce working code.
What a brilliant article, it really puts to rest for me, the whole “why not use F#?” argument. In almost every OCaml thread, someone suggests F# as a way to sidestep OCaml’s tooling. I’ve always been curious about OCaml, especially since some people call it “Go with types” and I’m not a fan of writing Rust. But I’m still not sold on OCaml as a whole, its evangelists just don’t win me over the way the Erlang, Ruby, Ru…
But OCaml sadly can't replace F# for all my use cases. F# does get access to many performance-oriented features that the CLR supports and OCaml simply can't, such as value-types. Maybe OxCaml can fix that long term, but I'm currently missing a performant ML-like with a simple toolchain.
Earlier quoted context omitted.
And the next milestone of Dune is to become an alternative package manager via Dune package Management, using a store in a "nixish" way.
I suppose it is still going to use opam internally, right?