05:32 <discocaml> <shalokshalom> Exactly. I guess caching is a thing, C++ has distributed caching with sscache, I guess Rust and Swift might have too?

05:34 <discocaml> <aurelian5014> I use ccache with rust

09:42 <discocaml> <eval.apply> https://ocaml.org/manual/5.3/api/Dynlink.html

13:34 <discocaml> <asadun5771> i really want to like OCAML, but maaaan some of the minute stuff really puts me off

13:34 <discocaml> <asadun5771> the variable shadowing, the lack of braces (or at least pretend to look imperative), the `=` operator having multiple meanings

13:34 <discocaml> <asadun5771> i guess i am going to have to keep looking or write my own 😭

13:35 <discocaml> <asadun5771> what i love: type inference, GC, REPL support, not sure what i think about modules...

13:37 <discocaml> <asadun5771> i like Rust but it is a very, very ambitious project and very big language as well ( i never really understood async) and the compile time is coutner productive at times

15:04 <discocaml> <noahtheduke> thanks!

15:21 <discocaml> <froyo> Rust is following OCaml's school of thought in lexical conventions though. Shadowing is allowed everywhere. For braces, anywhere you want to introduce a block, you could just use `( ... )` or `begin ... end`.

15:25 <discocaml> <noahtheduke> it's a bummer ocaml can't access variables defined in dynamically loaded modules

15:25 <discocaml> <froyo> `(<>)`, `(=)` operators have only one meaning in stdlib, structural (in)equality (respectively). You're free to redefine them or to redefine`(==)` and `(!=)` if you wish to use more conventional syntax. Although I personally discourage both actions because it breaks assumptions the readers of your code might have when they look at an operator conventionally used for something else. though I do agree it can be a little confusing at first the fact

15:31 <discocaml> <jaydub3621> If you want an ocaml-like language that is smaller and more of a Rust syntax, take a look at Gleam

15:31 <discocaml> <froyo> you could always just avoid using an operator altogether and instead opt for `Mod.equal`

15:32 <discocaml> <froyo> (it's better anyway because structural equality has a gotcha when two different structures could mean the same thing in an equality relation, e.g. sets)

15:34 <discocaml> <yawaramin> you can, see https://x.com/_anmonteiro/status/1761307756315730317

15:38 <discocaml> <yawaramin> you can adapt that to have some other desired properties eg multicore thread safety by using an Eio promise to hold the 'plugin' instead of using a ref

15:54 <discocaml> <noahtheduke> that's interesting

15:55 <discocaml> <froyo> > it's a bummer ocaml can't access variables defined in dynamically loaded modules

15:55 <discocaml> <froyo> wdym by "variables"? refs? both refs and normal bindings can be read from plugins

15:56 <discocaml> <noahtheduke> i love clojure and love how clojure can just load a given file and access whatever is inside, because clojure's top level bindings attach to the namespace and the namespaces are tracked globally

15:57 <discocaml> <noahtheduke> i've been wondering if that's possible in ocaml, as it would simplify finding tests in testo or equivalent

15:57 <discocaml> <noahtheduke> finding and running tests, i mean

16:43 <discocaml> <yawaramin> test discovery seems like a solution in search of a problem to me. we can easily have an API like `suite "Addition" [case "positive number" (fun ctx -> ...); case ...;...]` and so on where the suite is packaged together with all its tests so there's nothing to 'find'

16:47 <discocaml> <yawaramin> or rather `let () = suite ...` ie `suite` is the 'test runner'. declaring the module as a `test` component in the `dune` file is enough to tell dune where to find all the test suites anyway so...

16:59 <discocaml> <noahtheduke> if a test has to be manually included in a call to a test running function, then it's possible for it to be missed and not run (i've done this). if a file has to be included in a list of files to be run, then it's possible for it to be missed and not run (i've done this).

17:09 <discocaml> <yawaramin> yeah that's why i'm saying we can just define the test inline, we don't have to define it separately and then include it in the list manually just because the examples show that

17:10 <discocaml> <yawaramin> if test files are defined in dune `(test ...)` stanzas, dune will automatically run them when running the `dune test` command. no need to include files in a list

17:13 <discocaml> <yawaramin> eg in a traditional Python test suite, the definition is a class named `SomethingTest` and the cases are methods named `testFoo()` and so on. would you just 'forget' to include a test case in such a suite? no, because you're defining them all inline

17:59 <discocaml> <noahtheduke> right

18:01 <discocaml> <noahtheduke> but with pytest you can just say "pytest" and it'll discover the right files to execute

18:55 <discocaml> <yawaramin> fair point, in dune you need to declare each test in its stanza. so i guess it's possible to forget to declare it