
The Hamler Programming Language - rossng
https://www.hamler-lang.org/
======
macintux
Added to my Erlang resources gist. Amazing how many languages are now
available for the BEAM.

[https://gist.github.com/macintux/6349828#alternative-
languag...](https://gist.github.com/macintux/6349828#alternative-languages-
targeting-the-erlang-vm)

~~~
yellowapple
At the risk of tooting my own horn, I've got one more for ya:
[https://otpcl.github.io](https://otpcl.github.io)

~~~
macintux
Thanks, added.

------
heisenzombie
I'm relatively ignorant about this, but a common refrain I've heard repeated
about strongly typed languages targeting the BEAM is that typing of messages
is [hard / an ongoing research problem / impossible]. Can anyone comment on
whether that is true and what that says about this language?

~~~
YorickPeterse
It indeed is difficult to combine static typing, and actors that can receive
messages from any other actor. "Session typing" is a way of handling this, but
I've yet to see an implementation that isn't overly complex.

Type-checking messages on the sending side is straightforward: just use a
generic PID/actor type of some sort. So for example (using Inko [1] syntax
here):

    
    
        let child: Process!(String) = process.spawn {
          ...
        }
    
        child.send('hello')
    

Handling this on the receiving end is more tricky, as a receive could happen
anywhere at any time. Imagine somewhere deep down you have a method like this:

    
    
        def foo {
          process.receive
        }
    

How would the compiler know what type `process.receive` is supposed to return?
What if you want not just a string, but a specific list of strings?

I'd say that for most languages the best approach is to use some kind of "Any"
type for messages, and rely on some form of pattern matching to figure out
what you're dealing with. This has the downside of not providing compile-time
safety, but it might be good enough. For example, in Inko (this is a new
addition not yet released) you would do something like this:

    
    
        match(process.receive) {
          'start' -> { start_the_thing }
          'stop' -> { stop_the_thing }
          else -> { oops }
        }
    

[1]: [https://inko-lang.org/](https://inko-lang.org/)

~~~
Zalastax
Yes, it's super difficult to limit the receiving end. If you use a mailbox
type, it quickly needs to handle basically all shapes of data. Session types
or similar are needed to get all guarantees we want but are super complicated.
I looked at this in my MSc thesis "Singly typed actors in Agda":
[http://studentarbeten.chalmers.se/publication/256251-singly-...](http://studentarbeten.chalmers.se/publication/256251-singly-
typed-actors-in-agda-an-approach-to-distributed-programming-with-dependent-
types)

------
rudolph9
Looks really interesting. I‘ve always admired the erlang community but writing
slang always felt like something was missing and having recently dove into
Haskell this looks like it has a lot of potential.

Few questions: 1) how stable is hamler? I’m eager to dive in but know I don’t
have time to work through frequent language bugs if I’m going to do anything
real with it.

2) A good reference, which I didn’t see in the doc and having a hard time
articulating my self would be a comparison of Hamler vs Haskell erlang FFI
support?
[https://hackage.haskell.org/package/erlang](https://hackage.haskell.org/package/erlang)

3) What are the key differences between Hamler And Haskell (sort of a
continuation of the last question)?

~~~
Vosporos
>1) how stable is hamler? I’m eager to dive in but know I don’t have time to
work through frequent language bugs if I’m going to do anything real with it.

Still a work in progress

>3) What are the key differences between Hamler And Haskell (sort of a
continuation of the last question)?

Think of the differences between Haskell and Purescript, because while the
syntax is Haskell-like, most of the infrastructure is based on PureScript

~~~
carterklein13
This definitely seems like a best of both worlds type situation.

------
lliamander
This would be interesting to check out, but in my experience with using Erlang
for a IIoT type application, gradual typing with dialyzer is sufficient for
large code bases. We also employed property-based testing to a limited degree.

The complicated part of applications that Erlang is well suited for is
reasoning about the state of the entire application based on the state of the
various concurrent processes. Perhaps I'm missing something, but I don't think
that's something that stronger type systems can really help more than what you
would get from other tools like concolic testing, TLA models, etc.

------
purescript
I'm curious why this isn't a backend for the existing PureScript compiler,
since the front-end seems to be copy-paste identical?

~~~
emqx
We really appreciate all the work Purescript has done. Hamler is still in the
early stage of development. We have made some changes on the front-end to
introduce some built-in Erlang data structures and syntax sugars, and we are
planning on making more changes in the front-end. The initial plan of the
language was for the company’s internal use and later we decided to make it
open-source hoping to communicate better with the community.

------
acjohnson55
Another options for typed actors is Akka for Scala and Java:
[https://doc.akka.io/docs/akka/current/typed/actors.html](https://doc.akka.io/docs/akka/current/typed/actors.html)

------
vmchale
Always fun to see compilers written in Haskell!

And always good to see people targeting BEAM.

------
c54
Looks cool! Is this meant for use in embedded applications? I couldn’t find
info about compile targets and performance on resource constrained systems (in
other words, can I target an Arduino?)

~~~
eyelidlessness
Since it compiles to BEAM, I would assume it's meant for use anywhere Erlang
(or Elixir or any other BEAM language) would be appropriate.

------
rehemiau
How does it compare to PureScript used with purerl?
[https://github.com/purerl/purerl](https://github.com/purerl/purerl)

~~~
Vosporos
It leverages PureScript's CoreFn IR.

~~~
rehemiau
And purerl does not? It mentions it in its readme. And in practice, do you
know what advantages it gives over the purerl's approach?

------
chalst
Interesting to see this kind of work coming out of China.

> The founding team of EMQ hails from Huawei, IBM, Amazon, and Apple with
> years of experience and a deep understanding of the industry.

[https://www.emqx.io/about](https://www.emqx.io/about)

------
xiaodai
It compares itself to Erlang. How does it compare with Elixir?

------
hopia
This looks cool! The BEAM absolutely needs languages on it with a solid
functional type system.

Curious to see what interacting with the OTP with its callbacks actually looks
like.

------
namelosw
A new family member! It's good to see BEAM is getting traction.

The documentation seem to be work in progress. I wonder how to type
processes/genservers. But generally, it seems to be a good fit, since most
Erlang code is already pretty functional (immutable, no variables, etc).

------
ozmaverick72
Has anyone tried writing a distributed app with Hamler ? It would be great to
see an example that shows off the inbuilt messaging of erlang and the static
typing of Haskell.

------
mratsim
The logo is so similar to Haskell's ...

~~~
zozbot234
It's a Haskell style language for the Erlang VM.

------
carapace
Haskell on OTP? Yes, please!

What's it like to debug?

