5 ms·

After you work with Phoenix/LiveView is soo hard to come back to anything else. I love the fact it's very opinionated and most times there's a right way to do t

by deofoo 3y ago

After you work with Phoenix/LiveView is soo hard to come back to anything else. I love the fact it's very opinionated and most times there's a right way to do things. LiveView is game changer, same user experience (even better) with 10x better developer experience. No much dual state management and things just work.

quickthrower2 3y ago
I keep seeing almost this exact comment from different people when phoenix is mentioned. It is quite a learning curve I might try again one day. What makes this better than say a traditional ruby/rails or django app with maybe some htmx to save doing the JS side of things?
- fredrikholm 3y ago
  BEAM (ErlangVM). This video explains it better than I can: https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE
  - yurishimo 3y ago
    I knew which video this was before I clicked on it. It's a brilliant demo of the power of the BEAM and how it can be leveraged for web applications.
- ch4s3 3y ago
  You get a concurrent request processing spread across all of your cpu/vcpu cores out of the box. The fallback controller pattern for error handling is incredible for boilerplate error handling. Worst case latency is very stable. The query builder/data mapper, Ecto, is IMO far better than ActiveRecor being more explicit and prevents N+1s out of the box. Eex is built on compile time linked lists rather than run time string interpolation like the options in Rails and Django.
  - ativzzz 3y ago
    My opinions on this as a rails dev > You get a concurrent request processing spread across all of your cpu/vcpu cores out of the box That's neat, but this doesn't matter until you reach serious scale, as scaling a rails app horizontally by throwing more server instances works for a long time > The fallback controller pattern for error handling is incredible for boilerplate error handling Sounds just like controller inheritance in rails > Worst case latency is very stable So is rails, worst case latency is generally caused by slow SQL requests or having to render complex documents (which can be offloaded to the background easily) > The query builder/data mapper, Ecto, is IMO far better than ActiveRecor being more explicit and prevents N+1s out of the box I don't have a problem with ActiveRecord, and while N+1s are easy to create, there are a ton of tools to help prevent these in rails. Can be a hinderance for junior devs or devs without rails experience though Once things get complex, you're gonna be writing SQL directly anyway > Eex is built on compile time linked lists Cool but sounds irrelevant for 99.9% of cases, string interpolation isn't what causes rails apps to be slow
    - ch4s3 3y ago
      Let me quickly address these to the best of my ability, knowing Jose's answers are probably better :) > That's neat, but this doesn't matter until you reach serious scale, as scaling a rails app horizontally by throwing more server instances works for a long time You can do that, but its cheaper to get more out of each cpu and Elixir/BEAM give you that for free with a similarly flexible dynamic language. > Sounds just like controller inheritance in rails Not exactly, it works on the basis of pattern matching and the Fallback functions are included into the plug (think Rack) pipeline. This makes it faster and you don't have the problems of inherited methods stepping on each other. You also get to match on really specific shapes and cases to handle really granular errors without much effort or cognitive overhead, and you don't need to do things like catching errors like people often do in Rails controller error handling with rescue_from. > So is rails, worst case latency is generally caused by slow SQL requests or having to render complex documents (which can be offloaded to the background easily) You elixir application will often be doing things like background work and managing a key value store. You can do all of this and saturate the cpu without latency exploding. The scheduler in the BEAM will de-schedule long running processes and put them in the back of the run queue. Again, you get this for free. > I don't have a problem with ActiveRecord, and while N+1s are easy to create, there are a ton of tools to help prevent these in rails. Can be a hinderance for junior devs or devs without rails experience though That's all well and good but it's a nice feature in Ecto. Ecto also hews closer to SQL, and you can compose reusable pieces of queries in a way that is far more manageable than anything ActiveRecord scopes offer. We (where I work) write anything short of complex CTEs in Ecto's DSL, a lot of stuff I'd never try to do with ActiveRecord. It's just a lot closer to SQL and gets some nice compile time assurances. > Cool but sounds irrelevant for 99.9% of cases, string interpolation isn't what causes rails apps to be slow Rendering collections of nested partials in Rails has always been slow and eats memory. This isn't an issue with EEX. They also render faster locally.
