Sorry could you explain your comment some more? Genuinely curious what is bad about dune. Just started using it
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.
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.
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
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.
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 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-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 :-)
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.