4 ms·
> The problem is that stateful connections suck and create artificial complexity when you don’t need them. Instead of managing the state of your app you’re now
by dnautics 6y ago
> The problem is that stateful connections suck and create artificial complexity when you don’t need them. Instead of managing the state of your app you’re now managing the state of your app and a connection to a remote server. HTTP is a stateless protocol on top of a stateful socket connection. It wasn’t designed this way by accident.
Seriously, try phoenix liveview if you haven't already. These problems of dealing with stateful connections over questionable tranport and managing them are what the Erlang vm were designed for, and phoenix was designed by rails core team members.
- cortesoft 6y agoIsn’t the issue, though, how do you scale this out? HTTP app servers are great... you can add and remove them at will, based on load, and customers never know the difference, because it only takes a few seconds after not accepting new connections for the existing ones to drain. If you instead have servers holding state, those servers become a lot less ephemeral. In addition, HTTP has built in caching, which is a HUGE benefit for scale.
- ricketycricket 6y agodnautics isn't wrong. Even the issues you bring up are addressed by Erlang/OTP. Distributed Erlang with 10K nodes, hot code reload, etc.
- querulous 6y agothe only people who think distributed erlang is good are people who have never done anything nontrivial with it
- dnautics 6y agoI work on a system with an distributed erlang service mesh.
- hydroxyethane 6y agoCould you explain why that is to someone (me) has never done anything nontrivial with it? Thanks.
- querulous 6y agoi'd encourage everyone thinking about using it to go read the code (it's fairly approachable) but in short it just connects each node in the cluster to each other node in the cluster via a tcp connection and sends packets between them. there's almost nothing as far as protocol, queue management, congestion control or traffic management. it's discovery mechanism is just shipping lists of peers around. pretty much any competent programmer with networking experience could put together something comparable it works okay in small clusters on reliable low latency networks but it's not a replacement for an actual network mesh there have been attempts to fix it but none have really found adoption. i think this is the most notable: https://lasp-lang.readme.io/docs https://lasp-lang.readme.io/docs
- hydroxyethane 6y agothanks for your answer so basically it relies on plain TCP and its reliability features. If you need something more sophisticated you gotta do it yourself within the application code (or using libs).
- dnautics 6y agoElixir tends to have sophisticated libraries around what you really want that are plug and play with distributed erlang. (Phoenix pubsub/tracker/presence). Horde/swarm, etc.