Live data from Hacker News

A deep dive into Multicore OCaml garbage collector

kcsrk.info

11–20 of 97 posts

Re: A deep dive into Multicore OCaml garbage collector

#11
post #2

OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it's not good, not ready, or why I should try Haskell instead. Does anyone have experience to say yay/nay on worthwhile learning, know of any companies using it heavily, or know of any large cleany written codebases from which to study?

You might want to check out https://reasonml.github.io/. It's a new syntax and set of tools for OCaml that are better in many ways but compatible with the existing ecosystem and tools.

Re: A deep dive into Multicore OCaml garbage collector

#12
post #2

OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it's not good, not ready, or why I should try Haskell instead. Does anyone have experience to say yay/nay on worthwhile learning, know of any companies using it heavily, or know of any large cleany written codebases from which to study?

From what I understand F# is a pretty close version of Ocaml, but has the benefit of all the libraries of the full .net ecosystem.

If you compare the two it's obvious the F# author blatantly copied as much as he possibly could.

Re: A deep dive into Multicore OCaml garbage collector

#13
post #2

OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it's not good, not ready, or why I should try Haskell instead. Does anyone have experience to say yay/nay on worthwhile learning, know of any companies using it heavily, or know of any large cleany written codebases from which to study?

OCaml has many of the good qualities people attribute to Go (simplicity, speed, relatively low-latency GC, well-engineered compiler&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's work in progress to fix that. Personally I'm of the opinion that if the developers had take…

People often don't like the syntax too much (which is why Facebook invented Reason). There are other weaknesses as well:

- the stdlib is good for data structures and not much else, which in turn gave rise to at least three different stdlib extensions

- it does not have typeclasses, so implementing a generic "to_string" for your data type is not a thing

- it has some really unfortunate ideas like "universal compare"

- in general, there is little focus on creature comforts (this is 2017 and despite often relying on exceptions for error handling, there is no "finally" clause in the language)

- in the same spirit, strings are simply bytes, it's up to the developer to ensure they have the right encoding

- the language separates the code itself from the type declaration, a feature which, combined with its type inference, can make reading OCaml code similar to reading Python (in the "what type is this 'e' variable" sense)

- its most widely used build system is pretty terrible

That said, it has some solid features as well, despite the small community size. The packaging system is top-notch, it has good text editor integration via Merlin, and while not always numerous, the libraries are often high-quality, and it is an exceedingly pleasant language to develop with. It strikes a really good balance between solidity and ease-of-use.

Re: A deep dive into Multicore OCaml garbage collector

#14

Earlier quoted context omitted.

From what I understand F# is a pretty close version of Ocaml, but has the benefit of all the libraries of the full .net ecosystem.

If you compare the two it's obvious the F# author blatantly copied as much as he possibly could.

F# is pretty much Microsoft's version of OCaml, but it diverges in some key features (for instance, it can do multicore but it does not have OCaml's functors).

Re: A deep dive into Multicore OCaml garbage collector

#15
post #5
post #2

OCaml has always intrigued me as something to learn, but it seems I always read equally as many reasons that it's not good, not ready, or why I should try Haskell instead. Does anyone have experience to say yay/nay on worthwhile learning, know of any companies using it heavily, or know of any large cleany written codebases from which to study?

IMO the best part about OCaml is that it's just so fun to write code in. The type system is a million times more expressive and elegant than anything the world of Java/C# offers and more rigorous to boot. And unlike Haskell, you can cheat a little and write imperative code if you really need to. The library ecosystem could be better with OCaml though, but this is a chicken-egg problem and not an indictment of the lan…

> you can cheat a little and write imperative code if you really need to

I'm not sure if this is cheating.

Yes, this can be misused to introduce side-effects where there should be none.

However, the strict evaluation by default (and lazy evaluation only when explicitly marked) has a huge benefit that you can not only reason easily about correctness (as in Haskell), but also reason easily about performance. The latter you can't do in Haskell without huge assumptions about the optimizer. In that regard, Haskell is similar to SQL: For small SQL queries it is pretty clear how it will be executed, but for large SQL queries it isn't clear at all which route the query planner will choose.

Having said that, reasoning about performance is even better in Rust, which is heavily inspired by OCaml but allows to to reason about memory access, closing the gap that you can reason about OCaml's performance only while ignoring the GC.

Re: A deep dive into Multicore OCaml garbage collector

#16

Earlier quoted context omitted.

If you compare the two it's obvious the F# author blatantly copied as much as he possibly could.

F# is pretty much Microsoft's version of OCaml, but it diverges in some key features (for instance, it can do multicore but it does not have OCaml's functors).

Im making over $7k a month working part time. I kept hearing other people tell me how much money they can make online so I decided to look into it. Well, it was all true and has totally changed my life. This is what I do...

http://www.joinmate2.Com

Re: A deep dive into Multicore OCaml garbage collector

#17

Earlier quoted context omitted.

If you compare the two it's obvious the F# author blatantly copied as much as he possibly could.

F# is pretty much Microsoft's version of OCaml, but it diverges in some key features (for instance, it can do multicore but it does not have OCaml's functors).

F# has added some new features on top of OCaml like: - Lightweight syntax - Active Patterns to extend pattern matching - Type Providers to make it easy to interact with json/sql in a type safe way

It's a joy to work in

https://stackoverflow.com/questions/179492/f-changes-to-ocam...

Re: A deep dive into Multicore OCaml garbage collector

#18
post #15
post #5

Earlier quoted context omitted.

IMO the best part about OCaml is that it's just so fun to write code in. The type system is a million times more expressive and elegant than anything the world of Java/C# offers and more rigorous to boot. And unlike Haskell, you can cheat a little and write imperative code if you really need to. The library ecosystem could be better with OCaml though, but this is a chicken-egg problem and not an indictment of the lan…

> you can cheat a little and write imperative code if you really need to I'm not sure if this is cheating. Yes, this can be misused to introduce side-effects where there should be none. However, the strict evaluation by default (and lazy evaluation only when explicitly marked) has a huge benefit that you can not only reason easily about correctness (as in Haskell), but also reason easily about performance. The latter…

You are offering a one-sided argument with regard to strict versus lazy!

Lazy evaluation can make space usage difficult to reason about, but time complexity should be unchanged.

Lazy evaluation, by default, is also a huge benefit to Haskell. Strict evaluation is often a huge impediment to function reuse.

Re: A deep dive into Multicore OCaml garbage collector

#19
I never managed to understand why so many people were apparently longering for multicore support. I just can't believe many are impatiently waiting for this feature to start using the ocaml language for some projects requiring multicore support, and I became impatient myself just to see what those projects are.

In recent years where servers are to scale to many machines I found myself using less and less kennel threads. Also it seams GUIs are mostly web theses days. Most remaining fields I can imagine where you would want kennel threads, ocaml would not fit anyway because of GC and lack of control over memory layout.

So I really wonder...

Re: A deep dive into Multicore OCaml garbage collector

#20
post #15
post #5

Earlier quoted context omitted.

IMO the best part about OCaml is that it's just so fun to write code in. The type system is a million times more expressive and elegant than anything the world of Java/C# offers and more rigorous to boot. And unlike Haskell, you can cheat a little and write imperative code if you really need to. The library ecosystem could be better with OCaml though, but this is a chicken-egg problem and not an indictment of the lan…

> you can cheat a little and write imperative code if you really need to I'm not sure if this is cheating. Yes, this can be misused to introduce side-effects where there should be none. However, the strict evaluation by default (and lazy evaluation only when explicitly marked) has a huge benefit that you can not only reason easily about correctness (as in Haskell), but also reason easily about performance. The latter…

> Having said that, reasoning about performance is even better in Rust, which is heavily inspired by OCaml but allows to to reason about memory access, closing the gap that you can reason about OCaml's performance only while ignoring the GC.

Rust is a really different topic. It's an imperative low-level language with functional trappings, not the reverse. First off, "reasoning about memory access" really means "think about what part of code owns which data", which is non-trivial, especially considering the various ways for sharing data in Rust.

Secondly, trying to do idiomatic OCaml in Rust is a terrible idea. Idiomatic OCaml is all about immutability and recursion. Immutability means allocation, and idiomatic Rust is pretty much all about avoiding allocations. And recursion is also a bad idea, especially considering Rust does not have TCO. It's not a dig at Rust, which is an exceedingly interesting language of its own, but Rust and OCaml have completely different philosophies.

Post reply on HN