I’m trying to calibrate my personal back off algorithm on checking for updates on Evan’s backend work and I’m just curious if anyone has any insight into when the new work might be released?
Exponential back-off algorithm - see you again in a couple of years?
Ya, maybe i just need to resolve to check for news at the beginning of each month, and accept that I may have to check 10 or 20 times or whatever it takes, at the risk of having a month delay in getting the news… And what?..act/plan as if it’s not going to happen in the meantime?.. Which for me means investing in another technology other than Elm, when what Evan is working on sounds like what I actually want (Just thinking out loud).
@evancz i can’t pretend to understand what its like to be on your side of things (i.e. a language creator, for a language with a substantial community.) However, anyone who has ever estimated a timeline for a supposedly straightforward project knows it can be difficult to impossible, and I’m sure what your working on is not straight forward… would you be willing to offer a tentative rough ballpark estimate on a release date, subject to correction?..or if not, perhaps an idea of when the backend work might be discussed publicly?
I think this interview from 2 months ago might answer your questions. At 12:20 specifically, Evan talks about why development is happening privately.
If you’d like an estimation of when things are released, you can look at Elm’s roadmap. It explains how setting artificial dates in the future as deadlines can prevent you from exploring and developing good things you wouldn’t have found otherwise.
TLDR for both: No promises about timelines or openness. Open source is often a single person’s labour of love, and you can’t expect them to behave the same as a Silicon Valley unicorn.
In the absense of any timeline whatsoever, I guess I’ll stop wasting my time thinking about beautiful Elm on the backend and choose some other tech… (like fullstack Gleam) even thougn it seems Evan’s work may possibly be released soon, and sounds like it would be really amazing.
For now i think its best to take Elm for what it is and not to base any decisions on what it might be in the future.
It may be better to go with something that already exists and supports your use case. But…
elm-pages already has support for “backend tasks” which make doing backend in Elm possible.
It is also not difficult to roll your own solution. I have this package elm-serverless 4.0.0 which is due an update.
To get started with a simple set up, all your really need is to define a pair of ports, one for HTTP requests in, and one for HTTP responses out. Then run under node. That is basically what the update to elm-serverless is going to be - instead of a custom Program builder, it will just be a pair of ports for HTTP.
If you want to make HTTP requests, you will need the xmlhttprequest implementation from elm-serverless to run under node.
One thing to note about what Evan has been working on, as I understand it, is that it may be tied to Postgres. I love Postgres, but its not always the database that I use. So in some ways I am already thinking that it might not be something that I am interested in using - since I would likely prefer a database agnostic way of working. That said, no reason not to use whatever language/compiler improvements that might be coming, and ignore the Postgres part if it is not appropriate to the situation. But also, I don’t feel I need to be blocked waiting on Evan to make progress.
Why would you want to go down the route of using Elm on the backend? For me it was to be able to do so-called “isometric” code. I have some very complex logic written in Elm that runs in the UI, but I also need to run that exact same logic on the back-end, in order to keep a back-end model in synch accross many users. I did not want to have to implement this code in 2 different languages, so back-end Elm it is.
I can recommend elm-concurrent-task 1.1.1 for running elm on node. There is also a realworld implementation with elm-concurrent-task: GitHub - andrewMacmurray/realworld-backend-elm: Realworld API backend implementation in elm
elm-procedure 1.1.1 is worth mentioning here too.
I looked at elm-concurrent-task and elm-procedure and decided that I would go with elm-procedure. The reason for my choice is that e-c-t requires your tasks to be synchronous functions that you bundle into a task register to call from Elm. e-p just works with regular ports for Cmds and Subs in the usual Elm style. As I already had ports for code written in an asynchronous style it made sense for me to use e-p. e-p does not have a concurrent executor like e-c-t does.
Both are useful packages to know about for backend work.
You might also look at https://www.lamdera.com/, which supports full-stack elm applications.
I’m curious : how do you talk to an SQL database with elm on the backend ? Do you have to use PostgREST or is there a more direct way?
PostgREST would be a good way of doing it. Bear in mind that elm/http uses xmlhttprequest, so you need to patch that on NodeJS, and then you can use elm/http to make requests from your Elm backend.
There are no native database drivers.
I use this in some of my projects to generate type-safe SQL queries:
It’s not an official package yet but it might give some inspiration.
There is also a pg_graphql plugin for Postgres, for example, so you can use elm-graphql or elm-gql to work with a Postgres database. Or a middle-ware product like Hasura in front of your SQL database, which also exposes GraphQL and/or REST interfaces. Lots of options.
As Evans said in his last interview, he will release it when he its ready.
I think beyond ELM in the backend that would be good, I guess an agnostic engine to render Elm from any backend would be better, similar to htmx, an lib that can be implemented in any BE would be great.