fredrikholm 3y ago
Amen. I'm always amazed by how malleable the BEAM and the patterns built on it can be. I don't think anyone predicted Erlang to (IMO) reign supreme in frontend development. I say this having written tens of thousands of lines of React and Svelte in production, on top of all the hobby projects over the years.
- sph 3y ago
  In hindsight it makes sense. Networked servers need resilience to failure, to keep running, and to make concurrency as painless as possible, especially as CPU cores count increases. Off the top of my head there's not many languages that can easily handle a million processes on consumer hardware, while the developer only has to think in single threaded mode because deadlocks and data races are literally impossible. If you're building a server of any kind, the BEAM is the bee's knees. You can always resort to using a sidecar process or a Rust NIF for the high performance hot path.
  - fredrikholm 3y ago
    > million processes ... think in single threaded mode This is a big component of the secret sauce. Writing top down, happy path code as if you're just exploring an idea and then decide to scale it to distributed nodes without changing the implementation is just absurdly practical and blows every other VM out of the park.
  - ativzzz 3y ago
    > while the developer only has to think in single threaded mode because deadlocks and data races are literally impossible Does Elixir somehow automatically solve the case where a row in a database is loaded into memory simultaneously across multiple requests and a value is incremented? (can be easily solved with row locking, but still needs to be done explicitly at the application level)
    - sph 3y ago
      Usually one would use Redis for this problem, and you have a Redis-like system (but based on pattern matching) native to OTP, ets. If you need a global, cluster wide counter, spawn a process with name {:global, :whatever} and let it be the source of truth for this value. Depending on the problem, there are multiple approaches you can take. And a single Postgres instance is able to deal with massive concurrency, there might not be any need for premature optimization when SQL transaction could do.
sodapopcan 3y ago
While I agree wholeheartedly, I do want to point out that while it has opinions in its high quality documentation, it is in no way opinionated in the same way that something like Rails is. You can use Phoenix in the same way you'd use Sinatra or Flask or the like [0], there are just no generators for it. I just wanted to bring this up in case anyone would be put off to try it who is afraid opinionated frameworks. However, if you prefer the opinionated option and want to be given clear guidelines on how to solve many common problems, Phoenix does indeed have you covered :) [0] https://gist.github.com/Gazler/b4e92e9ab7527c7e326f19856f8a974a https://gist.github.com/Gazler/b4e92e9ab7527c7e326f19856f8a9...
- deleted 3y ago
  [deleted]
Dowwie 3y ago
What have you built with Phoenix?

by deofoo 3y ago

quickthrower2 3y ago

I keep seeing almost this exact comment from different people when phoenix is mentioned. It is quite a learning curve I might try again one day. What makes this better than say a traditional ruby/rails or django app with maybe some htmx to save doing the JS side of things?

fredrikholm 3y ago
BEAM (ErlangVM). This video explains it better than I can: https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE
- yurishimo 3y ago
  I knew which video this was before I clicked on it. It's a brilliant demo of the power of the BEAM and how it can be leveraged for web applications.
