yes, parmap is really useful, don’t get me wrong. but it also has limitations, for instance when multithreading in library code is also involved. an example is Accelerate on OS X; this did not work for me in conjunction with parmap.
Also, having Unix-specific libraries does not help on the Windows side of things. IMHO bragging about it is not exactly the way to go. Most of us are not stranded there by choice 
Hopefully we’ll be allowed to use Linux VMs some day…
OCamlnet is very cool for what it does – it’s really hard to handle shared memory flexibly with a tracing GC. But as you can see from the documentation, it’s extremely brittle and error-prone – the exact opposite of a model you’d want to encourage people to use.
They’ve looked at pretty much everything out there, including ocamlnet.
That’s a great way to doom your language to oblivion. Also, another limitation is that you better not do enough in each mapper to cause a major GC, because that’ll start marking the heap, which will cause Unix’s copy-on-write procedure to kick in, slowing the program down considerably.
2 Likes
I spent the weekend looking into what is publicly visible about the state of the OCaml multicore effort. Part of that was finally getting my head around Algebraic Effects. Once I figured out they’re really better understood as a generalization of exceptions suitable for use in the continuation passing style, I started getting more excited about them than the new runtime support for shared memory parallelism.
Oh god, I hope you didn’t look at my old Oni stuff that nobody ever actually used. In my copious spare time, I’ve been working on a replacement for it that better uses OCaml 4.x language features, and now that I’ve finally got my head around Algebraic Effects, I want them more than anything else.
I can wait for Multicore. I want Algebraic Effects now. NOW.
And I’m a little disappointed that the current publicly visible multicore branch is baselined on 4.02.2 (not even 4.02.3). So, I’m asking: is the merge debt currently too high for an outsider to consider a weekend project? Or is it doable? Can I locally rebase the multicore branch onto 4.07+trunk and start playing with it? If so, then I’d be pretty excited.
1 Like
Most certainly, yes.
1 Like
Well honestly in Ocaml’s case it’s pretty much always been that way, I attribute it to two big reasons most of the prominent devs in the community aren’t afraid of C, which tends to not be portable due to either being low level to the point that it is dependant on P platform or it’s not compatible with the bare C standards, there is also the existence of F# that comes to play, like F# despite being syntactically an inferior ocaml clone, it has already inherited a better ecosystem than Ocaml in terms of number of libraries and more maintenance .
The latter part is kind of why maintainers don’t usually care about windows compatibility gripes like, most of us aren’t stuck with windows at work, and use unix-like OS’s personally, and F# is closer to Ocaml than scala is to haskell with a billion dependencies from typelevel projects.
3 Likes
This is an interesting explanation of what’s happening with Windows support @Nobody_Gone . It makes sense. I have no interest in using Windows, ever, but I still think it would be good for Windows support to be taken seriously. Not that I am going to do anything about it, but I want OCaml to grow, and there are a lot of Windows machines. I don’t see why Windows developers should be left stuck with F#. I understand that it’s harder to get this going if most of the existing OCaml community is unix-based, and I don’t have a solution. Just expressing sentiments here.
(I considered learning F# instead of OCaml, and did notice that it seems to have more libraries available and a larger community. That was appealing. I decided I preferred OCaml and the OCaml world anyway, and I’m happy I went with OCaml, but the more its use grows the better it is for everyone involved–imo.)
1 Like
It’s not like F# isn’t great, .NET has a lot of cool shit, actually if we are talking about soley what it comes with out of the box it beats the JVM by a pretty wide margin, like the only standard lib story I find better is OTP/erlang .
So does the windows api in CPP like when I code for windows in CPP I rarely use external deps, in unix unless it’s something very low level and self contained, or really simple I can’t live without GLib for C or Boost for CPP.
F# isn’t that different or inferior at the language level, like its module system is a bit weaker, and its metaprogramming story is not great but not bad, it doesn’t have functors, white space instead of let bindings.
https://en.wikibooks.org/wiki/F_Sharp_Programming/Modules_and_Namespaces
Honestly it’s not a huge loss for windows developers here, and like if you’re a windows shop F# is probably too extreme for you let alone ocaml, see what I did there.
Also I’m pretty sure there is some fucker out there who just determines what modules in ocaml they use and the F# counterparts, for x project and transpiles that shit to F#, just for kicks because like the community in a nutshell justs seem to be full of really smart people, who love the language that know where it fails miserably, and just come up with the most ridiculous workarounds again just for kicks.
I’m not sure why you use such vulgarities to describe your opinion, but yes, F# is also a very nice language. The comparison is not just the module system and metaprogramming, some of the features they developed (active patterns, computation expressives, type providers…) are very interesting. It’s good to have more people exploring the language design space.
3 Likes
I am just a vulgar person, it tends to come out when I’m really into the conversation, you should see how bad it is when I explain things in person, but yeah I know I was intentionally referencing where ocaml outdoes F#, but yeah F# isn’t just a bad ocaml clone on .NET.
Computation Expressions are pretty beautiful.
1 Like
I believe Esterel and Lexifi (two French companies) are all working under Windows and use OCaml, not F#.
I don’t know how they do it, but they manage to live with OCaml on Windows.
I guess it’s painful, but it works for them.
1 Like
Who likes to perform this test suite on the current multicore build and compare it with .Net Core 2?
https://benchmarksgame.alioth.debian.org/u64q/fsharp.html
I am very interested how this new multi-core implementation performs ^-^
There is Eta
I guess you mean for local scope? That is optional.
This wonderful lib collection has. http://gusty.github.io/FSharpPlus/abstraction-functor.html
See also the overview: https://gusty.github.io/FSharpPlus/abstractions.html
So which kind of functors it has not, in your opinion?
F# would have Haskell functors (“mapping type”)
http://gusty.github.io/FSharpPlus/abstraction-functor.html
but it hasn’t got OCaml functors (functions over modules)
http://caml.inria.fr/pub/docs/manual-ocaml/moduleexamples.html#sec20
1 Like
Can somebody explain how this is compared to Erlangs processes or Clojure go/chan? Maybe even with example code. Thank you in advance.
1 Like
I guess Erlang processes can be distributed over the network.
All other languages don’t have this super cool ability (JoCaml had, in its early versions).
Periodic reminder that I’m champing at the bit for typed algebraic effects to land in OCaml trunk.
2 Likes