5 ms·

The design of OCaml/Reason is the sweet spot of functional programming for me but every time I must deal with Dune after working with the tooling of Go or Rust

The design of OCaml/Reason is the sweet spot of functional programming for me but every time I must deal with Dune after working with the tooling of Go or Rust I want to stab myself in the face repeatedly and I think that maybe that might just be related to the general concept of "masses" + OCaml.

rashkov 4y ago
Sorry could you explain your comment some more? Genuinely curious what is bad about dune. Just started using it
- pkilgore 4y ago
  We can start with that, upon starting down the road to learning a (IMO great) but very, very different syntax than most other languages in OCaml, Dune then asks you to write a lisp file to do basic configuration and I suspect 90%+ people who want to explore just say "fuck it" the second they internalize this. I'm sure there's a crowd, especially here on HN, that views this as some sort of purity test for the language, but in my opinion it's needlessly obtuse over <insert more readable and traditional and lintable type here> used by modern build systems. Then there's the fact that several `init` commands don't actually fully `init` a project (and up until recently, the very example in OCaml's getting started documentation was broken). Then there's this insanity dune build dune test dune exec # hahaha no, no, this doesn't work. Then you gotta manually tape together crap between opam and dune (and don't get me started on how insane the lockfile situation is -- I swear to god I complained once and someone told me I should learn to use nix!). This is all very fun and yak shave-ey and I generally grin and bear it, but boy do I totally get why most people look at me like I'm a weirdo because I like this language.
  - cemerick 4y ago
    I think there's a lot of strawmen here, many quite analogous to those used to (unfairly IMO) criticize OCaml itself. Complaining about sexprs, when one's baseline is the completely ad-hoc nature of go.mod files, or cargo toml files, is pretty silly. Further, sexprs are a very common general-purpose serialization path for OCaml values, so dune's selection here is hardly arbitrary. Yes, `dune build`, `dune runtest`, and `dune exec ...` do "work", i.e. each command has its semantics, which are pretty extensively documented IMO. Is the complaint that they're not the same commands that one uses with cargo or whatever? You're right that opam and dune used to not interoperate much (or at all), but that has changed a lot in the last year or so, to the point that, _if you want_, you don't have to write opam files at all (i.e. they'll be generated from metadata in your `dune-project` file). Again, well documented, at least IMO: https://dune.readthedocs.io/en/stable/opam.html https://dune.readthedocs.io/en/stable/opam.html The "lockfile situation" is pretty good AFAICT. I've been using them for a year+ with good / expected results. You're right about `dune init` not doing the right things. I believe that's been resolved very recently IIRC, but then again, I can't recall the last language/build tool I used init-like functionality with; I almost always just copy over config/structure from another project I've worked on, and tweak from there. There are absolutely real critiques of dune, but "it's not cargo" or whatever is silly.
    - yawaramin 4y ago
      Hmm, let's dive a little deeper. Dune itself is fine, and even great once everything is working. It's just that you have to mug through tons of documentation that's arranged in pure reference format, instead of in a task-based format, before it's up and running. Sure, dune generates opam files...except for the (some pretty important) parts it doesn't support. I've had to fall back to opam template files in two different projects to express things that dune-project format doesn't support. It's a leaky abstraction over opam format. The lockfile situation is incredibly rudimentary compared to Go or even to npm. Check out https://go.dev/blog/supply-chain https://go.dev/blog/supply-chain and tell me opam has 1/5th of the capabilities of go.sum checksums and their overall supply chain security. I know this was a concern for you pretty recently: https://discuss.ocaml.org/t/opam-repository-security-and-data-integrity-posture/6478 https://discuss.ocaml.org/t/opam-repository-security-and-dat... Dune init is actually the one really good piece of UX in dune. Being able to run a command and generate a valid dune component (e.g. not having to remember the `(preprocess (pps ppx_bla))` dance and just being able to do `dune init --ppx=ppx_bla` is pretty cool. I feel like 'I just endlessly copy configs from other places' is not really a point of pride. It reminds me of the bad old days of init shell scripts before systemd :-)
    - pkilgore 4y ago
      I'm trying not to make this just about dune. Dune is curtainly BETTER than, say Make n friend to newcomers. But there's a market for programming languages that OCaml is objectively losing. Can we really not agree that the most popular/recommended build tool requiring you to write a lisp to do basic config probably isn't helping draw new user into the fold? I doesn't have to be cargo. But the more it rhymes with that degree of user experience, the more the "masses" will discover the things that make ocaml great.
      - sweeneyrod 4y ago
        I agree that dune is worse in many important ways than the build systems of languages like Rust and Go (where they were developed at the same time as the language, rather than 20 years later). But dune config files aren't lisp. They're s-expressions, which have the same syntax as lisp but are just static data like json/yaml/toml (and once you get used to them, I think most people prefer them to those).
  - dunefox 4y ago
    A couple of years ago I gave myself two evenings to setup and start to learn Ocaml. I gave up due to the tooling. Nothing worked, many things weren't obvious or explained. This is much better with Haskell, Rust, F#, ...
Zababa 4y ago
Dune is a great "window" in my experience with OCaml, it forces you to do more than with every other language but you end up with a better understanding of everything.
- pkilgore 4y ago
  This is fair. It's also a reason the "masses" are going to pick up Go or Rust instead.
  - Zababa 4y ago
    That's how I think things will go too. I really enjoy the time I spend with OCaml but whenever I need to do something I use JS because it gives me the frustration in lower doses if that makes sense. I learn less but sometimes I don't want to learn, I want to do.
  - LAC-Tech 4y ago
    Rust has a larger ecosystem, but it's not even on the same planet as ocaml in terms of expressiveness. Kind of disappointed facebook didn't run with ocaml, instead of doing the whole Reason thing. They could have been contributing to and using ocaml directly, instead they decided that programmers will freak out if there's no curly braces.
    - dunefox 4y ago
      > but it's not even on the same planet as ocaml in terms of expressiveness. It's also not on the same planet with tooling pain points.
      - LAC-Tech 4y ago
        I think it is on the same planet. Maybe not wrt ecosystem, but apart from rust having a testing built into the language I find them both about the same.
- baby 4y ago
LAC-Tech 4y ago
What's wrong with dune? I thought it was really good.
- baby 4y ago
  Horrible doc, the configuration files are a made-up language with no extension, it is completely detached from managing the versions of your dependencies, or their source of origin (package manager? vendored? patched? internal?), horrible CLI, transitive dependencies are imported by default and it's hard to not do that, etc. And then you try to use it in combination with opam and you want to blow your head.
  - LAC-Tech 4y ago
    - thought the docs were good. Same level as cargo or npm or anything else I've used. - the 'made up langauge' is just s-expressions, not any more made up than NPM using a json file. There's no standard file extension for them though, which is fair. - I'll take your word on the rest of them, I didn't do anything heavy duty
    - baby 4y ago
      > - I'll take your word on the rest of them, I didn't do anything heavy duty TBH, that's why you thought the docs were good > - the 'made up langauge' is just s-expressions, not any more made up than NPM using a json file. There's no standard file extension for them though, which is fair. The lack of extension is really the problem, as your editor will not format it or add syntax highlighting. It's very 90's
- yawaramin 4y ago
  detailed answer upthread https://news.ycombinator.com/item?id=31278948 https://news.ycombinator.com/item?id=31278948
- whb07 4y ago
  I concur as well that Dune is lacking. Compared to Rust or NPM. Shoot even dotnet/nugget is significantly ahead of Dune.
_benj 4y ago
I haven't spent enough time with dune to form an opinion (go and cargo are absolutely marvelous though) but a quick search[0] reveals that dune is not the only option. [0] <https://github.com/ocaml-community/awesome-ocaml#package-management https://github.com/ocaml-community/awesome-ocaml#package-man...>
- yawaramin 4y ago
  The better place to get tooling info is the OCaml Platform page: https://ocaml.org/docs/platform https://ocaml.org/docs/platform There you can see that dune is the only actively maintained viable build system for OCaml. The others are all in maintenance mode or deprecated.

rashkov 4y ago

Sorry could you explain your comment some more? Genuinely curious what is bad about dune. Just started using it

pkilgore 4y ago
We can start with that, upon starting down the road to learning a (IMO great) but very, very different syntax than most other languages in OCaml, Dune then asks you to write a lisp file to do basic configuration and I suspect 90%+ people who want to explore just say "fuck it" the second they internalize this. I'm sure there's a crowd, especially here on HN, that views this as some sort of purity test for the language, but in my opinion it's needlessly obtuse over <insert more readable and traditional and lintable type here> used by modern build systems. Then there's the fact that several `init` commands don't actually fully `init` a project (and up until recently, the very example in OCaml's getting started documentation was broken). Then there's this insanity dune build dune test dune exec # hahaha no, no, this doesn't work. Then you gotta manually tape together crap between opam and dune (and don't get me started on how insane the lockfile situation is -- I swear to god I complained once and someone told me I should learn to use nix!). This is all very fun and yak shave-ey and I generally grin and bear it, but boy do I totally get why most people look at me like I'm a weirdo because I like this language.
- cemerick 4y ago
  I think there's a lot of strawmen here, many quite analogous to those used to (unfairly IMO) criticize OCaml itself. Complaining about sexprs, when one's baseline is the completely ad-hoc nature of go.mod files, or cargo toml files, is pretty silly. Further, sexprs are a very common general-purpose serialization path for OCaml values, so dune's selection here is hardly arbitrary. Yes, `dune build`, `dune runtest`, and `dune exec ...` do "work", i.e. each command has its semantics, which are pretty extensively documented IMO. Is the complaint that they're not the same commands that one uses with cargo or whatever? You're right that opam and dune used to not interoperate much (or at all), but that has changed a lot in the last year or so, to the point that, _if you want_, you don't have to write opam files at all (i.e. they'll be generated from metadata in your `dune-project` file). Again, well documented, at least IMO: https://dune.readthedocs.io/en/stable/opam.html https://dune.readthedocs.io/en/stable/opam.html The "lockfile situation" is pretty good AFAICT. I've been using them for a year+ with good / expected results. You're right about `dune init` not doing the right things. I believe that's been resolved very recently IIRC, but then again, I can't recall the last language/build tool I used init-like functionality with; I almost always just copy over config/structure from another project I've worked on, and tweak from there. There are absolutely real critiques of dune, but "it's not cargo" or whatever is silly.
  - yawaramin 4y ago
    Hmm, let's dive a little deeper. Dune itself is fine, and even great once everything is working. It's just that you have to mug through tons of documentation that's arranged in pure reference format, instead of in a task-based format, before it's up and running. Sure, dune generates opam files...except for the (some pretty important) parts it doesn't support. I've had to fall back to opam template files in two different projects to express things that dune-project format doesn't support. It's a leaky abstraction over opam format. The lockfile situation is incredibly rudimentary compared to Go or even to npm. Check out https://go.dev/blog/supply-chain https://go.dev/blog/supply-chain and tell me opam has 1/5th of the capabilities of go.sum checksums and their overall supply chain security. I know this was a concern for you pretty recently: https://discuss.ocaml.org/t/opam-repository-security-and-data-integrity-posture/6478 https://discuss.ocaml.org/t/opam-repository-security-and-dat... Dune init is actually the one really good piece of UX in dune. Being able to run a command and generate a valid dune component (e.g. not having to remember the `(preprocess (pps ppx_bla))` dance and just being able to do `dune init --ppx=ppx_bla` is pretty cool. I feel like 'I just endlessly copy configs from other places' is not really a point of pride. It reminds me of the bad old days of init shell scripts before systemd :-)
  - pkilgore 4y ago
    I'm trying not to make this just about dune. Dune is curtainly BETTER than, say Make n friend to newcomers. But there's a market for programming languages that OCaml is objectively losing. Can we really not agree that the most popular/recommended build tool requiring you to write a lisp to do basic config probably isn't helping draw new user into the fold? I doesn't have to be cargo. But the more it rhymes with that degree of user experience, the more the "masses" will discover the things that make ocaml great.
    - sweeneyrod 4y ago
      I agree that dune is worse in many important ways than the build systems of languages like Rust and Go (where they were developed at the same time as the language, rather than 20 years later). But dune config files aren't lisp. They're s-expressions, which have the same syntax as lisp but are just static data like json/yaml/toml (and once you get used to them, I think most people prefer them to those).
- dunefox 4y ago
  A couple of years ago I gave myself two evenings to setup and start to learn Ocaml. I gave up due to the tooling. Nothing worked, many things weren't obvious or explained. This is much better with Haskell, Rust, F#, ...

Zababa 4y ago

Dune is a great "window" in my experience with OCaml, it forces you to do more than with every other language but you end up with a better understanding of everything.

pkilgore 4y ago
This is fair. It's also a reason the "masses" are going to pick up Go or Rust instead.
- Zababa 4y ago
  That's how I think things will go too. I really enjoy the time I spend with OCaml but whenever I need to do something I use JS because it gives me the frustration in lower doses if that makes sense. I learn less but sometimes I don't want to learn, I want to do.
- LAC-Tech 4y ago
  Rust has a larger ecosystem, but it's not even on the same planet as ocaml in terms of expressiveness. Kind of disappointed facebook didn't run with ocaml, instead of doing the whole Reason thing. They could have been contributing to and using ocaml directly, instead they decided that programmers will freak out if there's no curly braces.
  - dunefox 4y ago
    > but it's not even on the same planet as ocaml in terms of expressiveness. It's also not on the same planet with tooling pain points.
    - LAC-Tech 4y ago
      I think it is on the same planet. Maybe not wrt ecosystem, but apart from rust having a testing built into the language I find them both about the same.
baby 4y ago

LAC-Tech 4y ago

What's wrong with dune? I thought it was really good.

baby 4y ago
Horrible doc, the configuration files are a made-up language with no extension, it is completely detached from managing the versions of your dependencies, or their source of origin (package manager? vendored? patched? internal?), horrible CLI, transitive dependencies are imported by default and it's hard to not do that, etc. And then you try to use it in combination with opam and you want to blow your head.
- LAC-Tech 4y ago
  - thought the docs were good. Same level as cargo or npm or anything else I've used. - the 'made up langauge' is just s-expressions, not any more made up than NPM using a json file. There's no standard file extension for them though, which is fair. - I'll take your word on the rest of them, I didn't do anything heavy duty
  - baby 4y ago
    > - I'll take your word on the rest of them, I didn't do anything heavy duty TBH, that's why you thought the docs were good > - the 'made up langauge' is just s-expressions, not any more made up than NPM using a json file. There's no standard file extension for them though, which is fair. The lack of extension is really the problem, as your editor will not format it or add syntax highlighting. It's very 90's
yawaramin 4y ago
detailed answer upthread https://news.ycombinator.com/item?id=31278948 https://news.ycombinator.com/item?id=31278948
whb07 4y ago
I concur as well that Dune is lacking. Compared to Rust or NPM. Shoot even dotnet/nugget is significantly ahead of Dune.

_benj 4y ago

I haven't spent enough time with dune to form an opinion (go and cargo are absolutely marvelous though) but a quick search[0] reveals that dune is not the only option. [0] <https://github.com/ocaml-community/awesome-ocaml#package-management https://github.com/ocaml-community/awesome-ocaml#package-man...>

yawaramin 4y ago
The better place to get tooling info is the OCaml Platform page: https://ocaml.org/docs/platform https://ocaml.org/docs/platform There you can see that dune is the only actively maintained viable build system for OCaml. The others are all in maintenance mode or deprecated.