ch4s3 3y ago
You get a concurrent request processing spread across all of your cpu/vcpu cores out of the box. The fallback controller pattern for error handling is incredible for boilerplate error handling. Worst case latency is very stable. The query builder/data mapper, Ecto, is IMO far better than ActiveRecor being more explicit and prevents N+1s out of the box. Eex is built on compile time linked lists rather than run time string interpolation like the options in Rails and Django.
- ativzzz 3y ago
  My opinions on this as a rails dev > You get a concurrent request processing spread across all of your cpu/vcpu cores out of the box That's neat, but this doesn't matter until you reach serious scale, as scaling a rails app horizontally by throwing more server instances works for a long time > The fallback controller pattern for error handling is incredible for boilerplate error handling Sounds just like controller inheritance in rails > Worst case latency is very stable So is rails, worst case latency is generally caused by slow SQL requests or having to render complex documents (which can be offloaded to the background easily) > The query builder/data mapper, Ecto, is IMO far better than ActiveRecor being more explicit and prevents N+1s out of the box I don't have a problem with ActiveRecord, and while N+1s are easy to create, there are a ton of tools to help prevent these in rails. Can be a hinderance for junior devs or devs without rails experience though Once things get complex, you're gonna be writing SQL directly anyway > Eex is built on compile time linked lists Cool but sounds irrelevant for 99.9% of cases, string interpolation isn't what causes rails apps to be slow
  - ch4s3 3y ago
    Let me quickly address these to the best of my ability, knowing Jose's answers are probably better :) > That's neat, but this doesn't matter until you reach serious scale, as scaling a rails app horizontally by throwing more server instances works for a long time You can do that, but its cheaper to get more out of each cpu and Elixir/BEAM give you that for free with a similarly flexible dynamic language. > Sounds just like controller inheritance in rails Not exactly, it works on the basis of pattern matching and the Fallback functions are included into the plug (think Rack) pipeline. This makes it faster and you don't have the problems of inherited methods stepping on each other. You also get to match on really specific shapes and cases to handle really granular errors without much effort or cognitive overhead, and you don't need to do things like catching errors like people often do in Rails controller error handling with rescue_from. > So is rails, worst case latency is generally caused by slow SQL requests or having to render complex documents (which can be offloaded to the background easily) You elixir application will often be doing things like background work and managing a key value store. You can do all of this and saturate the cpu without latency exploding. The scheduler in the BEAM will de-schedule long running processes and put them in the back of the run queue. Again, you get this for free. > I don't have a problem with ActiveRecord, and while N+1s are easy to create, there are a ton of tools to help prevent these in rails. Can be a hinderance for junior devs or devs without rails experience though That's all well and good but it's a nice feature in Ecto. Ecto also hews closer to SQL, and you can compose reusable pieces of queries in a way that is far more manageable than anything ActiveRecord scopes offer. We (where I work) write anything short of complex CTEs in Ecto's DSL, a lot of stuff I'd never try to do with ActiveRecord. It's just a lot closer to SQL and gets some nice compile time assurances. > Cool but sounds irrelevant for 99.9% of cases, string interpolation isn't what causes rails apps to be slow Rendering collections of nested partials in Rails has always been slow and eats memory. This isn't an issue with EEX. They also render faster locally.

fredrikholm 3y ago

Amen. I'm always amazed by how malleable the BEAM and the patterns built on it can be. I don't think anyone predicted Erlang to (IMO) reign supreme in frontend development. I say this having written tens of thousands of lines of React and Svelte in production, on top of all the hobby projects over the years.

sph 3y ago
In hindsight it makes sense. Networked servers need resilience to failure, to keep running, and to make concurrency as painless as possible, especially as CPU cores count increases. Off the top of my head there's not many languages that can easily handle a million processes on consumer hardware, while the developer only has to think in single threaded mode because deadlocks and data races are literally impossible. If you're building a server of any kind, the BEAM is the bee's knees. You can always resort to using a sidecar process or a Rust NIF for the high performance hot path.
- fredrikholm 3y ago
  > million processes ... think in single threaded mode This is a big component of the secret sauce. Writing top down, happy path code as if you're just exploring an idea and then decide to scale it to distributed nodes without changing the implementation is just absurdly practical and blows every other VM out of the park.
- ativzzz 3y ago
  > while the developer only has to think in single threaded mode because deadlocks and data races are literally impossible Does Elixir somehow automatically solve the case where a row in a database is loaded into memory simultaneously across multiple requests and a value is incremented? (can be easily solved with row locking, but still needs to be done explicitly at the application level)
  - sph 3y ago
    Usually one would use Redis for this problem, and you have a Redis-like system (but based on pattern matching) native to OTP, ets. If you need a global, cluster wide counter, spawn a process with name {:global, :whatever} and let it be the source of truth for this value. Depending on the problem, there are multiple approaches you can take. And a single Postgres instance is able to deal with massive concurrency, there might not be any need for premature optimization when SQL transaction could do.

sodapopcan 3y ago

While I agree wholeheartedly, I do want to point out that while it has opinions in its high quality documentation, it is in no way opinionated in the same way that something like Rails is. You can use Phoenix in the same way you'd use Sinatra or Flask or the like [0], there are just no generators for it. I just wanted to bring this up in case anyone would be put off to try it who is afraid opinionated frameworks. However, if you prefer the opinionated option and want to be given clear guidelines on how to solve many common problems, Phoenix does indeed have you covered :) [0] https://gist.github.com/Gazler/b4e92e9ab7527c7e326f19856f8a974a https://gist.github.com/Gazler/b4e92e9ab7527c7e326f19856f8a9...

deleted 3y ago
[deleted]

Dowwie 3y ago

What have you built with Phoenix?