Sounds 
sweet!
It’s great to see more languages compiling to Erlang - I wonder if (you exclude JS) #erlang holds the record now? 
One of the benefits of it being OCaml, is that it’ll be easier to pick up reason and the revery framework, which is meant to be a much more performant competitor to Electron (for desktop apps).
Must admit when I first saw Caramel, I wondered whether @OvermindDL1 might have been involved 
Here’s their homepage btw:
Hi folks, i’m writing this, feel free to AMA 
Looks like this is your first post. Welcome to the forum!
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.
And I must say that personally I think implementing languages is a lot of fun. 
I have some questions I hope you’ll find time to answer Leandro 
- What made you want to create Caramel?
- Who do you think might want to use it most?
- Other than adding a type-checker, does it add anything else or bring any other benefits?
- Is there anything it leaves behind from OCaml? (That people might be otherwise expecting?)
Thanks! 
Happy to be here 
OCaml and Reason aren’t at the scale of TypeScript or Elixir, but they have a loyal and caring community 
Oh boy it is! 
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.
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.
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.
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
Thanks @ostera I am sure a lot of people will find your post helpful
It’s great to see so many to-Erlang compilers and languages now, we’ve had two this year that I know of devtalk.com/hamler was the other one). I think we’re going to see more and more interest in Erlang in the next few years - exciting times! 
We will be running a webinar on Caramel on December 9th for those wanting to explore or ask the creator any questions Register at https://www2.erlang-solutions.com/webinar-registration-2