I wish somebody with this amount of experience would compare the benefits / shortcomings of using the ReasonML syntax. (The article mentions it once, in passing.)
OCaml as my primary language
41–50 of 296 posts
Re: OCaml as my primary language
#42Earlier quoted context omitted.
"use opam" is always the answer but in reality its the worst package manager ever. I've never seen so many packages fail to install, so many broken dependencies and miscompilations that resulted in segfaults due to wrong dependencies. I just gave up with Ocaml due to the crappy ecosystem, although I could have lived with the other idiosyncrasies.
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....
Re: OCaml as my primary language
#43I 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…
[flagged]
Re: OCaml as my primary language
#44In F# comparison. Modules "my opinion, strongly justify preferring one over the other". Strong stance on Modules. My ignorance, what do they do that provides that much benefit. ??
In short, OCaml modules are used for coarse-grained generics.
Modules are like structurally-typed records that can contain both abstract types and values/functions dependent on those types; every implementation file is itself a module. When passed to functors (module-level functions), they allow you to parameterize large pieces of code, depending on multiple types and functions, all at once quite cleanly. And simply including them or narrowing their signatures is how one exports library APIs.
(The closest equivalent I can imagine to module signatures is Scala traits with abstract type members, but structurally-typed and every package is an instance.)
However, they are a bit too verbose for finer-grained generics. For example, a map with string keys needs `module String_map = Map.Make(String)`. There is limited support for passing modules as first-class values with less ceremony, hopefully with more on the way.
Re: OCaml as my primary language
#45I 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.
> terser languages don't work all that well with LLMs
I’d believe that, but I haven’t tried enough yet. It seems to be doing quite well with jq. I wonder how its APL fares.
When Claude generates Haskell code, I constantly want to reduce it. Doing that is a very mechanical process; I wonder if giving an agent a linter would give better results than overloading it all to the LLM.
Re: OCaml as my primary language
#46I 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
Re: OCaml as my primary language
#47Earlier 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.
And the next milestone of Dune is to become an alternative package manager via Dune package Management, using a store in a "nixish" way.
Re: OCaml as my primary language
#48Earlier quoted context omitted.
> I have no idea I can tell. Thankfully the OCaml textbook has this explicitly called out. https://dev.realworldocaml.org/variants.html#combining-recor... > The main downside is the obvious one, which is that an inline record can’t be treated as its own free-standing object. And, as you can see below, OCaml will reject code that tries to do so.
That's for embedded records. You can have the same thing as Kotlin but with better syntax.
If you don't do inline records you either
- create a separate record type, which is no less verbose than Java's approach
- use positional destructuring, which is bug prone for business logic.
Also it's funny that you think OCaml records are "with better syntax". It's a weak part of the language creating ambiguity. People work around this qurik by wrapping every record type in its own module.
https://dev.realworldocaml.org/records.html#reusing-field-na...
Re: OCaml as my primary language
#49Earlier quoted context omitted.
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.
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?
Re: OCaml as my primary language
#50In F# comparison. Modules "my opinion, strongly justify preferring one over the other". Strong stance on Modules. My ignorance, what do they do that provides that much benefit. ??
I don't know OCAML well but I think this is referring to the fact that modules on OCAML can be generic. In f# there is no HKTs that is types that can be parameterised with type classes. So in F# you have to have List.map, option.map etc, whereas in a language like OCAML or Haskell they would have one parametrised module