RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
60% Positive
Analyzed from 1077 words in the discussion.
Trending Topics
#dune#ocaml#build#language#system#projects#more#need#https#package

Discussion (31 Comments)Read Original on HackerNews
There's a handful of mix commands you learn when you get started and it's such a great experience. You can crack open erlang application structure and learn more if you want, but if you just want to `mix compile` `mix deps.get` `mix test` that's also fine.
When I first learned ocaml I watched this really wonderful series https://www.youtube.com/watch?v=MUcka_SvhLw&list=PLre5AT9JnK... (highly recommend if you are at all interested) and it's great for learning the language and tooling but it's all opam up until the end when some of it switches to dune.
I think wanting to provide more details about what's going on is nice too, but I think there's a place for "here's the commands you will actually need in your day to day"
[1] https://github.com/ocaml/ocamlbuild/blob/master/manual/manua...
That specific combination (ocaml + mingw) has a known problem with ocamlfind that's still awaiting a new release (see https://github.com/ocaml/ocamlfind/pull/112). ocamlfind underpins quite a bit of the package ecosystem, so this one is annoying, as the mingw workflow is otherwise quite good.
https://github.com/dharmatech/ocaml
Superficially, both uv and dune are also project runners. But dune is mainly a build tool, most important things dune does such as pre-processing, linking, compiling etc., are not needed in python in the first place (at least talking about pure python). You can use uv to create tarball/wheel but it's more akin to simple bundling than building in the dune sense. Dune can also run tests, but in uv you would need to delegate to something like pytest etc.
^1: https://dune.readthedocs.io/en/stable/tutorials/dune-package...
Maybe this introduction will finally do the trick.
So in the end I tried using dune and opam and whatnot, but it all felt less than clear to me. Especially, the comment someone else made here about having 2 different types of files for dune to work ...
I just want a project local directory, that contains all my dependencies and a lock file to reproducibly built my projects. That's the minimum I expect these days. Or some equivalent alternative.
The closest we have right now are build systems in the Bazel / Buck2 lineage.
It's neither of those unless you limit yourself to a lowest-common-denominator feature set. GNU Make, for example, is a Turing-complete, dynamic programming language and a CLI task runner. You can build a build system in GNU Make (https://github.com/omercsp/simple-build-system) just like you can do so in any other language.
Make suffers from unfamiliar and somewhat unorthodox syntax, and inconsistent language design. So it's not a good language, and saying it "sucks" is not completely unjustified, but not because it's limited. Looking at SBS, it also seems quite expressive, although I can't say I ever tried building something in it myself.
You just answered the question "why does every language need to re invent packaging, building, etc." Because people don't want to build build systems in Make