Thoughts on DHH interview on Ruby Rogues podcast? Rails, Front end and (briefly) Phoenix discussed

General Prog (Archived)
,
43

Overall I agree with your points that Rails is fine for a good range of applications. I mean, it is impossible to deny it. But you seemed to imply that TR, actor libraries and other changes would cause drastic differences and I politely disagree with that. Will Ruby and Rails get better? Sure, most technologies do, but I don’t expect order of magnitude improvements nor the adoption of new programming models that radically widen their applications.

It happens to all frameworks but it doesn’t mean it happens or will happen to the same extent. The Rails community is in particular proud to move fast, both in terms of breaking changes and adding new features. It has pros but it definitely has cons. At my previous job many people dreaded new Rails versions because they knew a large chunk of time would be spent upgrading applications and dependencies rather than working on what matters to the business.

And this brings me back to my original point: the importance of having strong foundations. Phoenix apps boot quickly, test suites run fast and its channel implementation scales horizontally and vertically with an implementation that is a fraction of the Rails one. When you look at the Phoenix codebase, Phoenix isn’t doing anything special to get those properties… it is just leveraging the platform. There are less moving parts and that in itself will most likely result in less churn in Phoenix applications as they age.

It is misleading to keep on painting performance as the number of requests per second or the latency in production. If you need those numbers, good for you. But It goes way beyond that. It directly impacts the quality of the system in the short and long term.

1 Like
44

I didn’t say anything about drastic but frankly I have no idea and neither do you of that outcome. What we do know is that so far (I’ll use the word now) there have been drastic improvements in what has so far been run on TR. I agreed with you that rails is not likely to see the same kind of improvement as frameworks never do. Whose the fastest or the baddest in concurrency/performance is not a deal breaking issue however . If it were then people would be dropping Node, Python or even php en masse and Elixir would be a top twenty (or better) language. Rails doesn’t have to be as fast as Phoenix because in 99.9% of the apps out there its not needed. The people I know that left Rails did so NOT for the best performance but to escape the problems of being on one of the lowest. Doesn’t have to be drastic .

“At my previous job many people dreaded new Rails versions because they knew a large chunk of time would be spent upgrading applications and dependencies rather than working on what matters to the business.”

Ruby gives itself over to Gems/libraries that doesn’t mean you HAVE TO do so. I have “been there done that” and the pain point was higher related to how much of you apps work you handed off for a gem to provide. I am fully aware of the features and architecture of phoenix (if they did not interest me I would not be here or built an app with it) but to be honest and fair to Rails and DHH - again a lot of what you say is age related. Do you know that a future version or two or three of Phoenix will not be a major headache to upgrade? Of course not even if you think you do. Will phoenix be the first framework to be just so freaking awesome future frameworks will not be able to point out its warts? Dubious.

So I think The community could be a little bit more gracious in pointing out flaws or weaknesses (generally the elixir team is) because it generally takes around a decade for the warts to start to show with any framework or language. The new kid on the block is always going to be able to point out all the flaws of their dads because the new kids are new and haven’t been scrutinized as long.

“It is misleading to keep on painting performance as the number of requests per second or the latency in production”

and who has been doing the misleading? No one has made ANY such claim. I replied to a general comment about performance with a general comment. No harm no foul. I was just explaining the legitimacy of DHH’s point of view. Meanwhile its just reality - requests, concurrrency and latency ARE whats often discussed between rails and phoenix proponents. So I guess entire communities are misleading each other on both sides.

At any rate this is getting more Rails vs phoenix where in my own approach its Rails AND Phoenix. I just get DHH points more as his use cases align with mine. If you are an employee or work on captive company apps you will have a different perspective.

45

At least so far, the approach that Phoenix has of generating code inside the user’s project, instead of leveraging “magic” code inside the framework that makes things “just work”, has made it so that even with major upgrades to the way things are expected to be done, it is much, much easier to keep existing projects working, because the code necessary to do is inside those projects, and not inside the framework.

1 Like
46

That’s exactly what I am saying. :slight_smile: To me it is not about concurrency/performance but rather what they allow me to build in terms of features and maintainability.

I don’t. :slight_smile: I was only explaining that they do not have to age the same way because:

  1. Although subjective, upgrading from Phoenix 1.1 → 1.2 → 1.3 was really straight-forward.
  2. Rails has a culture of “move fast and break things”. Phoenix seems to be quite moderate here.
  3. Ruby makes it easy to traverse boundaries, access private functionality, monkey patch, and those often lead to frustration when upgrading.
  4. Phoenix has less moving parts.

