It looks like the SAFE stack folks (F#) are looking into the possibility of ‘server-side TEA’ with Elmish.Bridge. I haven’t used it myself so I’m not sure how well it works or how far along it is in development.

Maybe there are some algorithm out there to optimize the nodes position by minimising crossings/overlaps between edges? I believe that graphviz uses something like that, but I may be wrong as I have not used it seriously since quite some time?

The latencies on this concurrent connections benchmark are of the order of tens of milliseconds. Note the scale on my graph is in micro-seconds, and this was measured using a network tap so its the real network message in/out latency to the wire. This is 3 orders of magnitude faster than your typical web server, 100% in Java and relies heavily on mutability to avoid creating garbage. Of course, we are comparing different tests here, but I put it up just to show what some people are striving for on the server.

That said, your benchmark does show that in many cases immutability isn’t a bottleneck, I am pleasantly surprised by it. Certainly good enough for the web, just perhaps not for electronic trading or HPC.

Extreme efficiency can be important in HPC, because a factor of 10 speed up can mean you have 10x less servers to pay for. In many cases all the difference between a profitable operation and an unprofitable one.

Erlang / Elixir is heavily used for low-latency and scalable web services (like whatsapp). Erlang doesn’t support mutability at the VM level.

A lot of backends today does not need a computational fast language, but a language which is good at concurrency. Functional languages tend to be great at concurrency. So there’s no reason Elm couldn’t contend in this space someday in the future.

Web servers written in Java can be extremely efficient with low-latency and high throughput and handling thousands of connections - in part because of mutable arrays. This feels like something that Elm on the back-end could never compete with.

Here is a concurrent connections benchmark showing Elixir and Clojure (both based on immutable data structures) outperforming every garbage-collected mutable-arrays language in the benchmark. (Only C++ outperformed the immutable-collections languages, which is presumably less about data structure choice and more that C++ never has to pause for garbage collection.)

Assuming mutability of sequential collections were somehow a significant bottleneck in a server’s ability to do low-latency high throughput processing of many concurrent connections, the focus of any concern should be whether Java’s slow and clunky mutable arrays can hope to compete with the obvious superiority of Elixir and Clojure’s immutable collections.

Just to be super clear about it: the real point here is that mutable arrays don’t make a difference in this domain. It’s all about how the servers and VMs are architected.

I actually think an interesting question is more “what would Elm look like on the server?”

I think the simplest and least general role that Elm can play on the back-end right now, is server side rendering with rehydration on the client. There is no official support so its a bit hacky, but its been shown it can be done.

This is a really attractive way to use Elm for me, because I was able to replace my CSS, SASS, handlebars templates and a mish-mash of javascript bits and pieces with just Elm.

I was telling a Java programmer about Elm recently. A Java programmer who works on low-level Java code for HPC, He didn’t like that Elm was immutable giving the example of quick sort. Quick sort is only quick sort if you are actually using mutable arrays - you can write the algorithm on top of the immutable HAMT arrays we have in Elm, but its not really the same algorithm. I did explain to him that the performance of Elm is very good, good enough for its domain generally.

But its a fair point. Web servers written in Java can be extremely efficient with low-latency and high throughput and handling thousands of connections - in part because of mutable arrays. This feels like something that Elm on the back-end could never compete with.

I imagine that a back end Elm would focus more on higher level things, like writing business logic or web APIs. When I think of all the service logic I’ve written or seen in Java, I now think of how much better that could would be in Elm.