[pdimitar]

This is what brought me to RoR land... and this is what made me leave.

I agree rapid prototyping is an excellent point for RoR but when you need to actually evolve the project for years, it gets really tedious and hard.

So for a dev shop RoR is quite fine -- you make the project, do very little iteration on it, and ship. That works well and I've experienced it.

For longer-lived projects however, Phoenix is miles ahead. Even Rust's Rocket, but only if you are willing to invent a lot of stuff yourself (auth for example).

[JeremyNT]

> For longer-lived projects however, Phoenix is miles ahead. Even Rust's Rocket, but only if you are willing to invent a lot of stuff yourself (auth for example).

I can't speak to Phoenix, but I've looked into Rocket and don't understand how it can really be compared to Rails. There's so much you need to implement yourself that you'll end up spending a big chunk of time on implementing things that Rails (or high quality / well used gems in the Rails ecosystem) can provide for free. And don't get me wrong, I'd love to sit down and do that work, but my job is to make stuff work and make it work quickly, and my employer doesn't hire enough people that we can afford to dedicate that kind of time when it's already "solved" by a framework.

I tend to work on projects where the requirements change constantly, and they're never really "done." Saying rails is good for "prototyping" is not wrong, but in a world where software is always evolving, the features and capabilities that make Rails great for prototyping are also great for just day-to-day existence.

[wukerplank]

What makes you say it is hard to maintain longer lived projects? (I used to be a RoR developer for a few years, so I'm curious about other people's experiences.)

[kenhwang]

As a person maintaining multiple Rails codebases approaching a decade in age: RoR just bitrots incredibly fast and its really difficult to catch or update.

With each new version of RoR gems just stop being compatible without replacement, and its a fairly significant effort to migrate everything to the new shiny being introduced. In fairly stable projects where there isn't much feature churn/replacement, you pretty much have entire sections of the codebase that never move past the version they were originally written in. You're constantly maintaining controllers/models written in RoR 3.2/4/4.2/5/5.1 styles since its incredibly difficult finding which features were used, but they still kinda sorta mostly work, until they silently don't.

The difference compared to other frameworks/languages is that Rails is very heavily powered by "magic". Every other tech explicitly configures and calls features being used, but Rails is mostly held together by "convention", but convention evolves. How do you search for things like "the filename of this must match the class name of this" or "the method name must match this database feature". Nevermind the metaprogrammed methods that aren't documented anywhere. The convention evolving as developer preferences changes is generally a good thing and keeps RoR from becoming too dated but it is an expensive maintenance burden.

I quite like Rails and it's still my first choice for personal projects/prototypes. But I'm definitely souring to it for long running professional work.

[pdimitar]

It's mostly the "magical" parts like before/after hooks. When you are tracing a bug and are trying to do step-by-step debugging, it has been hell. Quickly jumping to definitions? Even RubyMine can't do it.

Furthermore, as the project grows, you need to introduce something more/bigger than MVC and people put these files everywhere. Sure it's a management problem but it doesn't help that people don't do the right thing by default.

In general, there's a breaking poing that you will very soon hit when you try to just pile things on top.

[JohnBooty]

    It's mostly the "magical" parts like before/after hooks. 

I dislike a lot of the "magic" in Rails, but don't find before/after hooks very "magical" at all.

I guess when you get into inheritance perhaps. When you have an inheritance chain, which hooks are firing and in which order? That gets confusing fast. But, that also doesn't feel Rails-specific at all to me.

Rails gives you some ways to shoot yourself in the foot, but what language/framework doesn't?

    When you are tracing a bug and are trying to do step-by
    -step debugging, it has been hell.

I don't find this too much of an issue. It may be primitive but I just rely on debug output statements.

I have an expansion set up in my text editor that spits out `Rails.logger.debug("[jbootz] ")` and then I just do `tail -f log/development.log | grep jbootz`. I also have iTerm set up to highlight any lines containing "jbootz", so it stands out when it's mingled in with other output. (I just picked "jbootz" as it's a unique string)

In general that's the strategy for Rails debugging or really any dynamic language where the editor/IDE can't reason about the code like it can with a static language.... lots of debug output and then get a little creative with how you filter it in your terminal.

Helps to use an terminal app like iTerm that lets you use split panes so you can look at multiple filtered views of your log output at once if you like.

    Quickly jumping to definitions? Even RubyMine can't do it.

Yeah. I used to work in C# + Visual Studio + Resharper and oohhhhh boy, I often miss being able to lean heavily on the IDE/compiler.

Still, as far as definitions go? I don't know. I just grep for "def foo" (if I don't know what file it's in) or use my editor to jump right to the file where it exists (if I know where it is, which is usually the case)

Not as slick as the editor/IDE actually being smart, but I don't really find it to be a friction point.

