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.
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).
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.
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:
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.
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?
> 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.
> 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.
OCaml is high performance, Garbage Collected, hybrid system and application programming language
You can use OCaml to write high performance Apps and System tools without worrying too much about performance, or doing crazy manual memory management
I would also say, if you like Go, but think you hit a wall with it, then try OCaml
system programming language: C, C++, Rust
Hybrid system and application languages: OCaml, Go , D
If you need a language in this class (Hybrid system and app)I think currently Go and OCaml are your only options, Go being closer to C, Java familly of languages and OCaml is an ML language, so choose as per your preference
F# would probably sit in there somewhere too a little more on the app than system side, although you don't see many uses of the more low-level stuff that's been made available in the later releases of .NET, it's there for use in F#
In my opinion, as a professional haskell developer, it is too hard to reason about the runtime space usage of Haskell programs to ever recommend Haskell as a "systems programming language". Haskell would be great for writing a DSL for generating such code though.
Well, D have a GC, and by design cannot have a GC with good performance, because of its complex mutable object system
OCaml, can achieve good GC performance because its immutable by default
D by design, will never outperform OCaml, at least this is my understanding
That, and I think D's community is too small to fix the language, while it does have several brilliant members and developer, its just too small and underfunded
So, you have two reason why D should not be an option
the first technical ( D will never have a good GC ) the second is more of a logistics issue, the community is just not there to support a language as complex and as ambitious as D and deliver on all its claims
> Well, D have a GC, and by design cannot have a GC with good performance, because of its complex mutable object system. OCaml, can achieve good GC performance because its immutable by default
I'm not so sure considering Java probably has better GC performance than D/OCaml/Go and is completely mutable.
Java GC is only efficient if you allow it to be wasteful.
I'm regularly running hundreds of different ocaml programs on a single machine and I trust ocaml GC to actually collect the garbage.
I would not trust tens of java processes in default GC mode, which seems to be tuned for cases where a single process own the whole machine.
Hopefully, the multicore GC will be as good, or one will be able to disable multicore abilities when not in use (which is going to be most of the time, I believe)
what i know is that it is inherently harder to have good GC performance with mutable language
and as i said D has a very small community
Java is on the opposite side of this spectrum its immensely popular, and as I understand it took Java several iteration, and tons of resources before gaining good performance, and still today, Java optimization is a specialized experts job
No its not. Modern Java GC's require 0 tuning. ZGC with default settings can achieve submillisecond pauses.
> and as i said D has a very small community Java is on the opposite side of this spectrum its immensely popular, and as I understand it took Java several iteration, and tons of resources before gaining good performance
This wasn't your argument. You stated that mutability was the reason that D couldn't have a good GC, not the size of its community or resources. According to tiobe D is more popular than OCaml as well.
I develop in OCaml from time to time, and it's pretty practical. Separate compilation, makes small-ish binaries that most people wouldn't know weren't written in C/C++, fast, garbage collection reduces mental burden, easily call out to C if you need to. We steer clear of the more complex language features like functors because they confuse most programmers.
I consider OCaml the baseline for what a language from the last 20-or-so years should be. It doesn't do much that really pushes boundaries, but it has all the basic things you want and no major blunders (which is a surprisingly rare thing). In particular it has a sensible type system with proper algebraic types (which so many languages manage to get subtly wrong, even today), full pattern matching, and very little in the way of control flow keywords.
Jane Street, financial trading company, uses OCaml a ton and publishes a lot of their libraries.
I played with it some back when I was dabbling in every language I could get my hands on. About when Scala was new (and constantly breaking between releases) and before Rust, Go, JS v8 were around. I really liked the functional aspect, which wasn't bolted on after the fact, and that it could be compiled to a real binary, not interpreted bytecode. In my naive youth, I viewed AOT compilation as the path to a true high level language that was also fast.
While it was neat, I moved on to Lisps/Schemes and now modern JS is my very happy compromise of functional and practical.
Some of the rather impressive type system features of Ocaml:
- Modules can be stored in variables, based on runtime conditions, this is all statically type checked to ensure tht the module exports the binding of the proper type. Modules can also be passed to functions and functions can produce different results based on which module is passed.
- There are keyword arguments and optional arguments with full static type checking.
- It has full support for row type polymorphism, or “static duck typing” as some call it: it tests statically whether an object quacks like a duck.
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.