RIP Joe. Every interaction I had with you in the past was always a great time. You'll be missed, but never forgotten. Thanks for everything you've done for the Erlang community and distributed systems design.
Again, the problem is the initial unfounded reporting. This is why people who have been accused of heinous crimes without proof or conclusive investigation, because the town people were looking for an easy to identify perpetrator, have a hard time later being treated the same as before the accusation. It's what stays in the minds of most people that's the harm.
A friend and I used this paper as part of an independent study in compilers, it was a lot of fun and I think strikes the right balance of concepts core to compiler construction. I highly recommend it.
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/
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)?
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 "å" *)
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)
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.
> 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.
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!
Are you from JSC by chance? Is this from an authoritative source, or an just an observation of likeliness? Would love if they indeed do push hard for this.
I was pretty disappointed when I found LFE's insistence on staying very close to Erlang's semantics had forced it into implementing a Lisp-2. It's a very odd mix for FP.
Joxa deviates a bit further from some of Erlang's semantics, but in a way that allows it to express FP concepts in a much more streamlined way. Really intriguing design.
@technomancy, Hey man! Good to see you here ... but not even a little love for a Lisp-2? ;-)
We've chatted about this before, and I guess I just got used to (funcall ...) in CL. There's no question, though, that being able to call functions without that is very clean.
You know, if you squint just right, the name/arity uniqueness in Erlang is a pretty nice match for a Lisp-2 ;-)
I found that being a Lisp-1 made it inconsistent so I went with Lisp-2. Why should I be able to multiple functions with the same name but different no of args at the top-level (which you can and is commonly used) but not in local functions? Lisp-2 gives you the same handling for local functions and top-level functions.
