ha, yep. ^ May be of interest to @john and @andy.fingerhut who were asking related questions the other day in #off-topic?
I wonder how the situation is in OCaml, same I guess
no idea! Now I have to go research it…haha
Antonio Monteiro (lumo) just gave a talk on #clojutre about full stack OCaml development.
there is significant effort put into tooling and friendliness via ReasonML
@dev964 yes, it’s reason. what do you know about: 1) row polymorphism 2) hot code reloading 3) the multithreading issue in ReasonML
I know a good few clj devs that are into/professionally program ocaml/reasonML
Nope, haven’t played with it a lot
Maybe @anmonteiro can give more information on this
@borkdude from this it looks like they are more flexible than in Haskell at least: you can apparently use a record without defining all the fields, and tweak the compiler to simply warn you: https://v1.realworldocaml.org/v1/en/html/records.html
oh, or maybe that’s just pattern matching? Not sure
@gtrak also works in the ocaml space
What's the "multithreading issue"?
@john I read things like this: https://www.reddit.com/r/ocaml/comments/4c91rp/multicore_support/ dunno the current status
no parallelism
it's super early days for multicore, not sure I'd rely on it or plan to do so in the near future
I meant about the ocaml-multicore project
hmm
not bad as a thing that compiles to js though
mostly single threaded anyway
ocaml is a beautiful language, but it's platform dev is arguably super slow and the community not so big and generally a bit fragmented (multiple "core" libraries, tooling is so so, etc etc)
what is FB would massively push this language?
and what do you mean with platform dev super slow? I heard they have a very fast compiler, much faster than GHC. A common complaint about GHC is that it’s slow for big projects
sure, but right now appart from Jane's Street there's not much pushing happening
I meant the advancement of the language/compiler
multicore for instance has been in the works for an eternity
maybe they should compile to the JVM or BEAM then 😉
there are already some ml flavors for BEAM: alpaca-lang
From what I heard, some changes to the core language renders large swaths of written code broken
And lib maintainers are constantly trying to catch up with core to keep things unbroken
ocaml is fine, if you think about it the situation is not worse than python's GIL, but that's something to be aware of
I don’t know much about Python--is the GIL single-threaded or something? I vaguely remember hearing about that
I'd be more worried about the ecosystem/tooling. Last time I used it it did require quite a lot of effort to have a decent env/routine
but maybe Reason solves some of that now and also "dune", but that last one didn't exist back then
@ddellacosta yeah, python has green multi-threading, which requires the GIL thing, so not true parallelism by default, IIUC.
on the other hand, the JVM doesn’t really have green threads I guess
hmm, can’t reach any site on project Loom… did they pull the plug 😉
yet
gotcha, thanks
whole https://openjdk.java.net/ seems down?
Upon further research, I'm reading that python can spin up OS threads, but the GIL locks them in turn to prevent inconsistency.
They're on their way
there is a fairly recent talk from Oracles JVM languages summit: https://www.youtube.com/watch?v=J31o0ZMQEnI
the site of the summit is also down for the same reason 😕
“We’re sorry, the http://java.net site has closed. ”
hmm, hard to find that loom site now
but thanks for the talk, might watch it soon
omg 😂
Not sure how you could pull that off while still requiring full static typing...
What's even nicer is that fibers will make this totally transparent across os threads. Basically, this is a case of the 'best of both worlds'.