g0d_shatter has quit [Remote host closed the connection]
ArthurStrong has quit [Quit: leaving]
ArthurStrong has joined #ocaml
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
nullifidian_ has joined #ocaml
nullifidian__ has quit [Read error: Connection reset by peer]
<sarna>
Leonidas: replying late, but what would you recommend for a beginner? picking one, or learning both?
mbuf has quit [Ping timeout: 265 seconds]
mbuf has joined #ocaml
lix has joined #ocaml
clockish has quit [Quit: bye]
clockish has joined #ocaml
wingsorc has quit [Ping timeout: 248 seconds]
zmt01 has joined #ocaml
zmt00 has quit [Ping timeout: 260 seconds]
dreadedfrog has joined #ocaml
ArthurStrong has quit [Quit: leaving]
mbuf has quit [Quit: Leaving]
flodin has joined #ocaml
dreadedfrog has quit [Ping timeout: 268 seconds]
bartholin has quit [Quit: Leaving]
Wojciech_K has joined #ocaml
ziyourenxiang has quit [Quit: Leaving]
<Leonidas>
sarna: sorry, what was the context? Async vs Lwt or something else?
<sarna>
Leonidas: yeah, async vs lwt
<sarna>
and I'm still confused about standard libraries :)
<Leonidas>
sarna: I mean, if you learn one you get essentially the other one for free
<Leonidas>
sarna: I find Async a bit "cleaner" and it is also explained in RWO
<sarna>
Leonidas: so they're that similar.. but not *that* similar? lol
<sarna>
Leonidas: also Async doesn't work on mirage iirc?
<Leonidas>
sarna: the base case pretty much is: a >>= fun result -> return result
<Leonidas>
sarna: no, it doesn't
<sarna>
Leonidas: I see
<Leonidas>
sarna: Async has IMHO way better support for failures
<Leonidas>
and it is a bit more explicit about Deferred vs Results, whereas Lwt.t is both a resolved promise and a result type
<Leonidas>
(that means you can fail a promise in lwt, but not in async)
<Leonidas>
Personally I find Async's monitors a bit nicer to work with and I prefer ppx_let to ppx_lwt for being a more generic solution
<companion_cube>
I'd say, learn lwt, it's the one the community outside of Janestreet favors ;)
<Leonidas>
companion_cube: FOSS sure, proprietary not so sure
<companion_cube>
indeed
<companion_cube>
(although I don't know much about proprietary OCaml outside my own company)
<Leonidas>
Jane Street, Arena and Issuu all use Async
<companion_cube>
I don't think lexifi does, they're on windows; and we don't either :)
<companion_cube>
besport uses eliom I think
<Leonidas>
As far as I remember Async works on Windows
<companion_cube>
ah, my bad
<Leonidas>
(that said, probably noone at JS really cares, so it might as well be quite wonky)
<sarna>
625 downloads for Async in the last month, almost 2000 for Lwt, hmm
<Leonidas>
But OCaml and Windows is generally a rather tricky situation
<Leonidas>
I started with Lwt, fwiw
<Leonidas>
and not I am angry at Lwt_pool or Lwt.async and all of this :D
<companion_cube>
are you sure about the "not" ? :D
<Leonidas>
That said, the new maintainer of Lwt does a terrific job within the constraints of API compatibility, so I am very impressed about that
<Leonidas>
companion_cube: *now
<sarna>
but if I make a very nice library and then will have to use one that uses the other type of async.. I'm screwed?
<companion_cube>
what's wrong with Lwt.async or Lwt_pool?
<Leonidas>
companion_cube: Lwt_pool uses a shared pool so if some of your dependencies uses it (which you might not know) and you use it, you might run out of threads just because
<Leonidas>
and then you just have to tweak a random number to increase the amount of threads in a pool
<companion_cube>
m'kay :D
<Leonidas>
totally breaking composability
<companion_cube>
what about Lwt.async then?
<Leonidas>
it just blocks? that's like the unsafePerformIO of Lwt.
<companion_cube>
wut, it doesn't block at all tho
<Leonidas>
well, it eliminates the promise for it to do *something*
<Leonidas>
I think making promises "go away" is convenient but if you need that it feels like you're doing something wrong
<companion_cube>
ah, I find it quite convenient personally
<companion_cube>
for background stuff, for example
<companion_cube>
btw, for Lwt_pool, were you talking about Lwt_preemptive?
<Leonidas>
in any case, both Lwt and Async are vastly preferable to Python3 async
<companion_cube>
threads are ok too ;)
<Leonidas>
companion_cube: oh, yes, you might be right!
<companion_cube>
there's a lib that improves on lwt_preemptive
<companion_cube>
meanwhile, async pulls so much stuff that I feel like using it would be like asking for a banana, but getting the gorilla that holds it and the whole forest around 🙃
<sarna>
eh, I wanted to learn a language that would roughly be rust with gc by default, for personal projects. I narrowed it down to D vs OCaml - and I'd love to pick OCaml honestly, but the ecosystem split is making me anxious :(
<Leonidas>
yeah, though if you use core, then it makes very little of a difference
<companion_cube>
sarna: have you looked at nim or crystal?
<companion_cube>
ahah yeah you already got the whole forest
<sarna>
companion_cube: too niche in my opinion, and they don't offer me anything over D
<sarna>
OCaml offers better FP support
<Leonidas>
in any case, I think Lwts choices are often defensible by stating it was dimenix first async library, whereas Async was his second and dune his third :D
<companion_cube>
well, nim is clearly more modern than D
<companion_cube>
😂
<companion_cube>
reinventing one's own wheel
<Leonidas>
I really enjoyed the D book, despite never actually using D afterwards
<sarna>
in which aspect? by allowing_all casingSystems possible?
<companion_cube>
ah yeah, that's the ugly part
<companion_cube>
but it's expression based and doesn't look like C+++
<sarna>
"we have 5 standard libraries, let's make another one"
<companion_cube>
🤷
<companion_cube>
well, got to catch my flight
mbuf has joined #ocaml
<Leonidas>
sarna: no, I think this just replicates the API of Core on all platforms/standard libraries
<Leonidas>
companion_cube: have a good flight!
<sarna>
I don't know any language other than rust that'd have traits
<Leonidas>
sarna: Scala
<sarna>
companion_cube: enjoy your flight!
<Leonidas>
at least the name. When I looked at traits in Rust it sorta looked like typeclasses, as in Haskell
<sarna>
Leonidas: yeah, but it's incomplete and takes APIs from Elm.. why?
mbuf has quit [Remote host closed the connection]
<Leonidas>
sarna: of course it will be incomplete because Core is massive and everchanging
dreadedfrog has joined #ocaml
<sarna>
I've only seen rust-like traits in inko
<Leonidas>
> Many OCaml libraries have APIs optimized for pipelast (|>), while Belt aims for pipefirst (|.).
<sarna>
from some scala blogger: "Adding functionality by using Rust’s traits should be familiar territory if you’ve written typeclass-like stuff in Scala. In fact, Rust’s trait system feels a lot more similar to Haskell’s typeclass system than Scala’s, something which has its pros and cons (no scoping of implementations for a given type, for
<sarna>
example). "
mbuf has joined #ocaml
<Leonidas>
wow, pipefirst in OCaml sounds like a bad idea
<Leonidas>
sarna: yeah, that's why I wrote that it reminded me of typeclasses
<Armael>
what's pipefirst
<sarna>
Leonidas: yeah they're quite similar, don't know if they're the same though - I don't know enough :)
<Leonidas>
though it turns out that typeclasses are at least somewhat controversial even in Haskell
<Leonidas>
Armael: when your funtions take the thing they operate on as first instead of last argument
<Armael>
how do you chain stuff then
<Leonidas>
then you can't use currying to just get a unary function and pipe with |> but you have to use (|.) to essentially chain
<sarna>
I value rich type systems, compiling to a single binary, good performance without long pauses, good async/concurrency story'
<Armael>
(mfw they changed the css to an even more unreadable one)
<Leonidas>
yeah, not a fan
<sarna>
what are the giant blocks of nothing on this page for O.o
Serpent7776 has joined #ocaml
<Leonidas>
at least you can find things, unlike the Core docs where it requires skill to find where things actually are :/
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
nullifidian__ has joined #ocaml
<sarna>
core docs are terrible, I couldn't find anything :/
<Leonidas>
you haven't ascended yet :p
<Leonidas>
I can find things, but only because after years I know how to jump through the right hoops :D
nullifidian_ has quit [Ping timeout: 260 seconds]
<sarna>
:/
<sarna>
companion_cube: Nim has UB, so that's a no-go
<Leonidas>
~Obj.magic~ :p
mbuf has quit [Remote host closed the connection]
<sarna>
yeah, but you can at least grep for Obj.magic or unsafe
<sarna>
you can't grep for blindly dereferencing null pointers
<Leonidas>
yes, this was more tongue-in-cheek than an actual counterpoint
mbuf has joined #ocaml
<aecepoglu[m]>
wait what is "UB"?
<sarna>
I like having escape hatches :) I don't like using them, I like having them
<sarna>
aecepoglu[m]: undefined behavior
<sarna>
if you trigger it, your program is meaningless
<sarna>
it's valid for it to format your hard drive
<sarna>
even if you wanted to count to ten :)
<aecepoglu[m]>
not undefined-behaviour as in undeterministic, but a figurative black-hole
<sarna>
it's not contained, it can affect other parts of your code. there's a fun example where a person tries to print something and triggers UB, and on runtime it tells them there's an error in a linked library they've never referred to
narimiran has quit [Read error: Connection reset by peer]
narimiran has joined #ocaml
ziyourenxiang has joined #ocaml
mbuf has quit [Remote host closed the connection]
mfp has joined #ocaml
mbuf has joined #ocaml
mbuf has quit [Remote host closed the connection]
mbuf has joined #ocaml
mbuf has quit [Quit: Leaving]
Anarchos has joined #ocaml
mfp has quit [Ping timeout: 258 seconds]
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
Anarchos has quit [Quit: Vision[0.10.3]: i've been blurred!]
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
<Drup>
dborisog_: don't undersell yourself, the code you would have to change is really simple :)
<dmbaturin>
Are there any examples of opam packages that use dune and provide both a library and an executable?
<rgrinberg>
dmbaturin atd is one example
<dmbaturin>
rgrinberg: Thanks, let me check.
Wojciech_K has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
nicolaus has quit [Quit: Lost terminal]
Haudegen has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 260 seconds]
<sarna>
I'm having a stupid problem with dune
<sarna>
`dune build main.exe` succeeds, but I can't `dune exec main.exe`
<sarna>
O
<sarna>
I'm getting "Error: Program "main.exe" not found!"
jao has quit [Read error: Connection reset by peer]
<sarna>
changed the program a bit, now I'm getting "Error: Don't know about directory main.exe specified on the command line!"..
<sarna>
ignore that, I used "dune run" out of habit from rust and go :)
<sarna>
"dune exec ./main.exe" works - I have no words
<Fardale>
because your program does not have a public name so it does not exist in your path
mfp has joined #ocaml
<sarna>
hmm, I see
FreeBirdLjj has joined #ocaml
dash has joined #ocaml
twopoint718 has joined #ocaml
twopoint718 has quit [Remote host closed the connection]
twopoint718 has joined #ocaml
jao has joined #ocaml
gareppa has joined #ocaml
gareppa has quit [Remote host closed the connection]
FreeBirdLjj has quit [Remote host closed the connection]
Serpent7776 has quit [Quit: Leaving]
FreeBirdLjj has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 260 seconds]
dreadedfrog has quit [Ping timeout: 240 seconds]
jao has quit [Remote host closed the connection]
jao has joined #ocaml
TC01 has quit [Quit: No Ping reply in 180 seconds.]
TC01 has joined #ocaml
gareppa has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
ggole has quit [Quit: Leaving]
mahmudov has quit [Ping timeout: 240 seconds]
mahmudov has joined #ocaml
gareppa has quit [Quit: Leaving]
smazga has joined #ocaml
decentpenguin has joined #ocaml
Haudegen has joined #ocaml
oni-on-ion has quit [Quit: Quit]
jnavila has joined #ocaml
<dborisog_>
Drup: it might be the case, the problem is at the moment I'm unable to see the whole picture thus I cannot predict the outcome. I do not like immature contributions, and at the moment I can only provide one of those.
<dborisog_>
I am willing to contribute, for example a part of my current work may grow into a TyXML-based charting library for Ocsigen project, but I would like to have a certain level of maturity with OCaml and Ocsigen prior any functional move.
jao has quit [Remote host closed the connection]
bartholin has joined #ocaml
jao has joined #ocaml
jao has quit [Changing host]
jao has joined #ocaml
decentpenguin has quit [Quit: decentpenguin]
dborisog_ has quit [Ping timeout: 258 seconds]
mahmudov has quit [Read error: No route to host]
mahmudov has joined #ocaml
FreeBirdLjj has joined #ocaml
dreadedfrog has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 260 seconds]
dreadedfrog has quit [Ping timeout: 265 seconds]
nullifidian has joined #ocaml
nullifidian__ has quit [Ping timeout: 240 seconds]