[richeyryan]

OCaml is statically typed functional programming language. It's a cousin of Haskell. It has some nice things like automatic type inference so you don't have to write very many type annotations. It's not as focused on purity as Haskell so its easier to mutate state where you want to but you get a lot of the niceties of ML programming languages like pattern matching, variants, structural typing in places.

It also has object-oriented features, though they aren't widely used the attitude is something like OO is there if we need it and we're definitely willing to use it in places that require it.

Its pretty fast for a functional language and you could probably get pretty far with it before you'd have to consider using a real low level langauge.

The disadvantages I think are pretty uncontroversial: a smaller community, not as many libraries, a bit of a fractured stdlib and build situation and until now no multicore.

[dunefox]

Also no unicode support which is a huge con.

[rwmj]

Please no. OCaml gets this exactly right - on the rare occasion I want to do something Unicode-y I'll use Camomile, and the rest of the time don't get in the way with stupid language decisions (yes I'm looking at you Python 3 and Ruby).

[patrec]

I'd take ocaml's unicode support over python's, javascript's or java's any day of the week.

[reom_tobit]

Tangent, but I’ve never really understood what the issue is with unicode support in various languages.

Does anyone have any idea why it’s such a contentious issue?

[tialaramex]

Unicode reflects a reality about human writing systems. They are very complicated. This is more or less guaranteed to result in Unicode being contentious.

After all, it's obvious features my native language has are important and need to be first class APIs in the standard library, while any features that language doesn't use has aren't important and the standard library shouldn't be clogged up with anything so useless. Also things that are easy to do for my preferred writing system must be supported, if the easy way to implement them doesn't work for some other widely used languages, just ignore that, those people don't matter anyway.

[chubot]

Basically because there's 2 major ways to do it: the Windows way and the Unix way (UTF-8). Unicode has the concept of encodings and it doesn't tell you which one to use.

The Unix way is winning on the web, and I think Microsoft has made some moves toward UTF-8, but I don't understand what they are exactly:

https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows#W...

JavaScript and Java inherited the Windows way. Go and Rust use the Unix way (and apparently OCaml too). Python supports both which some say is a needless source of complexity, but it is flexible if you know how to use it.

[reom_tobit]

Awesome, thanks for the info. Sent me down a rabbit hole for a little bit.

[chubot]

In case you didn't already get it, this is a good and readable summary:

https://www.joelonsoftware.com/2003/10/08/the-absolute-minim...

[dunefox]

I don't know, I like working with strings.

[patrec]

I'd say the chances of someone enjoying working with strings in say javascript or java and their code actually working correctly over the range of possible inputs it is intended to handle are pretty slim, but that may just be my lack of imagination. Can you give an example of something unicode related that would be pleasant in javascript or java but really a pain in ocaml?

[themulticaster]

> It has some nice things like automatic type inference so you don't have to write very many type annotations.

I'm not quite sure what you're going for here. The Hindley-Milner type system Haskell is based on essentially does not require any type annotations [1]. By convention, every top-level declaration is annotated, but that is only for documentation and clarity.

Or did you mean that in comparing OCaml and Haskell to other (imperative) languages?

[1] There are a few buts that don't have much to do with the argument, but I'll list them here anyway:

1) Sometimes the type you end up with is too ambiguous and you'll need type annotations: E.g. what is the type of the term "2+3"? It is something like "Num a => a" (read: any type that is roughly number-like), but that is not useful if you want to run the program. However, in practice you won't need an annotation in almost all cases as long as some function you work with restricts the type.

2) Some Haskell extensions increase ambiguity in certain cases.

[Zababa]

> Sometimes the type you end up with is too ambiguous and you'll need type annotations: E.g. what is the type of the term "2+3"?

I don't think your example works in the case of OCaml since the signature of (+) is int -> int -> int. Basic operators not being polymorphic is one of the specificities of OCaml.