What is your opinion about Caramel, the OCaml compiler with Erlang backend?

[ostera]

@DevotionGeo

Looks like this is your first post. Welcome to the forum!

Thanks! Happy to be here

@rvirding

I think the idea is very good. I don’t have any feeling for how popular OCaml is so I don’t know if it will bring more users into the Erlang Ecosystem.

OCaml and Reason aren’t at the scale of TypeScript or Elixir, but they have a loyal and caring community

@rvirding

And I must say that personally I think implementing languages is a lot of fun.

Oh boy it is!

@AstonJ

What made you want to create Caramel?

I actually started making a type-checker for Erlang, as I wanted to really understand what were the hard parts about it. I chose to cram in a well-typed language into Erlang and try to get the same program out of Erlang afterwards, and thus Caramel as an OCaml to Erlang compiler was born.

The next milestone I’m working towards is actually recovering the type information from the generated Erlang programs to verify that the compilation is sound.

@AstonJ

• Who do you think might want to use it most?

I think anyone dealing with complex state machines should seriously consider this. Having a type-level representation of your business domain logic can be incredibly useful to rule out illegal representations, making them entirely unrepresentable, and having a tool tell you pretty much instantly if you’re about to do something you shouldn’t do.

Rapid prototyping and fearless refactors on large codebases are two other things that I really enjoy in OCaml, and that you would be able to get through Caramel as well.

@AstonJ

Other than adding a type-checker, does it add anything else or bring any other benefits?

Well, yes it does! OCaml is a highly expressive language, and building type-safe DSLs in it for specific problems is fairly common amongst the more idiomatic users. Check cmdliner as an example, or fmt.

In addition, the OCaml module system is by far the most powerful (and still type-safe) one I’ve seen put to production, so it should help with code reuse, enforcing codebase conventions, and large-scale refactors as well.

@AstonJ

Is there anything it leaves behind from OCaml? (That people might be otherwise expecting?)

Indeed, there’s a lot of tradeoffs being made here. For example, the OCaml object system (OOP support) will not be supported in the current compilation mode. Same goes for other features like first-class modules (treating an entire module of code as a value), or mutability.

I am however experimenting with ways in which some of the existing ecosystem codebase that is not trivially translatable can be made usable from within the BEAM by means of generating NIFs. We do have a lot of type-information to guide this process

Hope this helps