An Elm compiler for the Erlang Virtual Machine
kofi.sexy
kofi.sexy
Since you're not planning on continue the project, and are interested on 'Elm on the server', you might look at Purescript, which has a similar syntax, and compiles to Javascript, and also the BEAM: https://github.com/purerl
There are also C++ and C backends at https://github.com/andyarvanitis/purescript-native and https://github.com/pure-c/pure-c
If having a JS compile option is not a requirement, there are 2 more Ocaml/ReasonML-like BEAM laguages, https://github.com/alpaca-lang and https://github.com/lpil/gleam
(I'm kinda partial to Gleam, it seems really clean)
Great project!
I have to disagree that elm should aim for assembly. I think that it is a perfect language to use sparingly to build extremely typesafe systems where appropriate. I've found that to be the case on the front end, where I normally use elm alongside vanilla javascript. For me, it is often quicker to develop with regular JS (esp. when need to take advantage of "native" features) but its nice to have elm for certain parts where I want to take advantage of type system. Maybe I'm biased as an elixir dev, but I think you could apply the same logic within our erlang/elixir systems. The existing "type system" (specs + dialyzer) leaves a lot to be desired, so I see room for a typesafe language that compiles to beam. As for using serverside elm outside of the erlang vm, I'm not sure I could sign up for that. Part of what attracts me to elixir is all the erlang erlang ecosystem that we have available to us.
Also, pine was a good name! but I respect the practicality of the rename.
A "bespoke backend, going to assembly directly" does not preclude the option of integrating with an Erlang/Elixir project. In fact, I think that you could do so via ports or NIFs in such a way that the caller wouldn't know the difference. I think of the Erlang JSON libarary, jiffy. It's largely implemented in C for performance, but the language it's written in doesn't seem to matter in practice. As long as there is an easy way to integrate it into your Erlang/Elixir project.
I think an "Elm on the server" solution would work much the same way. Focused on making a clean integration point—then choose whatever implementation leads to the most performant and reliable artifact.