Hamler Programming Language

(copied from the website)

Hamler is a strongly-typed language with compile-time typechecking and built-in support for concurrency and distribution.

Why Hamler?

For almost a decade, we have been developing software systems based on Erlang/OTP, especially our main product EMQ X - the scalable open-source MQTT broker. So, we have always believed that Erlang is a masterpiece of engineering. With amazing concurrency, distribution and fault tolerance, it is one of the few general-purpose language platforms able to properly handle concurrency and soft realtime.

However, from all the experience writing Erlang, we believe that the following features can help Erlang programmer better adapt to the coming wave of 5G, IoT and edge-programming and attract more people for using BEAM.

  • Compile-time type checking and type reference
  • ADTs, Function Composition, Type Classes
  • More friendly syntax for prosperous communities
  • Functor, Applicative and Monad…:slight_smile:



From https://github.com/hamler-lang/documentation/blob/master/guides/01_WhyHamler.md

t :: IO ()
t = do
  pid0 <- selfPid
  pid100 <- seqio [spawn loop (State pid0) | x <- [1..1000]]
  seqio [send j (Next i) | (i,j) <- (zip pid100 [last pid100|init pid100]) ]
  send (head pid100) (Trans "great hamler! " 0)
  return ()

data Message = Next Pid
             | Trans String Integer

data State = State Pid

dealMessage :: State ->  Message -> IO State
dealMessage (State pid) (Next p) = return (State p)
dealMessage (State pid) (Trans str 11111) = return (State pid)
dealMessage (State pid) (Trans str i) =
  do send pid (Trans str (i+1))
     pid0 <- selfPid
     println (show pid0 <> " -> " <> show pid <> ": " <> str <> show i)
     return (State pid)

loop :: State -> IO ()
loop s = do
  x <- receive
  s1 <- dealMessage s x
  loop s1

Cross posted on Devtalk :003:


All those attempts to improve typing in erlang/elixir looks really tempting to use. On the other hand it’s quite risky to use it in production. :slightly_smiling_face: I am really impatient to see what the Facebook team will come up with (Facebook is writing a new, statically typed language to run on the BEAM?!). Apparently having better typing in the BEAM is a really desired feature.


Do you mean risky because these languages are still very new? Or some other reason?

1 Like

Exactly. I assume because those languages are not used so widely, they may be more prone to internal bugs. Also the rather simple tooling can be problematic when trying to find and fix a bug, etc… But I guess it was the same with Elixir in it’s beginning. :slight_smile:

1 Like

This looks so eerily similar to OCaml. :107:

@chulkilee Are you affiliated?

No, I just found it from HackerNews. Haven’t heard of it here so just sharing here :slight_smile:

1 Like

This is a fork of PureScript with minor syntax changes and an erlang backend added (similar to purerl). I would love to see a comparison between this and purerl.


What are the syntax changes? I couldn’t find any differences from regular PureScript.

From reading the compiler source I would be a little reluctant to call this language at present, more an alternative backend for the PureScript compiler. I wonder why they decided not to use the existing Erlang backend for the PureScript compiler, Purerl.

Very interested to see where this goes next!


There is now a comparison between Hamler and Purescript in hamler docs on GitHub