[diginux]

I have started playing with Rust and have used OCaml on and off, but recently really diving hard into it building a REST-based application from top to bottom in OCaml, including all the infrastructure bits. We are slowly making our stuff open source as it becomes useable: https://github.com/afiniate

In short, OCaml is a mature language that has been used for decades in commercial applications. I feel OCaml is the next progression for the people that got excited about distributed systems via the Erlang path and want more of the safety and reasoning that comes from a strongly/statically-typed language like OCaml. Rust may or may not take off, but I am confident OCaml will remain viable for the foreseeable future, and probably gain slow, but steady popularity as engineers see all the cool things you can do like MirageOS: http://openmirage.org/

[lobster_johnson]

Isn't the Unicode situation in OCaml more or less the same as in Erlang and Ruby 1.8, ie. "string" is just a byte string, and there's no native encoding support?

Last I checked, there was decent third-party library support in Batteries. I imagine it would be painful if you were to use Batteries' "UTF8.t" string type and had to interface with some other library that used "string" or some other string solution (like Camomile)?

[unhammer]

There's no built-in encoding/decoding stuff, ie. you need to use a library like Batteries, Camomile, uutf/uucp if you want to do something like capitalise, split or count characters.

Writing the appropriate glue isn't very hard, the interfaces either work with bytes or have to/from-bytes functions, but I suppose it's a bit annoying (at least when first starting out with the language) to have to figure out which lib is needed for which type of string operation, e.g. if you're into Batteries you still need Camomile (or uucp) for lowercasing:

    module C = CamomileLibraryDefault.Camomile
    module CM = C.CaseMap.Make(C.UTF8)
    module U = Batteries.UTF8
    
    let lower_initial bytes =
      U.sub (U.of_string_unsafe bytes) 0 1
      |> U.to_string_unsafe
      |> CM.lowercase
    
    let () =
      lower_initial "Åge" |> print_endline (* prints "å" *)

[lobster_johnson]

That's pretty horrible. Thanks for the explanation.

[toast0]

Erlang has no string type. Most strings are a list of integers (any size), you can put Unicode code points there if you want, or integers less than 255 if you prefer. There is also a binary/bitstring type which is an array of bits (if a multiple of 8, it's a binary). You can put whatever you want in a binary, it's binary.

If you'd like things encoded in some way, that's up to you, there is no type to help you (there is a Unicode module which can help convert between encodings)

[WaxProlix]

Don't forget the .NET OCaml, F#!

[bunderbunder]

F# is a member of the ML family, but I'd really hesitate to call it the .NET OCaml. It would be similarly accurate to say that Objective-C is the Apple C++.

They belong to the same family, and they both share a common ancestor that is not object-oriented. But their object systems are very different from each other.

[yellowapple]

> It would be similarly accurate to say that Objective-C is the Apple C++.

Well it's not inaccurate. Both of them were designed to make C object-oriented, and they tend to be used for many of the same situations because of that.

A more accurate nomenclature would be ".NET's OCaml-equivalent" or "Apple's C++-equivalent" (much like how C# is characterized as ".NET's Java-equivalent). This falls apart with thorough inspection, of course, but it's good enough for tongue-in-cheek comparisons like this.

[nbevans]

F# has a compiler flag to force it to use OCaml syntax parsing. It basically amounts to just being a strict mode. Because F# has very slightly more forgiving syntax than OCaml; but essentially almost identical.

To call it the .NET OCaml is not too far from the truth. And it was clearly meant tongue in cheek!