01:19 <discocaml> <diligentclerk> I haven't really read too many conversations online where people talk about tooling in a way that's really specific and actionable. People usually just say "I had a good experience with it" or "it sucks."

01:20 <discocaml> <diligentclerk> I would love to read a clear technical argument for why Go's tooling facilitated its rapid growth.

01:22 <discocaml> <diligentclerk> Are there good user experience study papers where they interview programmers or monitor them to see how they use their tooling?

01:24 <discocaml> <diligentclerk> or even just a blog post where somebody argues "these are the top 15 features that need to be implemented in tooling for a language before you can expect people to use it"

01:24 <discocaml> <yawaramin> cross-platform lockfiles?

01:24 <discocaml> <yawaramin> fast installs

01:25 <discocaml> <yawaramin> using native Windows tooling on Window

01:25 <discocaml> <yawaramin> using native Windows tooling on Windows

02:10 <discocaml> <contificate> All this tooling stuff comes down to the fact that most developers don't RTFM. I'm always surprised at the amount of things I learn about tools I've used for years if I glance over the manual.

02:12 <discocaml> <contificate> I'd hazard a guess that the general competence level among employed software engineers with, say, git is fairly low (for example).

02:13 <discocaml> <contificate> However, you are immediately more competent with git if you know how it works (even if you don't know the 2-8 subcommands that achieve the same thing). People don't know the aforementioned `dune` stuff that I think is important, and that probably makes it feel like like flailing around with opaque S-expr nonsense to most beginners.

02:16 <discocaml> <yawaramin> no but seriously, faster installs would be great. creating and installing packages in an opam switch is pretty painful

02:17 <discocaml> <yawaramin> admittedly i haven't tried the new dune package management yet

02:18 <discocaml> <contificate> when relocatable compiler eta

02:19 <discocaml> <contificate> my understanding is that OCaml's compiler couldn't really be moved around the file system after being built

02:23 <discocaml> <yawaramin> i've heard some noises that it's close

02:48 <discocaml> <dubious245> I mean there is enough stuff under the sun that already has to be learned. Making a build system a big part of what you have to learn to start using a programming language definitely increases that burden enough I can see people bouncing off the language.

02:50 <discocaml> <dubious245> So to start doing stuff in Ocaml for an average dev they need to learn a new non-c syntax, plus ocaml, plus the domain they are trying to implement, and them on top of that you add Dune.

03:06 <jutty> I think Dune could be simpler. And have some defaults where projects could omit trivial dune files. But binary package management aside, I just want defining custom commands in Dune to be easier. Usually OCaml projects have a Makefile with a bunch of phony targets just to ship project-related commands.

03:28 <companion_cube> if it were simpler, at the cost of not working for existing OCaml projects, it'd be dead

03:28 <companion_cube> begin flexible enough to work in a variety of situations is necessary when you're working with an already existing ecosystem

04:14 <Guest1> Does the dune repository itself support incremental building? I'm trying to make some changes and recompiling, but every time I type `make release` or `make dev` it restarts with progress 0/1530. I would have expected it to just recompile the 3-4 changed files and link them.

04:27 <discocaml> <barconstruction> What is a lock file? Is it equivalent to like, a specific set of dependencies and version numbers that guarantees a reproducible build?

06:35 <discocaml> <bluddy5> I think discussions about dune's syntax in terms of simplification and commands are mostly moot at this point. The reality is that everyone comes in with an AI assistant or two. For example, while getting systems configuration stuff done in linux used to be a pain, it's now much easier due to the fact that I can just ask chatgpt how to do it. Suddenly linux is a power-tool platform for *everyone*, and truly exceeds what windows can do. The sam

13:02 <companion_cube> @barconstruction yes, normally a lockfile contains the whole set of (transitive) dependencies with their versions, and typically their hash

15:01 <discocaml> <yawaramin> see also https://go.dev/ref/mod#go-sum-files

15:17 <companion_cube> or just cargo lockfiles really

15:46 <discocaml> <contificate> all I'll say is using dune is much easier than using the toolchain directly

15:47 <discocaml> <contificate> in fact, I only know how to use the toolchain directly from using `dune --verbose`

15:52 <discocaml> <cod1r> i like dune too

15:52 <discocaml> <cod1r> me and my homies are dune lovers

15:54 <discocaml> <contificate> need more OCaml tutorials on YouTube - workflows and the like

15:54 <discocaml> <contificate> can only get so far with Twitch grifters having their mouth agape at the concept of passing a function to another function

18:00 <discocaml> <gabyfle> Hello ! I was wondering, design wise, when do you use Modules and when do you use Classes ?

18:01 <discocaml> <gabyfle> I'm currently implementing digital filters and I think that both modules (with functors) and classes (with inheritance) would fit the case

18:01 <discocaml> <gabyfle> And since I have both options I'm unsure of what to choose

18:06 <discocaml> <gabyfle> <https://discuss.ocaml.org/t/objects-use-cases-in-ocaml/2282/15> seems to lead to a "not use objects" principle but I'm wondering if things changed over the years (the discussion is 7 years old)

18:51 <discocaml> <cod1r> i used to be that twitch grifter ngl 🤣

18:51 <discocaml> <cod1r> WOAH, HIGHER ORDER FUNCTIONS?!?!?!?!? 😱