3 ms·

Phoenix is quite nice if you're coming to it from a dynamically-typed environment, but I'd strongly dispute that its type system is "good enough" at large (huma

Phoenix is quite nice if you're coming to it from a dynamically-typed environment, but I'd strongly dispute that its type system is "good enough" at large (human, not technological) scales. Phoenix itself makes good decisions in a lot of places but it relies on things like Ecto for database manipulation, which (as just one example) is absolutely not enough for substantiative, human-scalable development--your "minimal testing" is my, as even a comparatively easygoing TypeScript-down-the-stack enjoyer, a whole lot of extra stuff. It also faces impedance mismatch with a lot of cloud tooling--which is not a disqualifier by itself and BEAM might not even be wrong, but most Elixir-in-anger systems I've seen end up abandoning much of the benefit of BEAM clustering and running a bunch of horizontally scaled web applications because they've got containers to manage and it fits the overall get-it-out-the-door plan better. This makes things like "just add another genserver" not really map to reality all that well, though of course genservers are a good layer of abstraction and modularization on their own. LiveView is great, though. I am hopeful for React server components and server actions to continue to mature; they're promising as it is.

cultofmetatron 3y ago
> is absolutely not enough for substantiative, human-scalable development you'll have to elaborate there. we have a pretty large codebase at this point that serves 3 different apps. granted our engineering staff is small but thats exactly what makes elxiir so great. It lets you build scalable infrastructure with a small team of humans > most Elixir-in-anger systems I've seen end up abandoning much of the benefit of BEAM clustering and running a bunch of horizontally scaled web applications because they've got containers to manage and it fits the overall get-it-out-the-door plan better. containers and clustering are not mutually exclusive. we run a elxiir cluster and take advantage of that with shared data and the ability to send mesages between each machine in pure elixir. At the same time, each vm is running inside a docker container managed with kubernetes. they work well together. we had one instance where a vm went down and kubernetes immediately brought it back up followed with it connecting to its peers.

cultofmetatron 3y ago

> is absolutely not enough for substantiative, human-scalable development you'll have to elaborate there. we have a pretty large codebase at this point that serves 3 different apps. granted our engineering staff is small but thats exactly what makes elxiir so great. It lets you build scalable infrastructure with a small team of humans > most Elixir-in-anger systems I've seen end up abandoning much of the benefit of BEAM clustering and running a bunch of horizontally scaled web applications because they've got containers to manage and it fits the overall get-it-out-the-door plan better. containers and clustering are not mutually exclusive. we run a elxiir cluster and take advantage of that with shared data and the ability to send mesages between each machine in pure elixir. At the same time, each vm is running inside a docker container managed with kubernetes. they work well together. we had one instance where a vm went down and kubernetes immediately brought it back up followed with it connecting to its peers.