<story><title>A deep dive into Multicore OCaml garbage collector</title><url>http://kcsrk.info/multicore/gc/2017/07/06/multicore-ocaml-gc/</url></story><parent_chain><item><author>axaxs</author><text>OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it&amp;#x27;s not good, not ready, or why I should try Haskell instead.  
Does anyone have experience to say yay&amp;#x2F;nay on worthwhile learning, know of any companies using it heavily, or know of any large cleany written codebases from which to study?</text></item></parent_chain><comment><author>rbehrends</author><text>I think as a computer scientist you should really have at least some familiarity with both Haskell and one of the ML languages, just because it&amp;#x27;ll expand your thinking. Whether to invest deeply in one of them is a matter of whether you have the time (especially if it&amp;#x27;s just as a hobby) and how well one or the other matches your preferences.&lt;p&gt;I don&amp;#x27;t generally evangelize OCaml – because as a language it can be a bit of a mixed bag – but end up using it a lot because in the end it&amp;#x27;s a pragmatic language and a really solid workhorse. The niche that it fills for me is that of a statically typed language with native compilation and a GC, a niche that has historically not been served all that well.&lt;p&gt;Things I like:&lt;p&gt;* The language itself is not too opinionated. It&amp;#x27;s a multi-paradigm, functional-first language, that allows me to use imperative or OO styles when that&amp;#x27;s the best fit.&lt;p&gt;* The compiler is fast.&lt;p&gt;* While the ecosystem has some gaps, it&amp;#x27;s very solid in those areas that I need (such as systems programming or language tooling).&lt;p&gt;* The language does not prioritize speed at the expense of correctness; this includes the compiler. There are languages where, let&amp;#x27;s say, I have trust issues. Code quality is still pretty darn good.&lt;p&gt;* I really like ML functors for parametric polymorphism. While more verbose than other approaches, they are simple and powerful.&lt;p&gt;* Having a time-traveling debugger can occasionally be very helpful.&lt;p&gt;* For all their warts, the language and the compiler are mature.</text></comment>
<story><title>A deep dive into Multicore OCaml garbage collector</title><url>http://kcsrk.info/multicore/gc/2017/07/06/multicore-ocaml-gc/</url></story><parent_chain><item><author>axaxs</author><text>OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it&amp;#x27;s not good, not ready, or why I should try Haskell instead.  
Does anyone have experience to say yay&amp;#x2F;nay on worthwhile learning, know of any companies using it heavily, or know of any large cleany written codebases from which to study?</text></item></parent_chain><comment><author>logicchains</author><text>OCaml has many of the good qualities people attribute to Go (simplicity, speed, relatively low-latency GC, well-engineered compiler&amp;amp;runtime) and none of the downsides. Its weakness is terrible support for multithreading (like CPython it has a global lock, such that only one thread can execute OCaml code at a time), but there&amp;#x27;s work in progress to fix that. Personally I&amp;#x27;m of the opinion that if the developers had taken multicore more seriously a decade ago, and improved Windows support, it would&amp;#x2F;could be used now for most of the things for which Go is used.</text></comment>