I am not saying those are good or bad. Many will say that bullets 2 and 3 are what makes Rails shine. I am just saying there is enough difference in philosophy and in practice to at least expect a different outcome.

Strawman. Nobody is claiming so.

You have answered your own question. Sure, the Elixir community is proud in advertising and tweeting performance numbers but if you ask Elixir/Phoenix developers what they love about the language or the platform, raw performance definitely won’t be the top answer. In this thread you can already find many examples.

47

At least so far,

relevant words to my point. When Phoenix has a decade under its belt then its a proven claim (not doubting it will but whose to say so early?)

I have no problems keeping my projects working. there is always a degree of abstraction with using a framework and with any major upgrade you have the risk in ANY language or framework of running into issues. Its up to the developer to know whats going on. the problems I see in Rails is that way too often gems are used all over in an app and then oops they break when theres an update. That can be messy but thats the price you pay for the RAD aspect.

I think this is one of the HUGE divides in understanding DHH. DHH being an entrepeneur is more about getting an app working for the end user and profitable so that you have a job to begin with and if needed can buy more servers from that then proven MVP. Thats where I and many businesses live so we can later with an app thats a hit THEN optimize all those things (in the very few cases where its needed). I can get OOP people up to speed far faster (and they are in greater supply) then asking them from MVP stage to wrap their heads around functional and a smaller ecosystem. In my own startups I’ll gladly pay later to do upgrades because the app out in the wild is paying for it. To put it blunt - its about end user satisfaction and money not architecture purity out the gate.

In my world Rails and Phoenix live side by side. I take the benefits of rails and when , where and if needed use Phoenix. Like DHH might say “its fast enough” to get the job done and its still right there at the top if you need to get to market in a time sensitive space.

48

Strawman. Nobody is claiming so.

Sorry - Thats not a strawman its an illustrative question. Big difference in definitions.

but if you ask Elixir/Phoenix developers what they love about the language or the platform,

Thanks. that makes my point…That wasn’t the question in this thread or even the thought I responded to. It WAS about performance. So I don’t know why you are running this point down. I have neither implied nor stated it was all about requests per second. So theres nothing at all misleading or you will have to claim all across the web (not just a thread) where both sides talk of benchmarks its always “misleading”.

Although subjective, upgrading from Phoenix 1.1 → 1.2 → 1.3 was really straight-forward.

so you are basing your argument on two minor upgrades to a framework on 5.1…ummmm okay. Like I said before I don’t dispute that may be the case just that its too early to know thats going to be the case

Anyway I find myself having to defend Rails again where I said nothing at all against Phoenix. I merely stated that for many Apps (as DHH states) Rails is more than adequate (which it is) and that there is likely to be performance boosts coming this year that would slim the disparity in performance a bit.

For that I have gotten a long and ever growing litany of the evils of Rails architecture, culture and libraries. Its hard to say why so many platforms have tried to emulate such a horrible framework full of so much devastating warts.

49

Because it gives your short-term gain for long term pain. As with almost anything humans seem to like short-term gains more. That is why anything with an instant positive feedback mechanism takes hold even if it is in general not good for you. (fast-food, ruin the environment for financial gain, quarterly stockmarket goals, stupid web frameworks :smiley: )

RoR dropped like a bomb back in the days and of course people tried to jump on the train. It was seen as the framework to emulate. And probably still is.

But there has always been complains about the architecture and for every Rails like clone there is another which aims for better architecture. They almost never take hold because they require you to put in more energy to get started. After a while the maintainers see that things haven’t got any traction and the projects stalls.

It seems that the number one reason technologies get popular (regardless of their technical merit) is easy on-boarding of developers, that non professionals can get started (VB, php (perhaps RoR?)) and how quick you can get anything done with it. Normally though, after a while, these applications are less maintainable than something built on solid ground.

If phoenix and elixir manages to do the “easy on-boarding” of developers the beam and the OTP platform will hopefully make sure that things are maintainable. If RoR could have that and and have better modularization I am pretty sure they would select to do it too.

2 Likes
50

Reminder that you are in a thread about Phoenix and Rails. Everyone is welcome to criticize and defend both technologies. I would recommend you to consider this thread is not about you.

We must have been reading different threads because the technical comments so far have been quite moderate. In fact, the discussion about architecture and maintainability is where I actually learned something. I couldn’t care less about performance.

1 Like
51

