Very cool to see how this is coming along. I remember when you demoed codec-beam and the early version of a gen server implementation at the Chicago elixir meetup. Good work man.
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.
Thanks for the kind words, and it's fun to hear that you're local! I think I should have clarified more about my view of an assembly compiler:
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.
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.