Type-checking for the BEAM is one of the most common barriers for adoption. From comments on our LinkedIn posts to threads on HackerNews, it is something that we know can make people nervous. For those in the Erlang and Elixir community, tools like Dialyzer have done a great job of meeting some of the core […]
Type-checking for the BEAM is one of the most common barriers for adoption. From comments on our LinkedIn posts to threads on HackerNews, it is something that we know can make people nervous. For those in the Erlang and Elixir community, tools like Dialyzer have done a great job of meeting some of the core requirements where type-checking would be necessary, but it’s also understandable that they’re not the right tool for every user. As a result, there has been a substantial increase in the number of languages and frameworks that looks to address this need. At Code BEAM V, Anton Lavrik announced that Facebook would be releasing their own version of statically-typed Erlang. Our friend Louis Pilford has also developed Gleam, another fast and performant language that works on the BEAM VM and offers static typing.
Erlang is a dynamically and strongly typed language that is famous for allowing teams to reduce the lines of codes needed in their system. As a result, the teams required for many Erlang systems have been small (just think of Whatsapp managing 900 million users with a backend team of only 50 server-side developers). However, as the need for scalable, distributed systems has grown (and with it, the demand for technologies that offer the benefits of BEAM-based technologies) the interest in Erlang and Elixir from broader teams, with systems built in a mix of technologies has also grown. The growing demand for BEAM based technologies has led to an increased desire to make it easier to catch errors at the time of compiling before they enter the production system. In theory, this could allow developers to create the ultimate crash proof systems, with the type checker catching everything before production and the BEAM VM, offering all the ‘let it crash’ benefits for handling failure.
The newest approach to type-checked Erlang has been created by our colleague Leandro Ostera. This began as a hobby project put together in a matter of weeks to help him understand why it is so hard to offer statically typed Erlang. As more people found out about the project, it’s popularity rapidly grew, and with good reason. Caramel now offers a highly expressive type-system and a blazingly fast type checker. As a result, your team can rule out entire classes of errors by using types that are closer to your domain.
As you can imagine, a system like this will be highly beneficial for those dealing with complex state machines. Caramel allows for a type-level representation of your business domain logic this in turn rules out illegal representations, making them entirely unrepresentable. Using Caramel, you will have a tool that tells you instantly if you are about to do something which you should not. Caramel will also make fearless refactoring of large codebases significantly easier to achieve.
Rather than reinvent the wheel when implementing the type-checker for Erlang, Leandro chose to leverage off of the existing OCaml language with over 25 years of development. OCaml was originally designed for systems where correctness was critical. As a result, it has an extremely powerful type system that has benefitted from significant time (we’re talking millions of hours) and financial (millions of dollars) investment to produce the right tool for the job. As well as its type checker, Caramel will allow Erlang developers to use OCaml’s powerful module system, which will help with code reuse, enforcing codebase conventions and large scale refactors.
The first public release of Caramel in October features:
caramelc the Caramel compiler
erlang an OCaml library for handling Erlang code, including an AST, lexer, parser, and printer
Caramel can compile a large portion of the OCaml language, in particular most of the immutable functional OCaml, and into idiomatic Erlang code.
The Erlang library currently includes support for the vast majority of the Standard Erlang language, according to the grammar shipped with Erlang/OTP as of version 24. It includes a series of modules to make it easy to construct Erlang programs from OCaml, as well as deconstruct them and operate on them.
Given the core components that currently exist within Caramel – there is an exciting and ambitious road map ahead. In the future, we could see a situation where any Erlang or OCaml code can be translated and implemented interchangeably, making the world-class strengths of both languages effortlessly available to anyone who is familiar with either language. To learn more about how you can help make that happen head to Caramel on Github. Until then, if you’d like to talk to our expert team about how we can build reliable, scalable solutions to meet your needs, get in touch. We’re always happy to help.
Source: Erlang Solutions