Kudos to Kofi for a nice project and a good write-up :+1: :)

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)

I think this is really exciting. I've just started using TypeScript on my professional front end projects and have really benefited from static typing, and I also love the concurrency model of Erlang and the BEAM. I'm going to give this a try when I finish up with all the .NET work I have to do at the moment.

Great project!

This reminds me of Elchemy (https://github.com/wende/elchemy) which uses the Elm compiler to output "readable" Elixir. I wonder if anyone has played with both and can compare them?

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.

It is good thing we have one. Will it be supported in the long term?

I don't plan to do much more with this particular project. At the end of the article I mention what I believe to be a nicer direction for Elm.

Slightly off topic but does that syntax highlighting theme in the video have a name? It's rather nice.

Funny that you mention that—the color surprised me as well! I used https://asciinema.org/ to record, which captures ANSII escape sequences. I'm guessing there's some sort of default colorscheme applied, since I've done little to individualize my terminal.

That's cool. Thanks for sharing. Would be great to see some more code snippets to get excited (or not) about the project.

Cool project! I would think Elm would be a bad choice for compiling to other languages because it isn't general purpose. You can only write 1 kind of application in Elm, right?