6 ms·

OCaml is an impressive language on many fronts: compile time, speed, memory usage, but then is almost crippled beyond usage by a few unfortunate decisions / (la

by xavxav 4y ago

OCaml is an impressive language on many fronts: compile time, speed, memory usage, but then is almost crippled beyond usage by a few unfortunate decisions / (lack of) features: - Dependency management, despite progress `opam` is hopeless brittle because no one uses lock files, good luck building a project that's more than 3 months old. Additionally, by default everything is installed into a global 'switch' and only one version of each package can exist in it. - Build tooling: things are finally improving with `dune`, but the amount of packages that are running hyper-complex Makefile based build systems is incredibly frustrating. It can be very difficult to add a dependency or change the layout of these projects if you aren't an expert in arcane Make sigils. - Error messages: again, finally improving, but the number of times I've gotten errors like "line 78 Syntax Error"... I know that parser generators are appealing academically / intellectually but there's a reason major industrial compilers use recursive descent. - Documentation: Seemingly non-existent for most packages and the tooling is quite poor compared to peer languages (Haskell, Rust). - More controversially, I think that modules are a worse solution in practice than typeclasses / traits. The automatic instance resolution coherence brings is a huge ergonomics win, and it also allows for more ecosystem wide collaboration in practice. I know that modular implicits are supposed to bring the 'best of both' but that doesn't even exist yet. None of the problems above are unfixable but they collaborate to make working in OCaml a very frustrating experience for me, even worse because through them I can see what is actually a quite nice language.

steinuil 4y ago
Re: dependency management and build tooling: these days I'm using opam-monorepo (https://github.com/tarides/opam-monorepo https://github.com/tarides/opam-monorepo, previously known as duniverse) to manage dependencies and it's working out pretty well for me. It vendors all dependencies into a node_modules-like directory inside the projects and writes an opam-compatible lockfile, and it builds all the dependencies using dune. For the most widely used packages that don't already use dune it uses an overlay containing dune ports at https://github.com/dune-universe/opam-overlays https://github.com/dune-universe/opam-overlays.
sausagefeet 4y ago
I have been an Ocaml user for a decade at this point and using Ocaml in the tech stack for the business I'm building. In my opinion: - Dependency management is not great in opam. I find it especially frustrating that the tried to be really clever with a SAT solver and it rarely does what I want it to do. That being said, I rarely run into issues with old builds of something failing. I only have a few projects on opam and I will get PRs for fixing my project to support later builds. The bigger issue, IMO, is there is no great way to mirror all the deps your project needs locally so you don't have to worry about them disappearing. - I have never run into the issue you've described here. In general, a package on opam just builds. I rarely have to modify an existing package, but when I do it has not been an issue. - Error messages aren't great, but I have never really hit this Syntax Error problem you run into (maybe you are one of those people that uses ";;"?). Error messages have also improved a lot over the last few versions, even around polymorphic variants, which has been a much welcomed improvement. - Documentation of third party libraries is unequally distributed. I find the language and std lib well documented, but for a library it depends. There is lots of room for improvement here. But on the flip side: I've run into plenty of libraries in Rust with bad documentation as well. - I think this comment on modules is a big unfair. Modules were never designed to solve the problem of typeclasses or traits. As you mentioned, module implicits might allow modules to be used as a solution, though. But on the flip side, type classes and traits struggle to express what modules can express, and I dearly miss modules when I work in any other language. I agree: Ocaml is a very nice language.
- tremon 4y ago
  As someone who has dabbled in Ocaml but has more experience with Haskell typeclasses and Rust traits, is there a good primer on what Ocaml modules are and how they're supposed to be used? Just porting my previous assumptions on traits/typeclasses over to Ocaml hasn't led me to very satisfying results.
  - sausagefeet 4y ago
    I'm not aware of any particular document, know. I have just read the language spec for modules. I know that sounds scary but, IMO, it's very approachable. And then, I think you just need to play with it to get a feel for me. But maybe someone else has a better introduction. But I think typeclasses and traits are about polymorphism, and that isn't what modules are about, they are about encapsulating code. https://v2.ocaml.org/releases/4.14/htmlman/modtypes.html https://v2.ocaml.org/releases/4.14/htmlman/modtypes.html https://v2.ocaml.org/releases/4.14/htmlman/modules.html https://v2.ocaml.org/releases/4.14/htmlman/modules.html https://v2.ocaml.org/releases/4.14/htmlman/firstclassmodules.html https://v2.ocaml.org/releases/4.14/htmlman/firstclassmodules...
WastingMyTime89 4y ago
> More controversially, I think that modules are a worse solution in practice than typeclasses / traits. If by controversial, you mean wrong we are in agreement. Modules are both conceptually simpler and easier to use in practice. They also produce far better error messages. I personally find Ocaml tooling far better than Haskell. The debugger is a lot nicer. The compiler is considerably faster, doesn’t rely as much on extension and generally gives better error messages. VSCode integration does everything I want and is easy to install. For what it’s worth you are the first person I meet complaining about syntax error. What people complain about are type checking errors which are indeed hard to understand sometimes. Syntax errors are caught well by the parser which tells you exactly where they are. I don’t really understand what you are complaining about.
- xavxav 4y ago
  I'll try to find an example of the syntax error I was mentioning, but I regularly trip up the parser with dumb mistakes which cause it to give completely useless errors. > Syntax errors are caught well by the parser which tells you exactly where they are. They aren't necessarily caused where the actual error is, just wherever the parser gets stuck, and the error it produces is usually not reflective of the human thought process that went in, but rather the automata's state.
  - yawaramin 4y ago
    Would be interesting to see such an error, but also what's interesting to me is that you are regularly making 'dumb' syntax mistakes, which suggests to me that you're still in the learning process and that you'll internalize the syntax more fully and stop making those mistakes some time in the future.
    - xavxav 4y ago
      Not really, it's more that I regularly make typos in all forms of writing (even handwritten). It's not usually misspellings but rather whole lexemes that go missing or are swapped. fwiw, I TA a course taught (partially) in OCaml and work regularly with a large OCaml project as part of my thesis. Parser generator errors are just a personal pet peeve of mine, I grew up with (mega)parsec (Haskell), where decent errors are out-of-the-box and great ones are easy.
pbiggar 4y ago
While you're not wrong about docs, the new package documentation for every package in the ecosystem is pretty fantastic! https://www.ocaml.org/packages https://www.ocaml.org/packages

by xavxav 4y ago

steinuil 4y ago

Re: dependency management and build tooling: these days I'm using opam-monorepo (https://github.com/tarides/opam-monorepo https://github.com/tarides/opam-monorepo, previously known as duniverse) to manage dependencies and it's working out pretty well for me. It vendors all dependencies into a node_modules-like directory inside the projects and writes an opam-compatible lockfile, and it builds all the dependencies using dune. For the most widely used packages that don't already use dune it uses an overlay containing dune ports at https://github.com/dune-universe/opam-overlays https://github.com/dune-universe/opam-overlays.

sausagefeet 4y ago

I have been an Ocaml user for a decade at this point and using Ocaml in the tech stack for the business I'm building. In my opinion: - Dependency management is not great in opam. I find it especially frustrating that the tried to be really clever with a SAT solver and it rarely does what I want it to do. That being said, I rarely run into issues with old builds of something failing. I only have a few projects on opam and I will get PRs for fixing my project to support later builds. The bigger issue, IMO, is there is no great way to mirror all the deps your project needs locally so you don't have to worry about them disappearing. - I have never run into the issue you've described here. In general, a package on opam just builds. I rarely have to modify an existing package, but when I do it has not been an issue. - Error messages aren't great, but I have never really hit this Syntax Error problem you run into (maybe you are one of those people that uses ";;"?). Error messages have also improved a lot over the last few versions, even around polymorphic variants, which has been a much welcomed improvement. - Documentation of third party libraries is unequally distributed. I find the language and std lib well documented, but for a library it depends. There is lots of room for improvement here. But on the flip side: I've run into plenty of libraries in Rust with bad documentation as well. - I think this comment on modules is a big unfair. Modules were never designed to solve the problem of typeclasses or traits. As you mentioned, module implicits might allow modules to be used as a solution, though. But on the flip side, type classes and traits struggle to express what modules can express, and I dearly miss modules when I work in any other language. I agree: Ocaml is a very nice language.

tremon 4y ago
As someone who has dabbled in Ocaml but has more experience with Haskell typeclasses and Rust traits, is there a good primer on what Ocaml modules are and how they're supposed to be used? Just porting my previous assumptions on traits/typeclasses over to Ocaml hasn't led me to very satisfying results.
- sausagefeet 4y ago
  I'm not aware of any particular document, know. I have just read the language spec for modules. I know that sounds scary but, IMO, it's very approachable. And then, I think you just need to play with it to get a feel for me. But maybe someone else has a better introduction. But I think typeclasses and traits are about polymorphism, and that isn't what modules are about, they are about encapsulating code. https://v2.ocaml.org/releases/4.14/htmlman/modtypes.html https://v2.ocaml.org/releases/4.14/htmlman/modtypes.html https://v2.ocaml.org/releases/4.14/htmlman/modules.html https://v2.ocaml.org/releases/4.14/htmlman/modules.html https://v2.ocaml.org/releases/4.14/htmlman/firstclassmodules.html https://v2.ocaml.org/releases/4.14/htmlman/firstclassmodules...

WastingMyTime89 4y ago

> More controversially, I think that modules are a worse solution in practice than typeclasses / traits. If by controversial, you mean wrong we are in agreement. Modules are both conceptually simpler and easier to use in practice. They also produce far better error messages. I personally find Ocaml tooling far better than Haskell. The debugger is a lot nicer. The compiler is considerably faster, doesn’t rely as much on extension and generally gives better error messages. VSCode integration does everything I want and is easy to install. For what it’s worth you are the first person I meet complaining about syntax error. What people complain about are type checking errors which are indeed hard to understand sometimes. Syntax errors are caught well by the parser which tells you exactly where they are. I don’t really understand what you are complaining about.

xavxav 4y ago
I'll try to find an example of the syntax error I was mentioning, but I regularly trip up the parser with dumb mistakes which cause it to give completely useless errors. > Syntax errors are caught well by the parser which tells you exactly where they are. They aren't necessarily caused where the actual error is, just wherever the parser gets stuck, and the error it produces is usually not reflective of the human thought process that went in, but rather the automata's state.
- yawaramin 4y ago
  Would be interesting to see such an error, but also what's interesting to me is that you are regularly making 'dumb' syntax mistakes, which suggests to me that you're still in the learning process and that you'll internalize the syntax more fully and stop making those mistakes some time in the future.
  - xavxav 4y ago
    Not really, it's more that I regularly make typos in all forms of writing (even handwritten). It's not usually misspellings but rather whole lexemes that go missing or are swapped. fwiw, I TA a course taught (partially) in OCaml and work regularly with a large OCaml project as part of my thesis. Parser generator errors are just a personal pet peeve of mine, I grew up with (mega)parsec (Haskell), where decent errors are out-of-the-box and great ones are easy.

pbiggar 4y ago

While you're not wrong about docs, the new package documentation for every package in the ecosystem is pretty fantastic! https://www.ocaml.org/packages https://www.ocaml.org/packages