No…not even close to a fair and balanced observation. Theres a whole lot more sucess to Ruby and Rails than that. People with real businesses valued getting things done and in a competitive marketplace what gets you to that marketplace is valued over technical purity - by business people at least (and they pay the bills). Programmers some times lose sight of a basic fact. Programming is about creating apps for the end users.

It seems that the number one reason technologies get popular (regardless of their technical merit) is easy on-boarding of developers, that non professionals can get started (VB, php (perhaps RoR?)) and how quick you can get anything done with it.

Again not a terribly fair assessment except perhaps for the last part. To a certain extent the days of 50 lines to get a hello world app should be done and that is a part of how quickly you can get things done.

Do we really have to rain all over Rails to advocate Phoenix? I know I don’t. It makes even less sense when the language and framework you are championing was greatly inspired by it.

I couldn’t care less about performance.

Now Remember your own words - “I would recommend you to consider this thread is not about you”
Its quite possible we are reading two different threads because I could have sworn this thread was about DHH’s comments in regard to development, Rails and Phoenix.

52

Firstly, I dotn’ think it is worth dragging this on. I think RoR is a great for time to market but has scalability problems (both performance wise and application wise). I think phoenix OTP addresses the scalability problems (both performance wise and application wise) and has narrowed the gap enough to RoR to make it a great choice for your next project.

I hope you don’t read to much hostility or argumentation in my arguments. I intend them more as some light-hearted comments.

Correct, business people who is driven by short term gain and quarterly reports. RoR definitely is successful in quick to market and getting a MVP out there. I’m not saying that RoR is all out bad. There are pros and cons with everything. On the web I guess the biggest platform by far is still php and I think we can agree that RoR improved on that it also introduced MVC to the mainstream web world and the pretty cool screen-casts by DHH that gave them an initial push.

I think it is pretty good :smiley: I am not comparing RoR technical abilities to VB or Php, just the feeling I have that those capabilities is what made things getting done in them. I’ve supported VB applications (+access) written by doctors in the 90’s which became critical to them running their departments. They used them as tools to solve a problem and get things done. But they were impossible to maintain later when things got serious.

The same goes with php and RoR. When someone has a problem (if they are a professional developer or not) and can use a tool and get something out there that seems to work (in spite of security problems or bad design or what not) it will get traction. Some tools create harder to maintain software than others (VB + early php for example). Some do it a little better (RoR) but in my opinion still a bit of the mark. As technology improve I hope the gap between doing something quickly and doing something well is getting smaller.

I don’t think I’ve been to hard on Rails, just responding to your initial question why Rails got popular even though it has its fair share of criticism. In my world the “quick to market” capabilities of rails is great and that it is why it is popular (even if their technology is good or bad). I’ve also noted that RoR applications are quite a bit harder to maintain long term than applications running on the BEAM.

I’m not really a phoenix advocate either, but rather an erlang/OTP advocate which I think is one of the best way to structure applications that are loosely coupled and have the ability to scale beyond million lines of code.

I am just hoping that phoenix can bridge the gap between easy on-boarding and quick to market with a properly design application.

3 Likes
53

When I said I couldn’t care less about performance, it was a direct criticism to DHH’s comments. It seems DHH, either on purpose or by accident, frames the Phoenix vs Rails debate around performance because it is easy to sell that Rails is “fast enough”.

I’m rather interested on a discussion about short-time and long-time impact of those choices. The impression so far is that Rails wins on the short-time because of the ecosystem but this rapid style of development shows flaws later on. On the other side, Phoenix lacks the ecosystem aspect but makes up for it on the longer term in simplicity and maintainability due to the platform and functional programming concepts.

This implies Phoenix is more suitable for any company that has passed the first months of rapid development and prototyping. But every time someone brings this up, you refuse to broaden the discussion, either on purpose or by accident, claiming that the original conversation was about performance (which it wasn’t) or by claiming that others are painting Rails as the devil (which most are not).

1 Like
54

Such has been my first hand experience. Back in 2010, we had a short time-to-market window, and we were able to meet it thanks to RoR. However, after about 6 months, we started experiencing some nasty problems in production, as complexity and scale kicked in. We had a long period of serious issues in production and needed to do various workarounds to stabilize the system. As the byproduct, a lot of additional technical complexity was introduced to the system.

I agree. My first Erlang project hit the production in 2011. It had similar demands as the RoR one, and operated on the same scale, yet it was technically simpler than the RoR project, and worked marvellously in production, despite many noob mistakes I made. Even back then, before I discovered Elixir, I made up my mind that Erlang is a much better long-term choice for a constantly evolving project.

