Hacker News Reader

Comment by xvilka | Hacker News Reader

Sadly, Multicore OCaml [1] is nowhere near [2] completion yet. Nor it moves fast. There are still a lot [3] of issues to solve and sync with the mainstream OCaml until it will be ready for anything basic. I write OCaml mostly these days (along with Rust, C, Python, and a couple less mainstream languages), but often miss the ease of parallelization with Haskell, code clarity, and so on.

[1] https://github.com/ocaml-multicore

[2] https://github.com/ocaml/ocaml/labels/multicore-prerequisite

[3] https://github.com/ocaml-multicore/ocaml-multicore/projects/...

View on HN

Truthfully, I'm waiting for Multicore OCaml and I'll only use it, Rust and Elixir.

OCaml's typing system is in my eyes unbeatable. Still considering making a transpiler from it to Rust and Elixir but I'm grossly unqualified to write compilers. :(

Haskell though, I couldn't grok it. Seemed to introduce a lot of tension for very basic topics -- like strings -- and it lost me.

As someone who learned it casually a while back: Haskell's not great for strings, I'll give you that.

How does the OCaml type system compare with Haskell's though?

Last I checked, they weren't that different. But I found OCaml's syntax more intuitive. Subjective, I admit.

Truthfully though, both languages have similar pains. You can do one thing in 10 different ways in both, for example, which isn't tempting.

But OCaml seems more terse, and its compiler is lightning-fast, so that tipped the scales for me.

The big distinguishing difference is that OCaml doesn't have ad-hoc polymorphism and function overloading. You cannot have a function that operates on many different types; which is why you have two sets of arithmetic operators for integers and floats ("+" vs "+.", for example). In theory you can use modules for this, but it's awkward, and I don't think they're generally used this way. (OCaml is getting implicit modules, and this may help the situation.)

In Haskell, typeclasses make this super easy. It allows you define a family of functions/operators that together become what a Go or Java developer might call an interface. Code written to use a particular typeclass will work for any implementation of that typeclass.

On the other hand, OCaml's module system is very powerful and has no counterpart in Haskell. It allows you to package a whole type implementation into a single module that has a public signature, and can be instantiated with generic type parameters.

I don’t know anything about OCaml so please forgive me if this question seems silly.

two sets of arithmetic operators for integers and floats

What if I want to create more numeric types? Say vectors in R^n, for example. Do I need to create more operators for vector addition and scalar multiplication? How do I make sure the user can’t add vectors of incompatible dimension?

Yes, you need to add new functions. You cannot redefine "+" to work a custom vector type.

Similarly, you cannot have a "print" function that works for all sorts of types. OCaml has print_string, print_int, and so on.

OCaml does have parametric polymorphism ("generics"). You can write functions which support generic parameters. And you can use modules as "functors" to sort of package up types in a similar way as Haskell typeclasses (e.g. see [1]).

[1] https://stackoverflow.com/questions/14934242/whats-the-close...

> OCaml's module system is very powerful and has no counterpart in Haskell.

Is this taking into account backpack?

I'm not familiar with Backpack, but reading about it [1], it looks like its goal is indeed to provide an OCaml-style module system to Haskell.

[1] https://plv.mpi-sws.org/backpack/

> Haskell's not great for strings

What do you mean by that?

The default String type is a linked list of characters, which means various things are slower than they should be.

Hum... Yes. String is there for historical reasons that turned out to be a bad fit to what Haskell became.

But there is no reason to use it. Text does everything String does.

There are couple of implementarion of strings: * String - this is default, it is list of characters and it was a mistake. * ByteString and LazyByteString - this represents array of 8bit characters. Performant but does not handle encodings * Text and LazyText - this is what you want to use when yiu work with text, since it represent text in unicode.

There is mess in these types. s9me libraries are using different types, so you might have to convert between those and it can be confusing, and the conversion apis are not unified. But if you manage in your project consistently use single type (say Text), then you'll actually have a great time working with strings. Its problem if you want to quickly mash together few libraries that does not use same types, since it get messy.

Reason for this is mostly historic.

> ByteString and LazyByteString - this represents array of 8bit characters

Not exactly. ByteString has no relation at all with text or characters. It represents a sequence of bytes, AKA binary data.

I imagined I would hear complaints about too many text types when I made that question, but it sounded like the GP had a different complaint.

The library mess is real, but it's improving quickly and it's a bad reason to decide Haskell is a bad language to deal with text. It's throwing a lot of great stuff out just because of a minor inconvenient. And by the way, one of the best things on Haskell is that you can defined a lot more text types. For example, my current project has types for internal identifiers, HTML, HTML form values, JS, and SQL, they are all text but I can always be sure things are properly encoded.

Data.Text are fine strings really. Better than most languages I'd say, if not by a lot.

> Haskell though, I couldn't grok it

If you know OCaml it's within reach. The advantage is that you have better lazy data structures with GHC.

> a couple less mainstream languages

I'm curious: what languages?

Reply on news.ycombinator.com