6 ms·

The Hamler Programming Language

133 points by rossng 6y ago

c54 6y ago
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 6y ago
  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.
mratsim 6y ago
The logo is so similar to Haskell's ...
- zozbot234 6y ago
  It's a Haskell style language for the Erlang VM.
- vmchale 6y ago
  the name seems to be a mush of Haskell and Erlang :p
deleted 6y ago
[deleted]
rehemiau 6y ago
How does it compare to PureScript used with purerl? https://github.com/purerl/purerl https://github.com/purerl/purerl
- Vosporos 6y ago
  It leverages PureScript's CoreFn IR.
  - rehemiau 6y ago
    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?
rudolph9 6y ago
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)?
- vmchale 6y ago
  > What are the key differences between Hamler And Haskell Targeting BEAM is pretty huge!
  - rudolph9 6y ago
    Ha yes! That sounds great but theoretically the version of Haskell currently intercepted by ghc could be compiled to beam similar to how there is a compiler for the javaVM. What is fundamentally different about Hamler and Haskell?
    - regularfry 6y ago
      Purescript is strict, so I'd imagine Hamler is too.
- Vosporos 6y ago
  >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
macintux 6y ago
Added to my Erlang resources gist. Amazing how many languages are now available for the BEAM. https://gist.github.com/macintux/6349828#alternative-languages-targeting-the-erlang-vm https://gist.github.com/macintux/6349828#alternative-languag...
- vmchale 6y ago
  > Amazing how many languages are now available for the BEAM. There's hardly anything like it!
- adelarsq 6y ago
  Nice list. Just an update... `Thinking in Erlang` no longer exists
  - macintux 6y ago
    Thanks, removed. Probably a few broken links on there by now.
- yellowapple 6y ago
  At the risk of tooting my own horn, I've got one more for ya: https://otpcl.github.io https://otpcl.github.io
  - macintux 6y ago
    Thanks, added.
vmchale 6y ago
Always fun to see compilers written in Haskell! And always good to see people targeting BEAM.
heisenzombie 6y ago
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?
- Vosporos 6y ago
  It honestly depends on your use-case. For heterogeneous systems that may run different versions of your Erlang software, strictly-typed messages are not that great, because you can't really ensure that all your systems are running the same version of the code that accepts messages. (This is why in Protobuf3, everything is optional, for instance) If you are a smaller organisation than, say, Google, ensuring compatibility between your systems is easier, so that's still doable. For in-VM messaging, since all types are accessible and enforceable, it's easier to have a common contract amongst all your actors since the risk isn't the same.
  - agentultra 6y ago
    It can be done with a sufficiently expressive type system, I think. One area I'm experimenting is is a library I co-wrote[0] in Haskell that uses the type system to attach a "version" tag to a type so that your code knows what version of a record you're looking at (and also so that you can upgrade/downgrade records between versions if you need that as well). [0] https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs/Data-Migration.html https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs...
    - lukevp 6y ago
      This seems like the right approach... We store persistent data in DBMSes, which have a schema defining the layout of our data, and use versioned migrations to upgrade the data. All new data either has optional parameters with default values for all new properties, or the app has to be taken offline and all versions upgraded at the same time to migrate. It seems reasonable to reflect this practice in all state based data representations within a language, not just in an external system. Is the reason this isn't done as a first class citizen of language design because it's too much work to write migrators for every data structure change?
acjohnson55 6y ago
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
chalst 6y ago
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
purescript 6y ago
I'm curious why this isn't a backend for the existing PureScript compiler, since the front-end seems to be copy-paste identical?
- rehemiau 6y ago
  I agree. And only mentioning PureScript as the "base" in one place on the webpage is not giving PureScript enough credit.
- deleted 6y ago
  [deleted]
- emqx 6y ago
  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.
