Leonidas changed the topic of #ocaml to: Discussion about the OCaml programming language | http://www.ocaml.org | OCaml 5.1.1 released: https://ocaml.org/releases/5.1.1 | Try OCaml in your browser: https://try.ocamlpro.com | Public channel logs at https://libera.irclog.whitequark.org/ocaml/
<discocaml> <deadsg> so how would i go about building a projecy with wsl?
brandoHSTY has joined #ocaml
rgrinberg has joined #ocaml
rgrinberg has quit [Read error: Connection reset by peer]
<dh`> companion_cube: either one thread per connection or thread pools and work lists or whatever, but _not_ using things like lwt that create poorly-documented or undocumented semantic excursions
rgrinberg has joined #ocaml
<dh`> lwt tries to do a bunch of stuff for you, but doesn't do a good job of explaining the semantics of its alternate constructions
brandoHSTY has quit [Remote host closed the connection]
<dh`> and lwt is well documented compared to a lot of things
<dh`> e.g. I'm still not sure why lwt causes some but not all exceptions to silently disappear, or how to avoid that behavior
<discocaml> <idontwantausernamefeckoff> i always found lwt quite leaky compared to eio
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dnh has joined #ocaml
jutty has joined #ocaml
dnh has quit [Ping timeout: 256 seconds]
<companion_cube> Yeah its exception semantics is not trivial
<companion_cube> Reading lwt.ml also shows how complicated it is internally (because it has to avoid space leaks, preserve some tail calls, etc)
<companion_cube> My feelings about Eio are mixed, but I think miou for example should be quite small and well documented
dnh has joined #ocaml
jutty has quit [Quit: jutty]
dnh has quit [Ping timeout: 272 seconds]
raskol has joined #ocaml
<discocaml> <idontwantausernamefeckoff> i feel like i’m starting to understand eios strangeness
rgrinberg has joined #ocaml
dnh has joined #ocaml
dnh has quit [Ping timeout: 255 seconds]
<dh`> all that complication is supposed to help you, but in practice it seems to result in a programming model that has holes in its operational envelope
<companion_cube> dh`: I'm normally a proponent of thread pools, but it's hard to deny now that event loops are more efficient for very concurrent IO workloads. And then you have to have some concurrency model around the event loop and it's a mess :/
azimut has quit [Ping timeout: 255 seconds]
dnh has joined #ocaml
<dh`> well
<dh`> it gets messy
<dh`> but it definitely doesn't work to have a single-threaded event loop if you're chasing after concurrent performance
<dh`> and so it seems like in general what you want is either light enough threads that you can have one per connection
<dh`> or you have a pile of threads trying to multiplex events for different connections, and that's always going to be a mess
<dh`> but I'm not up on the trends in this
<dh`> thread pools in general tend to suck the pipe because you lose cache affinity
dnh has quit [Ping timeout: 256 seconds]
Ella has joined #ocaml
<dh`> and you spend too much time coordinating the pool
<dh`> if I were trying to do this for really serious I would probably want a channel-based language, which ocaml really isn't
dnh has joined #ocaml
Ella6 has quit [Ping timeout: 252 seconds]
dnh has quit [Ping timeout: 246 seconds]
<discocaml> <idontwantausernamefeckoff> i don’t feel green threads add that much complexity than if i were to have to organise threads myself
<discocaml> <idontwantausernamefeckoff> channels are interesting tho
Ella5 has joined #ocaml
Ella has quit [Ping timeout: 246 seconds]
dnh has joined #ocaml
dnh has quit [Ping timeout: 260 seconds]
mmohammadi9812 has joined #ocaml
mmohammadi9812 has quit [Remote host closed the connection]
mmohammadi9812 has joined #ocaml
mmohammadi9812 has quit [Remote host closed the connection]
waleee has quit [Ping timeout: 268 seconds]
<discocaml> <darrenldl> what would qualify as a channel-based language?
<companion_cube> dh`: my understanding (not experience) is that the absolute best is one event loop per core, pinned to the core (like seastar)
<companion_cube> But anyway, most leading web libraries use event loops in a way of another, in the end (some do that on multiple cores, like Tokio in Rust)
average has quit [Quit: Connection closed for inactivity]
zanetti has quit [Quit: zanetti]
dnh has joined #ocaml
dnh has quit [Ping timeout: 255 seconds]
dnh has joined #ocaml
dnh has quit [Ping timeout: 272 seconds]
<dh`> idk
<dh`> one of the reasons I don't follow the trends in this is that people who should know better get worked up about it
<dh`> that does make a certain amount of sense, but it seems like if you care that much you'd want to be assigning work to cores based on cache affinity too, and that doesn't give a good way to do that
<companion_cube> afaiu, if you do that then a single connection stays on a core
<companion_cube> that said, I guess this is for experienced people who are really chasing the high perf
<companion_cube> otherwise it _should_ really be sufficient to have a single thread event loop and a thread pool for background jobs
dnh has joined #ocaml
dnh has quit [Ping timeout: 268 seconds]
fweht has quit [Quit: Connection closed for inactivity]
mbuf has joined #ocaml
dnh has joined #ocaml
dnh has quit [Ping timeout: 255 seconds]
Square3 has joined #ocaml
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mange has quit [Remote host closed the connection]
azimut has joined #ocaml
zanetti has joined #ocaml
zanetti has quit [Client Quit]
Serpent7776 has joined #ocaml
rgrinberg has joined #ocaml
bartholin has joined #ocaml
olle has joined #ocaml
dnh has joined #ocaml
bartholin has quit [Quit: Leaving]
raskol has quit [Ping timeout: 264 seconds]
mbuf has quit [Quit: Leaving]
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mro has joined #ocaml
vsiles has quit [Ping timeout: 268 seconds]
vsiles has joined #ocaml
dnh has joined #ocaml
jutty has joined #ocaml
jabuxas has joined #ocaml
<discocaml> <idontwantausernamefeckoff> companion_cube: i wish eio had a built in pooling domain manager. i know you do because the first google result for that is an issue you made 😅
<discocaml> <idontwantausernamefeckoff> oh when did Executer_pool get added
gentauro has quit [Read error: Connection reset by peer]
gentauro has joined #ocaml
olle has quit [Ping timeout: 264 seconds]
jutty has quit [Quit: jutty]
jabuxas_ has joined #ocaml
neiluj has joined #ocaml
jabuxas_ has quit [Ping timeout: 268 seconds]
raskol has joined #ocaml
troydm has quit [Ping timeout: 260 seconds]
szkl has quit [Quit: Connection closed for inactivity]
mbuf has joined #ocaml
jabuxas has quit [Ping timeout: 264 seconds]
<discocaml> <deepspacejohn> I'm reading these docs https://ocaml.org/p/domainslib/latest/doc/Domainslib/Task/index.html and I see this mentioned several times "Must be called with a call to run in the dynamic scope to handle the internal algebraic effects for task synchronization."
<discocaml> <deepspacejohn> what does "dynamic scope" mean in this context?
Square3 has quit [Ping timeout: 264 seconds]
zozozo has quit [Ping timeout: 260 seconds]
<discocaml> <deepspacejohn> I'm inferring that it means `run p (fun () -> (* run is in the dynamic scope here *))` based on other parts of the docs, but I haven't otherwise seen that term before.
<companion_cube> Yeah it's pretty much that
<companion_cube> It must run in a thread that handles the effects properly
<discocaml> <deepspacejohn> Thanks, that makes sense. The terminology just made me wonder if I was missing something else
<discocaml> <hockletock> the last paragraph of the `run` entry is slightly clearer: "[run] should be used at the top level to enclose the calls to other functions that may await on promises"
neiluj has quit [Remote host closed the connection]
waleee has joined #ocaml
zanetti has joined #ocaml
Serpent7776 has quit [Ping timeout: 268 seconds]
darchitect has joined #ocaml
bartholin has joined #ocaml
mro has quit [Ping timeout: 268 seconds]
mbuf has quit [Quit: Leaving]
jabuxas has joined #ocaml
jabuxas_ has joined #ocaml
jabuxas_ has quit [Client Quit]
jabuxas_ has joined #ocaml
jabuxas_ has quit [Ping timeout: 256 seconds]
jabuxas_ has joined #ocaml
jabuxas_ has quit [Ping timeout: 264 seconds]
jabuxas_ has joined #ocaml
jutty has joined #ocaml
waleee has quit [Ping timeout: 268 seconds]
jabuxas_ has quit [Ping timeout: 268 seconds]
<discocaml> <coollcat> Would Go?
<companion_cube> would Go what?
jabuxas has quit [Remote host closed the connection]
rgrinberg has joined #ocaml
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
waleee has joined #ocaml
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
dnaq has quit [Remote host closed the connection]
dnaq has joined #ocaml
<discocaml> <Kali> qualify as a channel based language
<discocaml> <Kali> replies do not show through the bridge
<companion_cube> oh. I guess it qualifies? idk
GreaseMonkey has quit [Remote host closed the connection]
greaser|q has joined #ocaml
greaser|q has quit [Remote host closed the connection]
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jabuxas has joined #ocaml
jabuxas_ has joined #ocaml
jabuxas has quit [Ping timeout: 260 seconds]
<discocaml> <idontwantausernamefeckoff> i don't remember ever using channels that much in go
jabuxas has joined #ocaml
jabuxas has quit [Ping timeout: 246 seconds]
zanetti has quit [Quit: zanetti]
<discocaml> <coollcat> Yeah it sort of depends what you do with it I guess. Channels are a major feature, but I’m not sure what extent would make a language “channel based”
jabuxas has joined #ocaml
<discocaml> <idontwantausernamefeckoff> there are some smaller languages which place a much heavier emphasis on channels
<discocaml> <idontwantausernamefeckoff> can't think of any off the top of my head though, maybe julia?
<discocaml> <idontwantausernamefeckoff> go's main focus is on goroutines though, i wouldn't say its channel based like i wouldn't say eio is promise based just because it offers that as a concurrency tool
<discocaml> <idontwantausernamefeckoff> found a use for `418 I'm a teapot` earlier
<discocaml> <darrenldl> @coollcat oh idk, i was just curious what dh` meant
a51 has quit [Quit: WeeChat 4.2.1]
zanetti has joined #ocaml
bartholin has quit [Quit: Leaving]
zanetti has quit [Client Quit]
<companion_cube> then what is a channel oriented language? :)
<companion_cube> or what is an example of one?
masterbuilder has joined #ocaml
torretto has quit [Ping timeout: 255 seconds]
jabuxas has quit [Ping timeout: 240 seconds]
torretto has joined #ocaml
Tuplanolla has joined #ocaml
<discocaml> <struktured> I'm saddened that owl didn't gain more momentum. I went to pydata con recently and I couldn't believe how much funding the community gets to improve and extend numpy / pandas / polars / etc.
jabuxas has joined #ocaml
<companion_cube> let's be realistic, polars is going to single-handledly beat anything we can write in OCaml
<companion_cube> I think it's fine that languages have domains of application where they're good, and domains where they're bad
<companion_cube> and numerical computations is a place where OCaml is bad
<companion_cube> and that's just fine
rgrinberg has joined #ocaml
<discocaml> <struktured> oh I don't mind ocaml wrapping some other dataframe library, in general
<companion_cube> Yeah absolutely
<companion_cube> Bindings is the way to go
<discocaml> <struktured> especially polars since it is written with a pretty sound design, has a decent expression language which ocaml could probably model nicely
<discocaml> <struktured> however, to implement a user defined function you'd still have to fall back to rust, which is not ideal
<discocaml> <struktured> (same would be true in python, of course)