I just listened to that podcast. Every time DHH is asked about Phoenix, which happens fairly often I’ve noticed, he comes out with some subtle backhanded compliment. Something like “it’s very good if you like that sort of thing”, “…but I would never need or want something like that”.
Anyway while I’m a fan of many of the things DHH says that doesn’t mean I agree with all of his opinions. Like Rail’s approach to js in general.
If you remember Rails’ history with approaches to js it started out with Prototype.js then Scriptaculous and RJS (horrible) then jQuery got baked in. Each step of the way things have been meshed together in a majestic mess throwing separating concerns out of the window. While each new thing that comes along we’re told it’s the new Kool-aid.
Also while the asset pipeline was wonderful to begin with it has taken years to work around it so that we could use cool ES6 stuff (thank you Webpacker) without very nasty hacks.
in that podcast DHH was pretty scathing about React and Redux, which is his opinion and fine. I don’t think he understands either of these libraries very well though, from the complaints he was raising. While I often agree with his scathing opinions trying to use modern javascript libs with Rails until very recently (mid 2017) hasn’t been a very good fit.
You basically had choice between doing a completely separate client side app and just using rails as a json api or trying and probably failing to hack your way around the asset pipelne then giving up and doing some jQuery sprinkles because life is too short.
I think I’m probably ranting because the bit that really annoyed me was DHH pronouncing Jose name so wrong at the beginning
Hey all. I’m one of the panelists on the Ruby Rogues podcast and was one of the interviewers of DHH. I really enjoyed all the comments so far on this topic. I have been on the fence with switching my main focus from Rails to Phoenix for quite a while. This interview, to me, solidified my dedication to Ruby on Rails. But honestly, if I was to start over, I’d go the Phoenix / Elixir path 100%.
What Rails provides and has provided for so long is a pre-determined way for developers to solve problems. I understand that with the patterns and conventions Phoenix has, it’s not very different from that. But for me, Ruby is easier. It’s very much a matter of preference.
If I look back at my 20 years of development, I can see that most projects I’ve ever built have not required multi-processing power nor heavy real-time functionality. I am not sure if that will change in the future, but as long as it hasn’t, there’s no reason to switch.
That being said, I do believe that Phoenix/Elixir is on the upswing and Ruby/Rails is on the downswing.
I do agree with him 100% on the front-end frameworks. I’ve nearly quit a job b/c of the complexity that those bring (especially Redux).
Finally, I hope you still enjoy the Ruby Rogues podcast. We have taken a new focus on content and hopefully provide enough entertainment value for ongoing listenership.
Are you sure about that? Please, allow me to reframe the question slightly: have you ever used some form of caching (Redis, memcached, etc.) to get results faster than you could have from another source (possibly a RDBMS)?
I’m suggesting that it’s possible that you’ve had the need, but didn’t recognize it at the time. Just a thought.
That’s actually what I sort of meant when I previously wrote the following:
I think we should be mindful to not attack this point too much, though, because the truth is that there are tons of people that make due with exactly this method of installing a 3rd party product that handles something for them and then outsourcing the work to it. It’s just a different way of doing things and I think this community predominantly is comprised of people that would rather make their own, self-contained, understandable version that does exactly what they want it to.
You are right. Almost every project I’ve ever built uses Sidekiq (or it’s predecessors). This is a huge benefit of the Phoenix/Elixir ecosystem that Rails needs to bolt-on.
Erlang (and Elixir) is not just about heavy real-time and massive concurrency. In my opinion a huge benefit comes from the fact that you can implement many features directly in Elixir and run them in the same OS process where you’re running the rest of your system. This leads to a much more homogeneous solution which is easier to develop, extend, test, deploy, and manage in production. Not to mention that onboarding of new developers is easier, since they need to learn just one technology to work on the system. That’s a bunch of wins in all phases of the development process.
I’ve been recently working on a custom CI service for our system. While the service benefits from concurrency, we don’t need massive concurrency. At peak times, no more than 100 processes will be running. Also, real-time is not relevant in this case. A few minutes latency is perfectly fine for us.
Still, Elixir helped us significantly reduce the technical complexity in this service. The service has the following technical needs:
periodical as well as on-demand communication with a 3rd party service over REST & GraphQL API
queuing, pooling, rate-limiting
persistence
fault-tolerance
in-memory statefulness
All of these are handled directly in Elixir, in the single project, and there is only one OS process running in production. No Redis, cronjob, sidekiq or any other 3rd party tools are needed in this particular case.
It’s quite obvious that DHH will say that Rails is the best framework in the world and it’s his opinion. I saw many programming languages and even more frameworks (imagine ColdFusion on wheels as a RoR clone ;)) and tbh I like Elixir the most with the Phoenix. I like everything related to them - from top to bottom, from FP to perfect syntax for my eyes.
@sasajuric I agree with you in 100%. This is the real advantage of using Elixir - you have cache, cron and worker processes simply in one language and they do the job! Btw, I use your con_cache in my work’s project
Also what I like in Elixir & Phoenix is the community with the leaders - @josevalim and @chrismccord don’t need to be race drivers like DHH. They are both awesome without any noisy things around them
Also, I think everybody should watch Saša’s talk about the runtime capabilities of BEAM and why it’s a great platform for actually maintaining systems. I had the chance to watch it live in Sofia during PartialConf and it’s definitely a great advocacy for Elixir (and the whole BEAM).
I disagree with this notion. I see it as a way to only use the technology (Ruby in DHH’s case) you’re comfortable with rather than what does the job well. Front end frameworks like React & Redux produce a significantly more understandable codebase and a richer user experience. Of course you can build simple pages with no functionality slightly faster with server side rendering, but this isn’t the 90s and very few pages do that (even if they intend to start that way). Plus I’ve seen too many times the ease with which server code and view code get intertwined, and its my belief that by using a different language it creates a proper separation of concerns which you wouldn’t have otherwise and this leads to a more clean implementation overall.
In my opinion, DHH’s logic doesn’t fit with my experience. I’ve had hard to diagnose bugs caused by chains of active record callbacks that I didn’t conceive were tied together, or cache invalidation issues caused by the cache everything attitude put forward by Rails. I’ve come across odd bugs even after 6 years of Rails professionally where I didn’t understand what was going on behind the scenes (take the << operator for instance that will persist your record if the parent is persisted but will just build it otherwise, a real kick in the nuts if you used first_or_initialize on the parent right before it) and even to this day its an occasional thing.
Rails is very magical and opaque about what it does for you whereas Phoenix and Ecto are very transparent and explicit about what they do for you. The difference means your blog post or 90 minute interview can make Rails look better, but in the day to day I much prefer simpler structure Phoenix and Elixir bring to the table.
Lots of SPAs are very fragile. Things you expect from a browser such as back button, middle/right click on links and form auto-completion often works poorly and inconsistent.
Heaps of SPAs or javascript heavy sites are slower and have a core functionality that is worse than a pure HTML solution and most work poorly on a bad connections.
The most robust and fast sites I use are pure HTML with a few parts in javascript. They also work without javascript.
Writing an SPA also requires re-inventing lots of things the browsers already do for you and in a non-standard way.
Is a well written SPA good to use? Of course. But they are far and few between.
Folks, there have been some comments directly on DHH as a person. Let’s please drop those and focus on the podcast content, otherwise we will lock the discussion.
When we talk about performance, it is common to think mostly about production but ignore that it causes a huge impact in development and deployment too.
I have written about the fallacies of web application performance before. Would you like your test suites to run at least 4 times faster with almost no effort? It is very likely you have at least 4 cores on your machine and 3 are sitting idle while your test suite runs. Even if you had one core, you would be able to get faster test suites because while one test talks to the database, another test could run.
In the comments section of the blog post above there is a very relevant comment from @michalmuskala that I will quote here:
I think the first point is the most important. I can’t stress enough how big of an impact an application that boots instantly and a test suite that runs fast have on development performance and developer quality of life.
I experienced this recently where I could directly compare generally similar Rails and Phoenix applications with a similar setup for testing - most of the tests were hitting the database and hitting it hard. The Phoenix application had about 1.5k tests that were running in about 30 seconds. The Rails app had about 1k tests running in a staggering 8 minutes.
And it is not only about faster tests. Sometimes we are forced to write more complex solutions to work around performance limitations. @JEG2 already mentioned that having to frequently resort to cache management (or caching layers) is one of such cases. If you don’t need Redis or similar, that will simplify development and deployment. @sasajuric also shared his experience on the matter.
And even without the performance benefits, I would say there are many other reasons to at least learn Elixir - or another functional language such as Clojure, Elm, OCaml or Haskell. There are concepts, such as the separation of side-effects and preference to immutability, that you will be able to bring to other languages and cause a positive impact on the code you write in any language.
In my opinion, having worked on wide range of projects, the headless back-end with universal JS front-end (“isomorphic” if you prefer) hits the sweet spot for flexibility, productivity, scalability, performance, user experience, dev experience, and maintainability.
For instance, using Nuxt.js (server-side rendering of Vue.js), and Phoenix as a GraphQL API; communicating over web socket. The persistent connection and JS chunking result in extremely fast page load times, and the flexibility to load additional (below the fold) assets afterwards (shortening TTI). Since the JS app is rendered first server-side, then you get your SEO benefit. No longer are you splitting your markup between back-end and front-end with two different templating languages. Once the page loads, it’s “hydrated” with the JS functionality (eg. routing, state management, etc.). Even from a dev-experience stand-point, live reloading is nice, but hot reloading is waaay better (using Webpack’s HMR to hot-swap JS/CSS modules; which maintains page state). I could go on and on. I haven’t even touched on PWA, desktop, and mobile apps leveraging much of the same codebase.
Pure back-end experiences just don’t hold a candle to the setup above IMO.
I don’t really buy the MVP argument, but I think that’s debatable, and largely dependent on the team. If you have a polyglot team that has worked in JS frameworks, then it’s not really an issue (IMO).
This has been my experience as well—having written mostly things which are closer to web apps than plain websites, I always prefer to have the clean separation of an API backend and a JS frontend. I find that using templates in a server language like Ruby or Elixir, especially when working in a team and in crunch time, ends up coupling the backend implementation to the frontend much more than I’d like.
I personally think that the distaste for many in the Ruby community for complex JS frameworks like Redux / React may have something to do with the total impedance mismatch between the out-of-the-box Rails way with strong conventions, and the DIY JS culture—I admit that to get something in Redux / React which will stand up to scaling and changing over time, you do need someone who has had significant experience already using these libraries—I’ve found that no amount of tutorials and blog posts can teach you The Right Way to do it. I can see why for someone used to the ease of setting something up in Rails or even Phoenix, that seems messy, complicated and unnecessary. I would describe React as having a “hidden learning curve”—it’s quite easy to read some posts and get started, but without experience and the ability to architect your system by choosing from the thousands of seemingly-similar parts available on npm, it’s likely that you’ll paint yourself into a corner.
I personally love Redux, and it immediately “clicked” for me when I started using it. I was immediately so much more productive than when I was using normal React state. I do think that having a “classical” background (a CS degree) as well as experience with a more functional way of doing things is a big part of whether Redux seems intuitive or not.
Ultimately, I think that for many teams whose focus for years has been RoR, HTML and CSS with splashes of jQuery, migrating to something like React without an experienced JS developer on the team may not be a good idea. I also do not think that the statically-rendered website is going to be dead any time soon. I do think, however, that what the React team is doing is amazing, and when treated as a separate software product worthy of dedicated developers with deep knowledge, React can produce some amazing results.
Probably not as big as any would think. Theres a good possibility that in 2018 that point will be mostly moot - Rails should run on Truffleruby (likely only a few months as they have made outstanding progress) and the speed and performance conversations will have to shift. Theres also a lot of third parties working on actor models for concurrency. Ruby could always scale - the cost just might have been more. If all goes well with Truffleruby’s implementations, I think many will find no compelling performance argument against rails. I see it surging upward again in usage. (That is NOT to say elixir will have no advantages)
DHH has always been right about startups and MVPs, Programmer joy and simplicity is what you need to get things done when you are small and unsure of the future. I still reach for ruby on rails 80% of the time - The ecosytem alone is reason to. If you are employed by a company that has its income assured and/or already have investor dollars then you can afford other considerations.
My place (at least for the time being) for elixir is to have something that I can reach for if I or one of my customers has a crazy (less than a quarter percentage point likelihood ) hit that has a good fraction of twitter scale users AND no monetization. Theres always been a divide in understanding DHH’s point of “fast enough”. Employees or companies that have captive users and a bank roll are less likely to get it. Entrepeneurs or those who work for them understand him completely as saying its profit per server not even how much you spend for servers. We don’t care about OOP vs functional - our goal is monetary success for our apps as fast as we can for competition reasons. For that Ruby is still pretty close to optimal and likely even more so if all goes well with Truffleruby.
You’ve gained a subscriber here. It was well done. Thank you. I think theres a natural friction between Phoenix and rails advocates as its hard for most people to advocate one without putting down the other in one way or the other (even if indirectly). So personally I think DHH has been restrained given some of the derogatory things that have been said about rails across the web even as the detractors use frameworks inspired by it . I don’t listen to him often but I have always like his level headedness and approach to programming and been grateful to what he’s brought to the table enough to inspire the entire industry.
I don’t know if RoR really seems simple… It seems easy to use, but not simple. Simple would be easily understandable components that you can easily fit together to build bigger things.
I find the whole GraalVM project to be very exciting, but truffleruby is at best an order of magnitude faster than MRI on microbenchmarks. This difference will be watered down when you consider Rails as a whole. It is great that the Ruby community is getting another option for deploying software but I doubt it will change the conversation, especially because alternative implementations always come with their cons too.
I also doubt it will solve the other performance issues that plague Rails development, such as long-running test suites, high boot times, poor database management, etc.
The actor model requires isolation if you want to leverage concurrency and fault tolerance. You won’t have isolation when mutable state is running abound. Without the foundations, you are limited to a suboptimal programming model with stop the world garbage collectors, system-wide crashes, etc.
Having actor libraries is definitely welcome, but it doesn’t compare to a system designed from scratch with actor-like properties.
I wholeheartedly agree on the ecosystem bit. It is Rails’ strongest asset and I don’t think anyone can deny Rails’ legacy. I can use it to quickly hack something with authentication, upload, etc. But as others have already said, I don’t find Rails simple. Nowadays it has too many moving parts and too many external dependencies just to get started. It keeps on growing and the subset of Rails I end up using on my applications keeps shrinking. I know I will have to pay for this extra complexity at some point.
and yet it does fine for many existing and well known apps. That would be mine and DHH’s point. . Look…No modern tech stack stays suspended in animation. Elixir and Phoenix should be prepared for some slimming in the leads and I made pains to say that doesn’t mean Elixir wouldn’t still have some/many advantages. However I’ll wait to see how things go with TR. I don’t see how anyone outside rails or TR can establish what the final output will be. the gains with TR have been tremendous. Yes so far the gains have been “raw” compared to a full framework test but I can’t think how TR wouldn’t make Rails more performant long term. I doubt the TR team would be putting the amount of work into it if they were as pessimistic and they are in a far better mind space to assess that . I agree its not going to be as dramatic for rails but then it doesn’t need to be.
“Having actor libraries is definitely welcome, but it doesn’t compare to a system designed from scratch with actor-like properties.”
No one said it would .That would be the point of DHH again - it doesn’t have to be near equal. keeping it on DHH’s point of view (which this thread is about) lets look at Erlang’s phenomenal uptime capabilities. I read one report putting it at 31 ms per annum. lets say that another solution was one hundred times worse. Who really cares theres no comparison? 3100 ms is 3.1 seconds. As a startup 3.1 seconds is going to have no great advantage to me over 31 ms. No reasonable customer is going to complain over 3 seconds over a year (they are more likely to think the problem was on their providers side).
Now for telecom that is probably a big deal. 3 seconds not being able to use the phone may be life or death. For 99% of web apps? nah. frankly for all my clients and my own projects 3 seconds A MONTH would not even raise a second respiration.
So it is with DHH’s argument with performance ( I just switched it to something else besides speed and concurrency we hear so much about and apparently doesn’t communicate to many). DHH’s point is solid - I don’t care that I can’r run a million requests on a server. I might post MPV (with a mega success hit) but I am going to need investor dollars anyway at that point and its then not going to kill me to have 40+ servers.
Where DHH’s argument gets a little thin is when its just satisfied at any performance level which is why I am happy to see strides now being made. I might not have a lot of customers who are going to have very high concurent usage regularly but I would a rather not to see an app (or my bank account) choke over a viral spurt. Besides that for the vast majority of cases its a monetization issue even more than a performance per server issue.
P.S. everyone is different. I find Ruby to be one of the simplest languages to pick up. OOP still rules the world so I am sure most people past their first language would find it much more intuitive than Elixir. Most still start out with OOP. Dependencies out of the box at installation is no issue as far as I am concerned. if you go gem crazy or have older versions then certainly - but that happens to all frameworks to some extent as they age. You just won’t come to the pain points with phoenix because its young. Its a bit like cursing the the creases in the leather of an old but reliable saddle. That comes with age.
Btw, I use your 