lliamander 6y ago
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.
hopia 6y ago
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.
xiaodai 6y ago
It compares itself to Erlang. How does it compare with Elixir?
ozmaverick72 6y ago
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.
namelosw 6y ago
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).
carapace 6y ago
Haskell on OTP? Yes, please! What's it like to debug?

133 points by rossng 6y ago

c54 6y ago

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 6y ago
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.

mratsim 6y ago

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

zozbot234 6y ago
It's a Haskell style language for the Erlang VM.
vmchale 6y ago
the name seems to be a mush of Haskell and Erlang :p

deleted 6y ago

[deleted]

rehemiau 6y ago

How does it compare to PureScript used with purerl? https://github.com/purerl/purerl https://github.com/purerl/purerl

Vosporos 6y ago
It leverages PureScript's CoreFn IR.
- rehemiau 6y ago
  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?

rudolph9 6y ago

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)?

vmchale 6y ago
> What are the key differences between Hamler And Haskell Targeting BEAM is pretty huge!
- rudolph9 6y ago
  Ha yes! That sounds great but theoretically the version of Haskell currently intercepted by ghc could be compiled to beam similar to how there is a compiler for the javaVM. What is fundamentally different about Hamler and Haskell?
  - regularfry 6y ago
    Purescript is strict, so I'd imagine Hamler is too.
Vosporos 6y ago
>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

macintux 6y ago

Added to my Erlang resources gist. Amazing how many languages are now available for the BEAM. https://gist.github.com/macintux/6349828#alternative-languages-targeting-the-erlang-vm https://gist.github.com/macintux/6349828#alternative-languag...

vmchale 6y ago
> Amazing how many languages are now available for the BEAM. There's hardly anything like it!
adelarsq 6y ago
Nice list. Just an update... `Thinking in Erlang` no longer exists
- macintux 6y ago
  Thanks, removed. Probably a few broken links on there by now.
yellowapple 6y ago
At the risk of tooting my own horn, I've got one more for ya: https://otpcl.github.io https://otpcl.github.io
- macintux 6y ago
  Thanks, added.

vmchale 6y ago

Always fun to see compilers written in Haskell! And always good to see people targeting BEAM.

heisenzombie 6y ago

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?

Vosporos 6y ago
It honestly depends on your use-case. For heterogeneous systems that may run different versions of your Erlang software, strictly-typed messages are not that great, because you can't really ensure that all your systems are running the same version of the code that accepts messages. (This is why in Protobuf3, everything is optional, for instance) If you are a smaller organisation than, say, Google, ensuring compatibility between your systems is easier, so that's still doable. For in-VM messaging, since all types are accessible and enforceable, it's easier to have a common contract amongst all your actors since the risk isn't the same.
- agentultra 6y ago
  It can be done with a sufficiently expressive type system, I think. One area I'm experimenting is is a library I co-wrote[0] in Haskell that uses the type system to attach a "version" tag to a type so that your code knows what version of a record you're looking at (and also so that you can upgrade/downgrade records between versions if you need that as well). [0] https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs/Data-Migration.html https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs...
  - lukevp 6y ago
    This seems like the right approach... We store persistent data in DBMSes, which have a schema defining the layout of our data, and use versioned migrations to upgrade the data. All new data either has optional parameters with default values for all new properties, or the app has to be taken offline and all versions upgraded at the same time to migrate. It seems reasonable to reflect this practice in all state based data representations within a language, not just in an external system. Is the reason this isn't done as a first class citizen of language design because it's too much work to write migrators for every data structure change?

acjohnson55 6y ago

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

chalst 6y ago

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

purescript 6y ago

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

rehemiau 6y ago
I agree. And only mentioning PureScript as the "base" in one place on the webpage is not giving PureScript enough credit.
deleted 6y ago
[deleted]
emqx 6y ago
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.

lliamander 6y ago

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.

hopia 6y ago

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.

xiaodai 6y ago

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

ozmaverick72 6y ago

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.

namelosw 6y ago

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).

carapace 6y ago

Haskell on OTP? Yes, please! What's it like to debug?