With the addition of Elixir, Phoenix, and Ecto, my opinion is that the bootstrap experience is significantly improved. Therefore, my pitch for Elixir/Phoenix is that we can start a new project easily, move forward at a steady pace, minimize technical complexity, and keep our sanity and always be in the control of the system when complexity/scale kick in.

5 Likes
55

No. Once again not a fair characterization. How about business people who have to pay bills and hire people so that programmers can feed and take care of their families? I think right now there are two types of programmers out there. We really have two different needs and to be honest the ones that pay attention to making money are more living in the real world (we help to feed those not). In sasajuric’s example . he had a job six months later because of Rails terrible architecture getting it out to market.

I would argue that ever feature has a downside and every approach has a draw back. I get that you think that as you say you hope that “phoenix can bridge the gap between easy on-boarding and quick to market with a properly design application.” but I think its a bit of a pipe dream. I expect that Phoenix will never meet that to the level rails does and neither should it. certainly its not churning out apps the way rails did and does.

look at ecosystem in regard to libraries. Its a necessary down side in an open source community that upgrading is going to be an issue the more libraries you have available and the more the community relies on them. This is part of the “moving parts” criticism and to a lesser degree the claims of “magic” that rails gets. I don’t really buy the whole build it once on great foundations and just maintain it from there on in. I have never had a project that never required rewrites as the project grew, evolved and expanded regardless of language or framework.

But every time someone brings this up, you refuse to broaden the discussion, either on purpose or by accident, claiming that the original conversation was about performance (which it wasn’t)

Thats rather personal making the discussion indeed about me. I just don’t know what you are talking about as one of the key points of DHH was about performance in the OP as clearly put here

So firstly, David as the creator of Rails can presumably get more efficiency, maintainability and performance out of Rails than almost anyone else. So most likely Basecamp is about as-highly-an-optimised Rails app as it’s possible to make. He argued that Rails was easily “fast enough”. But if Phoenix is much, much faster than Rails, then doesn’t that mean a Phoenix developer can put off performance optimisations much longer, perhaps indefinitely? That feels like a big win. Also, I don’t know what “fast enough” really means.

So how could anyone honestly say it wasn’t about performance??I think I might know who you are so I’d rather not respond further to your posts. They’ve significantly distorted what the thread was about as proved by the above quote from the thread opener.

This implies Phoenix is more suitable for any company that has passed the first months of rapid development and prototyping

No it doesn’t because no normal startup can truly be measured at under a year (some would say 2 or more) to be past its development stage and countless apps will never need significantly more to justify a different infrastructure.

56

You are assuming that using Phoenix at the time would somehow drastically affect his time to market and make his company lose their opportunity. To quote Sasa’s own conclusions:

Yes, the original conversation talks about performance but not only about performance. To quote the author:

One of the impacts of less magic is simpler development, better maintainability. But once again you skipped the whole discussion on the topic.

First of all, I was not referring only to startups. Second, I left “first months” intentionally vague as it indeed depends on many factors. Lastly, you just quoted Sasa using a 6 months time frame, which for his company was enough to feel the growing pains of a Rails application. YMMV.

1 Like
57

Folks, as I have said earlier, I am exceptionally keeping an eye on this thread. @MikeAnthony, @joaof and @paulstr, please consider having a break from this thread and let other users join the discussion. Your points have already been made, we don’t all need to agree. Otherwise I will move further comments to a separate thread.

4 Likes
58

I’m a senior Rails developer / consultant who’s hoping that legacy Phoenix apps will be easier to maintain. I can’t really remember seeing a well organized, easy-to-understand Rails app out in the real world; in nine years of working with the platform.

I think that Ruby the language is one part of the problem for me: its syntax and culture results in code that defies static analysis - by tools, or by people. In contrast, I can look at a page of Elixir code and understand where everything comes from.

4 Likes
59

I have developed production systems in both Rails and Phoenix. I’d say Ruby is still the king of expressive developer happiness, with Elixir not far behind. But none of that beats the fuzzy comfort of having the rock solid, stable, never go down runtime that Elixir offers. You just know the thing keeps running, while this is always the first concern for any Ruby project. And that is priceless.

1 Like
60

I can look at a page of Elixir code and understand where everything comes from.

Elixir certainly has that, but it is a feature of all functional languages. The lack of side effects means there is never any external state magically influencing what your code does. There is always only input, code, output. And that makes Elixir so readable and maintainable.

61

