
RailsConf 2016 - Rails to Phoenix by Brian Cardarella
About this video
Brian Cardarella's RailsConf 2016 talk on why and how teams can move from Rails to Elixir and Phoenix. It covers performance gains without losing productivity and how to introduce Phoenix in an organization.
Why it appears in the archive
HN points Rails developers to it as a real-world case for migrating to Phoenix, backed by numbers.
AI-generated summary and labels from the source dataset; verify important details against the video. Source & credits.
From the Hacker News discussion
I'd say you really should have a look into [VIDEO] . A really great presentation, including numbers and real world backup data, plus conceptual overviews.
Read original comment ↗I can't speak about experiences with Ruby/Rails since I don't use that stack but I can give you advice about both Scala and Elixir. I used to be a Java programmer and fell in love with Scala and functional programming. Scala helped me do things that I couldn't do so easily in Java in a more explicit way. However, I found doing web development with Scala to be more cumbersome than helpful but was still a great learning experience for FP in general. Since late 2015, I've been all-in on Elixir. Elixir does everything I wanted to Scala, specifically pattern matching everywhere and how powerful it is. Since Elixir uses BEAM, it's incredibly lightweight but can scale without any configuration. The community around Elixir is fantastic and helpful and everyone is growing together. Brian Cardarella (well known in the Elixir community) gave a conference talk at Rails Conf about switching from Rails to Phoenix (Elixir's goto for web) and that may be a good start to empower you to make a decision: [VIDEO] . A great resource for learning Elixir if you choose that route is Programming Elixir 1.2 by Dave Thomas. It's a great book for beginners and can help with you understand Elixir semantics and functional programming.
Read original comment ↗If you're looking for a reason to migrate from a stack like Ruby/Rails to Elixir/Phoenix you should check out my RailsConf talk on that exact subject: [VIDEO]
Read original comment ↗I started watching RailsConf 2016 - Rails to Phoenix by Brian Cardarella [VIDEO] as suggested in some comment yesterday and it has some stuff on whether learning Elixir is worth the time. Good talk in general. Edit link to comment thread: [LINK]
Read original comment ↗I posted this in the Elixir 1.3 thread but also relevant here. If you're looking to understand why you/your company may want to consider migrating from Rails to Phoenix you can check out my RailsConf talk on the subject [VIDEO]
Read original comment ↗We've moved all of our backend offerings from Rails to Elixir/Phoenix. Despite some questioning the value of anything below 100ms response times there is a lot of data backing up the idea that Elixir/Phoenix can lead to a more maintainable and more economical solution. I spoke about this recently at RailsConf: [VIDEO] Don't get me wrong, I think Rails is an amazing technology but it doesn't fit the use cases and demands our clients have today.
Read original comment ↗> but Erlang/beam code is not that fast. True, no doubt. You wanted a comparison why phoenix is faster than rails. And simply doing things at compile time reduces work at runtime. In Ruby, all Metaprogramming must be done at runtime, for example via method_missing trickery (been there, done that). > Ruby's templates are parsed into code that stays in memory, too, so it's not like they're re-parsed each and every time. This is actually not the same. A single immutable blob of binary (elixir strings) which is shared throughout the whole application can leverage hardware caching better. Jose could answer this probably better than I can do. > someone should dissect these things in a real-world-ish application to see what's actually true. Moz.com recently had fun with Elixir [1]. You may also have a look at [VIDEO] from latest RailsConf. > The claim was 'fast' though Well at least I know that BEAM processes are far lighter than eg: goroutines. Also there is a per-process GC, so no "stop the world", much smaller units for individual collects, and when a process finishes before the heap grows full, it can be discarded directly. > maintainable, which seems curious given that there are no really old Phoenix apps out there Fair enough. Personally I'd not wait until a software stack is a decade old before even considering it. I have at least worked on Elixir/Phoenix projects for many months now on-off with multiple colleagues, and it was/is still pure joy. Aesthetically pleasing syntax
Read original comment ↗