PR to Merge Multicore OCaml
github.com
github.com
How? Where?
https://discuss.ocaml.org/tag/multicore-monthly
There have also been presentations, videos, academic papers, etc., which should all be documented in the monthly reports.
My wish for Ocaml is that it could somehow be popular enough to have more… casual users, let’s say. I enjoy playing with it more than any other language I’ve run into, but everyone else falls so deeply into it that I don’t generally follow their discussions very well. (Maybe I’ll fall in deep myself in time, but it remains to be seen.)
Huh? The point is Go might be a lousy language, but I can't think of anything OCaml needs to do that the Go runtime cannot do. This wouldn't be leaky and the FFI could be quite good.
> Especially now that OCaml Multicore is on the way.
As I wrote in the other reply, this would be a naked ploy for new users, and flexing the language isn't wedded to a single run time.
Multicore OCaml isn't just a runtime change, but also demonstration of the new effects indicating that the language can do parallelism without bad concurrency problems. All that language-side work carries over to the other runtime: you get to show off Goroutines done more safely!
People forget that the call stack data structure naturally allows tail calls, and restrictions against it invariably have a certain degree of artificiality.
Beware that in your naked grab for users, you don't disappoint them and end up actually driving them away.
What's really dank is doing https://www.ccs.neu.edu/home/shivers/papers/mrlc-jfp.pdf i.e. multiple return pointers. This way you can do the Rust Result (Either Monad) thing without branching.
OCaml's package management and build system is not complicated for consumers and builds are very fast. What do you feel is complicated about opam and dune?
What is complicated (but got better) is submitting packages into the official package repository. However, this ensures that packages have correctly versioned dependencies, which is good for consumers.
Go does not rely on a central package repository and this makes it easier to use by essentially just pointing to GitHub. OCaml and Go differ in the way they try to use updated dependencies for a build. OCaml by default is aggressive whereas Go prefers stability.
OCaml on the other hand has an extremely well optimized runtime for lots of small heap allocations (typical in FP), and produces good asm code for functional patterns.
I am very excited not only for the native parallelism that's coming in 5.0 but also about the effect handlers! I am sure many others are looking to start creating very interesting things with them, e.g. Rust-alike async capabilities or Erlang's preemptive green threads / actors runtime.
More info: https://discuss.ocaml.org/t/multicore-ocaml-september-2021-e...
Really looking forward to what the community will build with OCaml 5.00! IMO it will shoot the language straight into the mainstream and I can't wait. OCaml is applicable for like 90% what's out there, including as a Python replacement. And its syntax is often much terser than Rust (although the higher-level typing constructs can be confusing to read).
After that, all that's left is a tool like Elixir's mix or Rust's cargo and the language is basically not only in the 21st century but much farther than many others! Looking forward to it.
This so much. Mix is so pleasant to work with, but getting an OCaml project off the ground requires messing with dune + esy if you want consistent and isolated package management. It's a massive pain.
[1]: https://github.com/ocaml-multicore/domainslib/blob/master/li...
There is work on-going at the moment to bridge or even unify eio (concurrency via effects) and domainslib (nested parallelism via domains and effects) but it's a few months out.
- domainslib schedules all tasks across all cores (like Go).
- eio keeps tasks on the same core (and you can use a shared job queue to distribute work between cores if you want).
Eio can certainly do async IO on multiple cores.
Moving tasks freely between cores has some major downsides - for example every time a Go program wants to access a shared value, it needs to take a mutex (and be careful to avoid deadlocks). Such races can be very hard to debug.
I suspect that the extra reliability is often worth the cost of sometimes having unbalanced workloads between cores. We're still investigating how big this effect is. When I worked at Docker, we spent a lot of time dealing with races in the Go code, even though almost nothing in Docker is CPU intensive!
For a group of tasks on a single core, you can be sure that e.g. incrementing a counter or scanning an array is an atomic operation. Only blocking operations (such as reading from a file or socket) can allow something else to run. And eio schedules tasks deterministically, so if you test with (deterministic) mocks then the trace of your tests is deterministic too. Eio's own unit-tests are mostly expect-based tests where the test just checks that the trace output matches the recorded trace, for example.
The Eio README has more information, plus a getting-started guide: https://github.com/ocaml-multicore/eio/blob/main/README.md
Now let's imagine I want to do the same program in OCaml. I think my options are:
- on current OCaml, thread-based concurrency but no parallelism
- on current OCaml, monadic concurrency (Lwt, Async) but no parallelism
- on multicore OCaml, direct/effect-based (I'm not sure what's the right word) concurrency with eio, which is deterministic. If I want parallelism here, I have to explicitely create and use a shared job queue, while the Go runtime does this implicitly. Since the standard library Queue is not thread safe, I would have to use Mutex to avoid concurrent access.
Is this correct? I've read the eio documentation but it's hard to wrap my head around all of that without examples. I've found the Domain_manager which looks like what I want. For example, I could have the main thread fill the queue and for each core available, I could launch a Domain_manager.run toto, with toto taking jobs from the queue that would be shared between all domains?
The README shows an example of a pool of workers pulling jobs from an Eio.Stream:
https://github.com/ocaml-multicore/eio#example-a-worker-pool
We're still exploring what APIs to provide for this kind of thing, and in particular how to unify domainslib and eio.
See the example near the end of https://raku-advent.blog/2021/12/01/batteries-included-gener... for what I mean.
We only have a few places that use "naked" pointers, which are in any case deprecated, and we should be able to fix those easily enough.
Mostly the rest are fairly ordinary extensions that just call C functions and use the usual CAMLparam stuff.
We do have a few places that register global roots. And several packages that do callbacks from C back to OCaml. We also use @@noalloc a lot.
Is there anything else? Since there's so much code, what should I be grepping for to find code that might be of concern?
Edit: Some examples of simple stuff:
https://github.com/libguestfs/libguestfs-common/blob/master/... https://github.com/libguestfs/libguestfs-common/blob/master/... https://github.com/libguestfs/libguestfs-common/blob/master/...
More complex stuff:
https://gitlab.com/nbdkit/nbdkit/-/tree/master/plugins/ocaml http://oirase.annexia.org/tmp/ocaml/
Noalloc and registering roots should all be the same, as are callbacks (for sequential code, which all existing code will be)
We have a scheduled build and test of every package in opam with multicore: http://check.ocamllabs.io:8082/ to try to shake out C API incompatibilities and that's proved fruitful.
If you do find things that don't work on 5.0, please let us know (and if you can, get it in to opam so we test it automatically!).
i.e. previously some code could've in theory assumed it only ever gets called by one thread at a time due to the global lock (and that lock would get dropped in a controlled manner by the usual released/acquire). I don't necessarily mean just global state in the C stubs (I don't recall seeing many of those), but implicit global/shared state in the C functions called. Reading manpages will usually tell whether a given function is safe to be called (or when not there are sometimes _r variants that are). This is no different than when writing regular multithreaded C code, one has to be more careful about what functions they can safely call. (and in fact current OCaml code can already be multithreaded, so if the C stub was meant to work correctly with multithreaded OCaml code with C->OCaml callbacks then it should've already taken necessary precautions).
I like the approach taken wrt to backward compatibility of sequential code though: only code that wants to take advantage of multicore will need to audit its C stubs for safety, if you don't use multicore everything will work as before.
How do you recommend to find these kinds of multicore-specific bugs in existing (or newly written) OCaml-C stubs? Would tools like parafuzz help here?
2. Domainslib is the library developed alongside multicore to aid users in exploiting parallelism. It supports nested parallelism and is pretty highly optimised (https://github.com/ocaml-multicore/domainslib/pull/29 for some graphs/numbers). The domainslib repo has some good examples: https://github.com/ocaml-multicore/domainslib/tree/master/te...
3. We've not tested against other forms of parallelism. There isn't anything stopping you exploiting SIMD in addition to parallelism from domains.
4. No, we've not compared performance by OS.
5. No plans for the multicore team to look at accelerator integration at the moment.
There were three big reasons pushing me towards other languages (C++, Rust) for a certain class of throughput-focused workflows:
1. Lack of multicore execution
2. Lack of control over how many bytes a datatype is (useful for many things, like ensuring something fits in a machine word or can avoid chasing a pointer in a loop)
3. Difficulty controlling where memory is allocated/copied vs moved (though some of this is less relevant when everything uses reference semantics and mutability is tracked with ref/mutable)
I’ll be glad to see (1) fading into history! Do you have any personal tips/anecdotes for memory optimizations in practice, or any suggestions for something to read/follow/search?
- Is merging this PR going to be more or less a formality now? I'm assuming subsequent PRs will make further improvements/fix any further bugs discovered. When is the merge to trunk likely to happen?
- (Not that it really matters, but I'm curious). Will this PR be merged as-is with nearly 4000 commits or will it be squashed? The history exists in the multicore repo but will the history be brought into the ocaml repo?
2. That is unclear at the moment. There's a lot of useful history in those commits (which link out to issues and PRs on ocaml-multicore's repo) but at the same time, it also includes a lot of experiments that were ultimately backed out.
I think over time Jane Street will (continue to) open source more of its libraries, and hopefully soon will also migrate onto Dune (internally they use jenga[0]). This should mean that the ecosystem within Jane Street more closely matches the external environment and tooling should get better as they push patches upstream.
Hopefully.
[0] https://discuss.ocaml.org/t/does-jenga-have-more-features-th...
Sbt is actually worse than dune+opam .
Ocaml has type inference globally so you are not required to spray type annotations at everything.
But Scala does have type directed lookup (type classes/ implicits).
Both have the curse of implementation/typing choices that stops you from doing the actual job ;)
I actually don’t use it myself but it seems to bring the modern programming language experience to OCaml
* There's no ownership tracking. This might be obvious - it doesn't need it, it has GC - but is actually kind of unfortunate; even in GC'd languages, linearity can be used to safely model state machines/typestate or for optimization.
* There's no traits/ad-hoc polymorphism at all.
* There's no impls, though a common pattern with a similar feel is to define types inside modules with the actual implementation of the type hidden, and provide an interface via functions to create or interact with instances of the type.
* It uses exceptions for error handling (when it doesn't use an option type) and even as a lightweight control flow mechanism. And now there's algebraic effects as well.
* It has an extraordinarily powerful module system, with functors (pass modules into other modules to produce new modules) and first-class modules (modules that exist as values at run-time that can be passed around to functions).
* It has some more advanced type machinery - GADTs, polymorphic variants, and a very interesting, powerful, almost completely unused object system.
* This bleeds a little into "ecosystem" and a little into "no ad-hoc polymorphism" and a little into the oddness of the syntax and a little into subjectivity, but in general doing really bog-standard imperative stuff in OCaml, while possible, tends to feel more awkward than it does in Rust.
* Compiler errors won’t help you much
* The tooling is lacking compared to cargo. It’s pretty much makefiles in a lisp language (better love parens)
* The ordering of your code matters, shadowing functions and structs is a a thing
* use A::* is pretty much the default, and transitive dependencies are imported at the top level, so be ready to be confused about the origin of a function or module or variable
I really wish more people would write OCaml so that we’d have a better ecosystem.
If you’re looking to get into a new language, you should seriously consider it as there are SO MANY low hanging fruits and opportunities to have an impact on the language.
The RWO-website https://dev.realworldocaml.org claims that the 2nd. Ed. has been published in Q4 2021, but I can't find it anywhere. Can somebody with experience tell me if RWO 2nd Ed. is the way to go?
We are just finishing edits of a few chapters (the tooling, testing and GADT ones), and then it’ll be off to the publishers early in the new year. The online one is therefore pretty up to date.
There’s also a thread on the OCaml forums on this topic with more suggestions: https://discuss.ocaml.org/t/how-do-you-stay-productive-in-oc...
OCaml offers a pragmatic functional approach to programming. And now you are going to be able to have your OCaml code run in a truly parallel fashion on your multicore CPU.
In the future there are plans to add typing to effects though. (There is support for effects currently but its untyped and experimental). When that happens you can track changes to state (which is a kind of "effect") if you want to...
that wasn't the OP's argument though, the argument was that OCaml is somehow generally better for engineers.
> OCaml offers a pragmatic functional approach to programming.
an evaluation of something as pragmatic depends purely on what one whishes to practice. There's no universally objective notion of pragmatism.
> And now you are going to be able to have your OCaml code run in a truly parallel fashion on your multicore CPU.
no, it won't be able to do that automatically. Your code will have to respect certain invariants to function properly, and you as a developer will have to enforce these invariants with the available tooling at hand. Haskell has purity, guaranteed STM, and `par` labels for that. OCaml doesn't have those and the existing codebases will have to eliminate their thread-unsafe public interfaces first.
> When that happens you can track changes to state
how are you planning to track state changes without purity?
> no, it won't be able to do that automatically. [...]
I was comparing it to the old situation in OCaml is that it was impossible to have threads that were executing pure OCaml code and were _not_ IO bound to execute truly parallely. That limitation is removed.
To me it is pretty obvious that you will need to use things like atomics, thread safe data-structures, mutexes etc. to ensure your code runs properly in multicore OCaml. It was implicit in my response. But I should have been more explicit.
> that wasn't the OP's argument though, the argument was that the OCaml is somehow generally better for engineers.
Engineers tend to be pragmatic. OCaml is pragmatic. So in quick short form, OCaml may be better to solve a certain kind of problem than something that is more pure and abstract like Haskell. It was intended as an informal argument and not an argument in a court of law :-).
Like math? Engineers would rather not use math?
> It was intended as an informal argument
Maybe. But at this point it just looks like a mean dig at Haskell. A better word would be opinionated. Haskell is opinionated, and that is fine.
The biggest bait in this thread is using the term "engineers". It should rather be: people trained in imperative programming in mainstream imperative languages. Then it makes sense.
Gosh yes engineers would rather not use math. If there are approximations that work well enough (and when incorrect goes the way that leads to buildings not falling down) engineers definitely like to use less math.
For one thing, less math means less room to make mistakes, and often ugly but works well is better than elegant with a higher chance of failing due to people screwing up.
And approximations are not math all of the sudden?
> definitely like to use less math
Is your point that they would rather work less than more? Easier than harder? Cus that is not very relevant and applies to every kind of work.
Or less math and more something else that you hand wave so hard it is not clear what it might be?
> And approximations are not math all of the sudden?
The context was Haskell versus OCaml, so yeah — Haskell is the more academic, pure math. Ocaml (in this context) is the more approximate, but more practical option for larger projects. In practice people use things like C and Python because spherical cows are close enough.
It is especially funny in the thread about OCaml getting soon (2022 maybe) multicore support. Something this less practical ivory tower Haskell had before it was even cool.
Maybe, there are better options out there these days for parallel and concurrent programs. Parallel programming in C and C++ is extremely fraught for the very reasons the parent brings up. There are so many footguns, starting from the fact that the favorite debugging method of C programmers, printf(), is not even thread safe.
It’s so bad that Rust markets as a feature “fearless concurrency”, capitalizing on the recognition that the prevailing emotional state of a C or C++ dev writing concurrent or parallel programs is one of fear.
And the very thing that makes Rust concurrency fearless over C and C++ is that borrowing and mutability are explicitly tracked. As we enter a world where over a dozen CPU cores are the norm, we are learning what works and what doesn’t in writing programs for these machines, and integrating those learnings into new languages.
Most everyone I know uses a debugger. Maybe you're mostly exposed to beginner programmers?
So you end up with legions of Linus hatting on debuggers and proud themselves of never having to use one, some kind of macho thing I guess.
The last point may not be obvious, but debuggers have tons of noise for complex programs. In practice I just want to see how my program state changes over time while a debugger shows the entire program state or a large subset of it.
I think the future of debugging is going to be structured program state logging. Ideally we should be able to take our logs and partially reconstruct program state over time. For example, in addition to source location, we should save the lexical information for each variable logged so you can have interactivity with your logs and source code.
Which in the age of micro-services is quite relevant as well.
Definitely better than other languages, still doesn't prevent one to actually think about end-to-end overall system design.
It basically requires eager evaluation which, believe it or not, is a huge ergonomic win for people wanting to work on practical problems.
OCaml also preserves the concise syntax and great type inference you get in Haskell.
All in all, a more pragmatic set of tradeoffs I'd say, although it certainly has its own problems.
What is untracked? Is
unsafePerformIO (printLn ...)
foo :: IO ()
What granularity does IO have? Does
foo :: IO ()
The need for effect tracking for writing correct programs is way overstated by some Haskell programmers. It's usually much more prudent to write DSLs which hide effects like variable mutations and logging, than expose them.
For example you can start your program with a pure correct-by-construction core DSL, and then add logging, mutable variables where needed underneath the DSL's terms without breaking the semantics of the DSL. With effect tracking you are doomed to either reinvent custom effects to be able to switch interpreters painlessly, or you'll need to break the DSL by the addition of effects.
Neither is prudent in real world, neither gives more value than takes. What is really funny is that some Haskell programmed believe that logging should be tracked, but allocation apparently should not (yes, it's a side effect).
Where in fact all the "effects" are need to be tracked only when they are meaningful, i.e. when they are part of our DSL's semantics, and not some hidden part of the interpreter I don't need to know about.
Imagine a theorem prover function which creates a conjunction of two terms:
val conj : term -> term -> term
This repetitive talking point is getting boring. Go figure whether it's tracked now:
{-# LANGUAGE Safe #-}
-distrust-all-packages
That's an extremely narrow view which you wouldn't have if you ever tried to implement a safe sandboxed environment.
> What granularity does IO have? Does [...] throws any exceptions? Maybe, maybe not.
what does it have to do with tracked parallel mutations?
> Neither is prudent in real world, neither gives more value than takes
define prudent and define real-world.
> It doesn't matter if it allocates or logs
have you heard about referential transparency? It's the thing your "theorem prover" example does not have.
That is, an environment without effects? In Haskell you could't do so, since pure functions allocate, throw exceptions, trigger GC etc.
> have you heard about referential transparency? It's the thing your "theorem prover" example does not have.
Of course it's.
conj "A" "B"
Where OCaml wins is that it does not hate mutation. This makes the code more impure but simpler. Sometimes just incrementing a mutable variable makes more sense than introducing a state monad!
OCaml's variables are immutable. To use mutation, you have to do so explicitly with the `ref` type, e.g.:
let box = ref 0 in
print_endline ("box value: " ++ int_of_string !box);
box := !box + 1;
print_endline ("box value: " ++ int_of_string !box)
For example in normal Haskell the code that uses mutation and code that does not use mutation have different types. A function may have the type
f :: Int -> Int
f :: Int -> ST s Int
f :: Int -> IO Int
f :: Int -> STM Int
Adding mutability to the mix via IORefs + Haskell's laziness by default means you don't _really_ know when a particular IORef mutation may really be executed.
In OCaml, evaluation is eager and you know when it will happen. Even when you introduce bangs and special Haskell language extensions, fully removing laziness from your code in Haskell is difficult.
TL;DR: Because of Haskell's laziness you are in some ways forced to be purely functional. OCaml allows you to embrace mutation in ways Haskell does not, in my view.
> But in a multi-core environment you will eventually want a guaranteed STM.
You actually may not always always want STMs. STMs are awesome but something more basic like locks may do the job. It can be more performant to use, say, a mutex. If STMs were superior on every parameter they would have taken over the world. They have not -- they are good in some scenarios and not so good in others...
Why would one prefer to fully remove laziness?
> TL;DR: Because of Haskell's laziness you are in some ways forced to be purely functional. OCaml allows you to embrace mutation in ways Haskell does not, in my view.
unless there's a strive to be more on the side of the Safe[1] language subset, Haskell can be told to embrace the same mutation property with a combination of `unsafePerformIO` and `seq`. People tend to avoid it because the language offers a tooling to achieve better mutation properties. Overall, my argument here is that OCaml's idiomatic approach to permissible mutations doesn't seem to be a competitive advantage when it comes to software development in general, but rather a flavour that imperative programmers prefer due to their familiarity with the concept.
> You actually may not always always want STMs.
Whenever there's a non-trivial retry policy, one should prefer to choose STM + queues over debugging adventures with Locks and Mutexes. Almost all of multithreaded software I can immediately think of have non-trivial retrying logic.
[1] https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/safe...
Far from an Ocaml/Haskell expert, but is it that laziness makes resource use less predictable?
[1] https://wiki.haskell.org/GHC_optimisations
[2] https://markkarpov.com/tutorial/ghc-optimization-and-fusion....
https://medium.com/@asankhaya/reason-with-ocaml-b75697a6c00b
That said I don't know Haskell to compare!
Well I don't think you should have been the one embarrassed in that scenario.
I don’t think Ocaml had that backtick infix syntax for non-symbol function names though!
Haskell and OCaml are both brilliant languages, with excellent feature sets and amazing dev teams... and lots of "engineers" who like them.
Kototama: ...I have the feeling that OCaml may be better for engineers.
You: let's not say that OCaml is better for engineers.
People are allowed to feel things.
But I'll give you a concrete reason why OCaml actually can be better for engineers: named and optional arguments. This single feature does wonders for code readability and maintainability.
Actually I'll throw in a bonus reason: no laziness by default i.e. small and simple, predictable runtime that behaves almost exactly like a C executable.
But yes. Optional arguments are a big problem at scale. And laziness is the worst antifeature I could imagine.
But. You can disable laziness and get great performance. You just need to be careful when using libraries and pick ones that have the right strictness.
A strict Haskell would be a killer language.
Honestly a deal breaker
> A strict Haskell would be a killer language.
PureScript may be this language!
I’m someone who isn’t an experienced functional programmer, or that deeply knowledgeable about type systems and category theory etc, but OCaml is still approachable to me, I feel I can get stuff done in it. I didn’t feel that way with Haskell - I tried, but found the number of ways to do things overwhelming, and a lot of it felt very theoretical. Of course, Haskell’s pureness is an impressive and interesting feature; but it isn’t for me.
OCaml also has much better systems programming abilities compared with Haskell, IMO. It feels like OCaml is the Rust of the functional programming world (and this is no accident, the Rust compiler was first implemented in OCaml in fact).
This is all completely subjective of course.
I skimmed through some preprint on arxiv, and I got the impression that one could implement async/await as well as something like green threads if you select a suitable runtime. But beyond implementing other concurrency abstractions, why should I care?
A few of these applications were discovered only very recently. The aim is that this language primitive will inspire further discoveries for expressing useful abstractions elegantly.
Some of these ideas are summarised in this talk: https://m.youtube.com/watch?v=VEhkhxoGJSk
Multicore OCaml: October 2021 - https://news.ycombinator.com/item?id=29238972 - Nov 2021 (12 comments)
Effective Concurrency with Algebraic Effects in Multicore OCaml - https://news.ycombinator.com/item?id=28838099 - Oct 2021 (59 comments)
Multicore OCaml: September 2021, effect handlers will be in OCaml 5.0 - https://news.ycombinator.com/item?id=28742033 - Oct 2021 (3 comments)
Multicore OCaml: September 2021 - Effect handlers will be in OCaml 5.0 - https://news.ycombinator.com/item?id=28719088 - Oct 2021 (3 comments)
Adapting the OCaml Ecosystem for Multicore OCaml - https://news.ycombinator.com/item?id=28440385 - Sept 2021 (1 comment)
Adapting the OCaml Ecosystem for Multicore OCaml - https://news.ycombinator.com/item?id=28373155 - Aug 2021 (21 comments)
Multicore OCaml: July 2021 - https://news.ycombinator.com/item?id=28039219 - Aug 2021 (14 comments)
Multicore OCaml: May 2021 - https://news.ycombinator.com/item?id=27480678 - June 2021 (27 comments)
Multicore OCaml: April 2021 - https://news.ycombinator.com/item?id=27140522 - May 2021 (89 comments)
Multicore OCaml: Feb 2021 with new preprint on Effect Handlers - https://news.ycombinator.com/item?id=26424785 - March 2021 (29 comments)
Multicore OCaml: October 2020 - https://news.ycombinator.com/item?id=25034538 - Nov 2020 (9 comments)
Multicore OCaml: September 2020 - https://news.ycombinator.com/item?id=24719124 - Oct 2020 (43 comments)
Parallel Programming in Multicore OCaml - https://news.ycombinator.com/item?id=23740869 - July 2020 (15 comments)
Multicore OCaml: May 2020 update - https://news.ycombinator.com/item?id=23380370 - June 2020 (17 comments)
Multicore OCaml: March 2020 update - https://news.ycombinator.com/item?id=22727975 - March 2020 (37 comments)
Multicore OCaml: Feb 2020 update - https://news.ycombinator.com/item?id=22443428 - Feb 2020 (80 comments)
State of Multicore OCaml [pdf] - https://news.ycombinator.com/item?id=17416797 - June 2018 (103 comments)
OCaml-multicore now at 4.04.2 - https://news.ycombinator.com/item?id=16646181 - March 2018 (4 comments)
A deep dive into Multicore OCaml garbage collector - https://news.ycombinator.com/item?id=14780159 - July 2017 (89 comments)
Lock-free programming for the masses - https://news.ycombinator.com/item?id=11907584 - June 2016 (29 comments)
Lock-free programming for the masses - https://news.ycombinator.com/item?id=11893911 - June 2016 (4 comments)
OCaml 4.03 will, “if all goes well”, support multicore - https://news.ycombinator.com/item?id=9582980 - May 2015 (113 comments)
Multicore OCaml - https://news.ycombinator.com/item?id=8003699 - July 2014 (1 comment)
Is there somebody who's familiar with both worlds and could compare them and explain how Multicore OCaml (and possibly the new effect system) work?
Thanks in advance!
Scala of course just uses the set of GCs that are available on the JVM. OCaml's GC has an advantage in that it's optimized for quickly creating and collecting many small objects–perfect for functional programming. But some advanced JVM GCs probably come close to that.
The new effect system is basically 'resumable exceptions'. An effect is declared somewhat similarly to an exception. When the effect is 'thrown', it is handled by the nearest effect handler up the callstack. The difference from an exception is that once (if) it is handled, it actually resumes at the exact position in the code where it left off, not in a continuation created by a closure which is effectively what Scala and every other userland effect system does.
No. F# is an ML dialect, like OCaml. But, you should be aware that the "O" in "OCaml" actually means something. OCaml comes with beautiful object system that's prototypal in nature and structurally typed integrated into the language. F# on the other hand has the object system inherited from .NET, and it's simplistic in comparison.
Also, modules and functors.
So, no, F# is not OCaml. If you absolutely need to use .NET, and know some ML, you can reach for F#, but its limitations will drive you nuts quickly. F# is for C# programmers - they have "full power of .NET" still accessible, plus a few nice things like HM type inference, immutability by default, and maybe computational expressions.
F# is an ML that is kind of allowed to play on .NET because in a given moment management accepted to integrate it into Visual Studio, and keeps looking for the golden spot that it will take it beyond the VB/C# shadow, always a second thought when the .NET team designs new architecture features only taking VB and C# into consideration.
F# twittersphere is its own bubble, not always with nice opinions about Microsoft and the .NET platform it depends on.
I’d like to learn Ocaml (more than just the parts I’ve learned from F# and SML), but F# is by no means a simplistic language in terms of what you can accomplish. It’s easily one of the best designed and most pragmatic languages out there. From the syntax I have seen, F# is cleaner than Ocaml.
> F# is an ML dialect, like OCaml
That’s kind of splitting hairs. The object system is different for obvious reasons. F# clearly started as a port of a subset of Ocaml to .NET and was even valid Ocaml code for some time in the early days. That’s exactly a dialect.
For F#, they started with OCaml syntax and semantics; then modified it to make it a true .NET language. They added features that were not in OCaml like inheritance & interfaces. and removed features that were unnecessary in .NET like functors.
https://fsharp.org/history/hopl-final/hopl-fsharp.pdf Early F# compiler even had ml-compatibility mode which would make syntax closer to OCaml, it was probably used for bootstrapping.
It was wrong of me to only mention the "limitations" (compared to OCaml) that "will drive you nuts", while saying nothing about extensions/advantages of F# - because, obviously, it does have some. This:
printfn "%s" ((3.0 + 3.0).ToString())
What I really wanted to say, but somehow failed, is that F# is not OCaml - it's a language in its own right, with both good and bad sides, which don't align with those of OCaml particularly well (and sometimes not at all). F# and OCaml share some semantic and syntactic features, but they are not "dialects" of each other (no matter which way you want to spin it), they have very different sets of trade-offs, and probably shouldn't be directly compared (even if such comparison was OK historically).
I think I failed to convey this properly because I was angry that "someone on the Internet!!!" mentioned F# in an OCaml thread "AGAIN!!!", even though it's definitely one of the biggest developments/successes on the OCaml side in recent memory. I mean, it's like you're having a party to celebrate your promotion, only to have that one person tell you all about how their cousin is better than you in every respect, and he didn't even need to work that hard for it, so you're just slow. It was strangely disconcerting, but I should have reacted less emotionally.