I’m in the process of deploying a Rails app to EC2, and I have to say that although at first deploying Elixir with distillery and edeliver seemed complex and daunting, after doing it two times it actually is simple and rails is looking more complex to be sincere, probably because distillery does to an erlang runtime package a natural “release”, while in rails it looks like it’s a bit all over the place once you get out of heroku (and to deploy elixir on heroku, the difference between that and rails is basically adding a two line buildpack to your app dir).

There’s other things that I think Elixir offers that Rails doesn’t (or can’t), and that’s basically native tools to deal with queues, backgrounding and generating state efficient processes (in the sense that you can create things like specialised caches, without having to add a worker process outside of your app just to deal with that).

Having said that, webpacker is a great addition to Rails and makes it easier to integrate things like vuejs, react, etc. I like DHH thoughts on “developer happiness”, “ease of use” and I’m grateful he made Rails and open sourced it, but I think elixir is better poised atm to tackle some problems, while offering better tools for the current state of web dev (like using a detached front-end that communicates with the server, instead of SSR), native abstractions to deal with queues (which is kinda relevant), native support for backgrounding tasks.

I think if Elixir had an even more streamlined approach to deployment, in the sense of deploying a webapp is running like 3 commands (yeah I know, no deployment is equal, nor what it requires, and elixir unlike rails is not only used for webapps, but still, a webapp, with a front-end, ecto, or an umbrella, giving it a command that just takes an IP and builds and deploys on that machine automatically, setting up a systemd task for it - and that can be changed for a custom build/deploy flow when required) would help significantly developer happiness. Also having “build” packs for phoenix that automatically set up front-ends (like webpacker is doing for rails) would also be great (since having these defaults doesn’t tie you into them, if you’re advanced enough you can take them out and simply do your own custom requirements).

Having said that, I like rails and ruby - and the philosophy behind it - I just think elixir/erlang (and phoenix) offer things that RoR can’t and make solving some issues (the things you tell your clients - “oh you know what, that’s really, actually complex to do”) fairly easier.

3 Likes
62

I’ve been writing Web Apps for more than 3 decades and I can say that the most excitement and productivity moment in this period wad the encounter with Rails. I honestly think that DHH is one the most influential features of craft. It’s not been by chance that it’s influenced almost all the major shop in the town. From RESTfullness out of the bow and elegance and DIY. Rails has raised our vision and practices. And one of the best books that showed me the extent of it’s power and flexibility was written by José Valim: Crafting Rails Applications. Here lies the real story of the two paradigms: Natural Evolution.

Maybe Jose was the right person to dare crafting the new paradigm out of the best ones available. Elegance and joy of the development and productivity. DHH & Jose have both shown that they have a strong taste of where the industry is ripe to head to, and the talent of building a community around their vision. Without DHH in person the Rails community wouldn’t grow so fast. The same thing is true today with Jose. I follow their activity and influence closely and I honestly admire both of them.
While all my apps are built with Rails my platform of choice is now Elixir/Phoenix. OO was my big thing 2 decades ago. Mathematically it helped my to model the reality. But it’s based on something which I don’t accept any more. The whole OO world is based on managed side-effects and statefull models. I’ve been in the business of defining and policing the guidelines to curb the negative effects of this paradigm during good part of my activity. Yes we give you all the tools you need to shoot yourself but at the same time advice you not to! Even when I found an elegant functional language like Scala, it was “functional” among others! You were “advised” not to use the language nastily.

Beyond the immediate benefits of a language or platform, such as performance, what I value in the Elixir direction is the choice of the paradigm (functional) combined with the most solid and proven runtime platform embodying that paradigm. It has been years that many languages and platforms praise the concept of actors. It’s almost a fashionable thing to inspire from it. Why not adopting the underlying Erlang runtime as the basis. Unlike JVM, the Erlang Virtual Machine is a true Open Source property and does belong to a company.

I understand the DHH’s “fast enough” argument, but when I buy a cheap server slot for my apps I would appreciate a better usage of the limited resources I get there. More importantly maybe, I’d appreciate the shorter testing time. Today it takes about 15 minutes to run the full test. And since some gem updates break the whole test suite, I run the tests sometimes between the individual main gem updates. It’s grown too expensive. Today this is the bigger problem to me than the number of requests per second.

I keep using Rails whenever I don’t get the right tools from Elixir/Phoenix ecosystem, and otherwise, I switch to Elixir/Phoenix. The 2 most productive and ground breaking platforms I’ve known.

7 Likes