Ask HN: Are you satisfied with Elixir or do you regret choosing Elixir?

Currently on my 3rd year as CTO of a startup. I chose elixir for the greenfield project because we wanted realtime sync for all devices and the smaller projects I worked on before in elixir went off without a hitch. I also found its concurrenly handling and performance far superior to node and I was producting far less bugs due to its functional nature.

3 years in and I'm very satisfied. There are a few epics we took on that would have been much more expensive to do in go or node. For example, we made a partnership with a credit card device terminal. Their interface required one persistent webocket connection per restaurant. IN another language, I would have had to coordinate with my devops guy to have a dynamic system to allocate a process for each of our accounts and route that to our devices. The intended use case were on premise POSes so our cloud based solution wasn't somethign they had planned on supporting.

Anyways, I was able to configure horde and a dynamic registry to boot up a process for each active account and automatically resserect on crash. Since pubsub is built in, It was easy to pass along data from it to all the devices over the channels interface. Best part is it was all doable within the code base running without any changes to out deployment.

Overall, I've been happy with elixir. the only bg downside is its gotten a bit boring. Things just work which leaves me spending time on rust in my free time when I want a challenge.

If you don't co-locate related state and logic, ensuring that each piece of state reaches the correct components becomes a logistical nightmare at scale (either needs to traverse many intermediate components or needs to be exposed globally to all components).

If you don't allow components to mutate state locally, you need a strategy to distribute all your data directly from external stores to the correct components and also a strategy to send state updates back to the relevant stores. When you have multiple components which share some of the same data, this is impossible to do in an efficient and reliable way because of the latency between the external store and the components (components risk overwriting each other's data by sending conflicting updates, for example).

It's a logistical nightmare, because, without co-locating state with logic in some components, you cannot control how state updates are combined and then applied onto the external store. Components have no awareness of each other so they cannot coordinate. Every read and write has to go through the external store which is both inefficient and unreliable when you factor in latency. (The idea of caching violates FP principles).

The advantage of co-located state is that it can be updated synchronously without any latency so there is no possibility of conflicts.

As noted by the parent, latency is certainly a consideration when using such tools, but there are a myriad of libs and techniques that can be leveraged to help you build great user experiences with StimulusReflex and LiveView. You just need to consider your options and architect accordingly.

Note also that the expo demos for StimulusReflex are incredibly old (a few major versions behind at this point) and were created in haste to help people grok concepts via example. They were never intended to be a canonical guide of how to best architect such apps at scale. We're considering taking the expo site offline in favor of more specific and better architected demos.