Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Phoenix framework is what you're looking for. I can build out mvps as quickly as in django/ror but the runtime perf is on par with go or rust (for io bound stuff)

Been in operation for 3 years and scaling has come out though incremental improvements. no large scale rewrites needed.

1. out of the bod req/res time is fast

2. multiclustered websockets come out of the box with channels for subscribing to events

3. easy to spin up a "service" as a genserver

4. best ecosystem of tooling for building asynchronous and parrallel systems

5. liveview is THE standard for reactive frontend frameworks where you are updating in real time from serverside html. (no shade thrown on rails but hotwire is a joke by comparison) liveview processers are persistent for the live of teh user session and can subscribe to server side events so you can have a user make a request, push the task into the background and update the ui when its completed with very little code.

ok so type safety isn't at ocaml, rust or haskell level but its good enough that Its rarely the source of bugs assuming you perform even minimal testing.



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.


> 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.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: