Hacker News Reader

Comment by terminalserver | Hacker News Reader

For the lay person, what is the advantage of ocaml over other languages?

Why would I reach for it?

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.

Also no unicode support which is a huge con.

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

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

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?

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?

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.

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

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...

Amazing link, would highly recommend to anyone reading this thread. Thanks again

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.

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).

> 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 everything D wanted to be, but failed

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

Is Haskell a good fit for your hybrid category, similar to go and ocaml, considering it also compiles to native?

I haven't heard of Haskell being used for the kind of "high level" systems programming that go is used for.

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.

Why do you think D isn't an option?

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.

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

D also suffers from the community always racing after the next big thing without fixing the current set of issues.

> 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.

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)

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#

That language is C# not OCaml, specially with the improvements done after version 7.

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.

Here's an example of one very widely used production application: https://github.com/libguestfs/virt-v2v/tree/master/v2v

It fits a similar niche to Golang or C++, but unlike those it's an enjoyable language to program in.

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.

> no major blunders

No multithreading seems to be a pretty big problem. Hopefully, it will be fixed soon, but still

Nah. People think they want it (hence the popularity of Rust) but it doesn't actually help you achieve any of the things you actually want to achieve.

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.

https://dev.realworldocaml.org/first-class-modules.html

OCaml is...

* functional

* strongly, statically typed

* garbage-collected

OCaml can compile to a native binary, or to JS via ReScript (formerly BuckleScript).

Also, it compiles very quickly compared to most other statically typed languages; especially compared to more advanced ones.

> OCaml can compile to a native binary, or to JS via ReScript (formerly BuckleScript).

It can also compile to JS via js_of_ocaml!

That's difficult to answer without knowing what you want from a programming language/stack.

Reply on news.ycombinator.com