[square_usual]

> I have an expansion set up in my text editor that spits out `Rails.logger.debug("[jbootz] ")` and then I just do `tail -f log/development.log | grep jbootz`. I also have iTerm set up to highlight any lines containing "jbootz", so it stands out when it's mingled in with other output. (I just picked "jbootz" as it's a unique string)

... that seems unnecessarily complicated compared to using byebug, or hell, the RubyMine debugger.

[JohnBooty]

I should have been clearer.

I use pry/byebug extensively as well.

There are times when I prefer debugging via debug output statements and times when I prefer interactive debugging.

[PikachuEXE]

I agree Rails only does a great job on structuring when project is started

But any large enough project needs rules for placing files/classes

I don't see how Rails failed in that way

I do agree there are some "magical" stuff like hooks that can be easily abused and introduce bad coding habits/patterns

Wish I can turn them off per class (not for the whole app since they are still sometimes useful)

[JohnBooty]

Yeah. MVC is not always the right tool for the job, but it's generally fine and IMO rarely a terrible fit.

I don't see how that's a Rails-specific problem.

Before Rails, working in the wild and wooly world of Microsoft web dev (with occasional PHP thrown in) I saw some real horrorshow web apps. People hacking together their own confusing and misthought architectures. And those horrorshows were rule and not the exception.

The standardized structure of Rails apps is such a breath of fresh air. It's so nice to step into a Rails codebase and basically know where most things are most of the time.

Admittedly it's also nice to step away from Rails for smaller, simpler apps.

[joelbluminator]

What do u use outside Rails and how was your experience? It's a bit embarrassing I only did Rails with Ruby.

[JohnBooty]

Before Rails I did a lot of work where there was no framework comparable to Rails, in ASP "Classic" and then ASP.NET.

Generally each web app had its own organizational structure. Everything was still "page-based" so your site's file structure would mirror the actual URLs: the code for your product page would be "/product.asp" and your shopping cart page would be "/cart.asp" or whatever. Those files had intermingled markup and code extremely similar to ERB files in Rails.

Conscientious developers of that era would of course extract as much functionality as possible into shared include files. Even in those savage days we tried to separate logic and presentation whenever possible. Early PHP dev worked much the same way.

Needless to say this generally lead to spaghetti code. You certainly could make very maintainable ASP/PHP sites, with a lot of effort -- just like you can find some very maintainable and well-structured shell scripts. But, even so, each "well-structured" ASP/PHP site would have its own structure and it was quite a learning curve jumping into a new one, if you ever had to look at somebody else's code.

Early ASP.NET apps used an even more bizarre set of Microsoft constructs. Code-behind files, etc. Yuck.

Later came ASP.NET MVC which was quite good IMO. It borrowed liberally from Rails which was a good thing.

In Ruby land I developed with both Sinatra and Rails. Sinatra is great and a lot of fun, but you are totally on your own w.r.t. structuring your app. Once your Sinatra app grows past a certain complexity, you will generally just find yourself reimplementing large parts of Rails and encountering the same problems w.r.t. structuring your app.

Rails and MVC are not perfect -- many say other variations like MVVM/MVP/etc are better. Perhaps so. I've certainly had pain points with Rails (too much "magic", high RAM usage) but as far as structuring my applications.... no.

[Lammy]

I think there are probably a large number of people who "learn Rails" without really learning the deeper/unique concepts of vanilla Ruby. For me at least it was like a decade in between first writing some Ruby and really feeling like I've started to understand the full scope of the language and syntax that's available to me, such that I'm only now able to start thinking about what cool actual-things I can build with these concepts.

[fareesh]

In your experience, is there good resource for discovering the "de-facto" hex packages for a particular requirement - I end up Googling things like "Phoenix paperclip equivalent" and then evaluating all the various ones.

Alternatively are there some good "kitchen sink" open source projects that implement many of the typical web application features like auth, uploads, etc. ?

Companies like thoughtbot have been a gold mine of information and battle-tested practices - is there anyone similar in the Phoenix space that's worth following?

[pdimitar]

Sadly there aren't many better ways. For the moment the best course of action is to search on ElixirForum. Even if I love the language and still look for ways to work with it (in my new job where it isn't used) I recognize that the ecosystem is not that big.

For auth, the core Elixir team has made one prototype but I am not sure if they'll pursue it further. Outside of that, use Pow. For file attachments: Waffle. Authorization: CanCan, although the area has several very solid options, I heard.

Discoverability can indeed be a problem. Covid-19 hit everything pretty heavily and Elixir's community is no exception. Just a month ago people started finally hiring for it again (on the forum).

[regularfry]

Time for a respin of https://www.ruby-toolbox.com/ ?

[athriren]

edited to delete as i was discourteous.