Like a lot of people in technology, I love to play with new stuff, but as someone who's seen things come and go, it's really difficult to recommend something other than Rails for most use cases. It's got so much that you can just include in terms of libraries and it's got a good community with good values. It lets you write down a first iteration that's solid and can be incrementally improved on and taken in new directions as the business learns what's what.

I devote time to keeping up to date with alternatives, but the costs of switching are high, and the ROI just isn't ever there.

(I work at a university these days, where our problems are different than when I worked at a startup, but speed of development and the relative stability of the platform are always important no matter what you're doing)

Things I love about Phoenix over Rails:

- Background / periodic jobs are baked into the same runtime as the server. You can install Oban in about 5 minutes and have it generate periodic jobs without any messing around with additional Ruby processes or custom databases (i.e. Redis, although background jobs are great on Postgres these days)

- Anything real-time is given to you out of the box. Rails has ActionCable but like the background jobs above, it needs to be setup as a separate process. Livepage makes this very straight forward.

- Phoenix sacrifices some of Rails' magic for verbosity but I think that's a better trade off long term.

Things I've loved about Rails:

- The eco system.

- Near impossible to hire experienced people - We had to write from scratch a lot of things that are "free" with rails/django/etc - The paradigm change takes time to learn and get it right - Some people were happy to learn it, others didn't want because they knew they wouldn't use it ever again - Many missing libraries in the ecosystem. Some libraries are poorly implemented or abandoned. - Googling for problems wasn't easy, there aren't as many answers out there as you can have for Rails, Django, etc...

But yes, the Erlang VM is awesome, can't disagree with that.

I'm guessing it's just a use case mismatch.. guessing most of the Elixir/Phoenix apps being built aren't needing to integrate with existing boring backoffice stuff.

I mean... it is, but that's usually done through an API to an existing back office app. For us, we have Elixir sitting there doing orchestration, but it doesn't take over the entire responsibility of an existing app so it doesn't really make sense to rewrite or extend any part of the API into it.

But as you imply, rarely built in.

They've recently built it into asp.net core, but it feels unfinished, the syntax/api sucks, it's poorly documented, and unclear how to use.

Hard to get right for such a seemingly simple concept!

I find with elixir I'm adding a lot of boiler plate.

I've spent the past year or so on and off building things in Phoenix. Elixir is an amazing programming language, and LiveView is pretty cool. If you are building something complex, I think Elixir and Phoenix solve a bunch of tough things for you out of the box, thanks to the BEAM. However, I find that the sort of websites I like to make are not complex and pretty much are content-based with a tiny bit of CRUD.

Because of this, I've lately been exploring Laravel. PHP is pretty much _the_ language for content-oriented sites, and it isn't going away anytime soon. I've been looking into CMSes like Statamic and CraftCMS and of course Wordpress. Laravel seems to have as big of a community around it as Rails. I've also noticed that many of the things I've used in the past couple years have come out of the Laravel community, in a sense, such as Tailwinds and Alpine.

IMO, most of the frameworks are somewhat interchangeable. The reason why Laravel interests me is because I no longer want to chase new and shiny things. PHP will always be around, and I always tend to like content-oriented sort of business models more. I figure that I might as well embrace the ugliness of PHP and stop thinking about programming languages and frameworks and instead spend my time thinking about what I can make.

Django is nice, Rails is much better architected and Ruby is just a nicer language than Python (cleaner to read, more functional-goodness built in, better APIs both in std libs and gems).

I agree Elixir+Phoenix is a great choice too.

I'm a Symfony fan, and have never seen the need to use Laravel.

It's probably not helping that I'm not starting from a greenfield project. Needing to go through and understand other people's code with an out of date Rails and its dependencies have made me spent most of the time on infrastructure. The entire test suite takes 50-60 minutes to complete with a lot of integration tests hitting the database.

Do people allocate a certain amount of time just to upgrade Rails? It seems like there's an expectation that Rails is 1) used to start quickly with scaffolding (great for hackathons) 2) constantly running app and cared for to not diverge from the latest version

At this point, it's one of those love-hate dysfunctional relationship with Rails for me

I once started an interview with the question... "So, what version of Rails are you stuck on?"

The interviewer sighed loudly.

Is there a framework or technology that doesn't need constant maintenance? I feel like Rails is actually quite low maintenance. Major version changes are rare - Rails 6 was released in 2019.

Java is a specifically strange beast here. With many modern typed languages, a major version upgrade will require you to modify small parts of your code, as the compiler becomes stricter or small parts of the syntax change.

Java is more like C and C++, in that it tries very hard to maintain language level compatibility. On the other, library compatibility is a bigger mess in Java, because the language was pretty stagnant for such a long time, and library authors got used to a very slow upgrade pace. This meant many libraries and tools chose to rely on internal JDK implementation details or perform bytecode wizardry which stopped working with new versions. Java 9 also moved a lot of interfaces which were not an official part of the Java SE spec (like all of Java EE) to external artifacts which you needed to add as dependencies.

Another extreme point of incompatibility was very silly: libraries were making assumptions parsing the Java version string: up until Java 8, the version string had the format "1.x", where x is the major version (Java 8 was "1.8"). Starting from Java 9, there was no phantom "1." prefix coming before the major version anymore, so Java 9 was just "9". This broke a lot of libraries which would have been compatible otherwise.

Library maintainers were unprepared for the rather small changes Java 9 has made, and took quite some time to upgrade, especially huge frameworks like Spring. It took Spring 6 months to support Java 9 after it became GA, but Java 17 was fully supported 3 months before it was released![1]

If you have to upgrade from Java 8 to Java 17 now, there is nearly zero friction if your libraries support it and upgrading the libraries is easy. You'd barely need to touch your own code. If any changes are forced on you, that's usually the libraries, but then neither Java nor static typing is to blame.

And honestly I think it's quite easy to upgrade. In my experience, Java shops just tend to be more conservative than the industry average.

[1] https://twitter.com/snicoll/status/1420652097373188100

I don't think that's totally true. Without any framework, maybe, but mostly the standard library? I'm not sure. People use a lot of libraries, and these may not have the same guarantees as Go itself.

It does help to stay on top of gen upgrades as much as possible, but I do not believe this is a rails specific thing.

Maybe useful: there are companies providing long term support for old rails versions.

Rails spits a bunch of deprecation warnings when stuff is changing. Usually it's just a matter of playing whack-a-mole with the deprecation warnings and walking through the upgrade instructions. It's a chore but it's not especially difficult, even if you're multiple versions behind (in which case you go should upgrade through the intermediate versions one at a time).

The thing that will save your bacon here is having decent test coverage, so you actually see those deprecation warnings :)

This has been my exact experience too. My current theory as to why it doesn't click for me is that it tries to be too much like English. Sure it's fun writing poems all day but try refactoring a poem someone else wrote with any kind of confidence.

That said I love that ruby and rails exist, it seems to unlock creativity in some people and that's awesome.

Now I am like a Romulan, all I do is computational computer science with NumPy and Pandas.

I'd not start a big project in any language without: null-safety, proper sum-types, type inference.

Hence I like Kotlin, and KTor seems to be a good Sinatra/Flask like in that arena.

Another interesting development I find no-code/low-code tools for the backend, like Hasura. This allows me to "just expose Postgres over GraphQL" with very little code (mainly configuration). That combined with type-safe client library generation for a typesafe frontend language like Elm gives me all the power I need in a very different paradigm. Something worth considering.

Small example Hasura+Elm project: https://github.com/cies/low-code-backend-dockered

very interesting; I've been looking into sum-types recently, esp from a categortical perspective https://www.youtube.com/watch?v=2LJC-XD5Ffo

Maybe there is something about the necessity of Natural Transformation somewhere when the system scales to a certain size

Sum-types to me are just a necessity for expressing certain situations that occur a lot. Enums do not cut it, and making sum-types from records is just ugly, waaaay to much boiler plate and hard to deal with in practice (one needs sum-types AND switch expressions + pattern matching to really unlock the bliss of sum-types).

[1] https://gobuffalo.io/en/

I have used Rails for most of my career and for a number of side ventures. I have to say I have had a love-hate relationship with it.

I love everything people love about Rails (mentioned above). What I hate is how the speed and productivity comes back to bite you later.

The code eventually turns into a ball of mud and becomes near impossible to update. You have N-dependencies that depend on Y-dependencies of their own. Different Rails versions or module versions, and you can't update one without breaking something else.

You eventually live with it, and nothing gets updated but then you want security updates, and sometimes something terrible happens (like the mimemagic catastrophe) that forces you to ham fist updates together and live with some rails engines not working completely. But that's ok, because productivity right?

I've seen those same problems in other technologies and architectures, just as I've seen them in Rails applications. I think those issues come from lacks of carefully enforced standards, separation of concerns, domain design, and discipline. These are people problems, not technology problems.

What rails provides is the freedom to think about your business domains and such without having to also design the plumbing. I would argue that rails gives you space to solve those problems, but you still have to solve them.

However I've found that as apps grow bigger and accumulate more complex business logic and data flows Rails codebases become increasingly difficult to manage.

How about adapters?

There's some great pieces of literature out there about advanced ruby / rails - well worth the read!

The problem comes when that codebase starts to mature: you look up one day and realize that it's no longer just you working in the codebase. The lack of language-level documentation makes it difficult to onboard new members to the team. A new developer is inspecting a method they're tasked with refactoring. It accepts an argument named "input". What the hell is an input? Is it a hash? Is it a class instance? Both? Something else entirely? Idiomatic Ruby/Rails makes it quite hard to intuit expected inputs/outputs. (Ironically the community also vocally disavows the use of comments, which would ameliorate that problem somewhat.)

Meanwhile, "Undefined method `blah` on nil:NilClass" errors start to litter your logs to the point that developers become numb to them. Invariant violations that should have been caught upstream, at their point of inception, sneak all over your runtime and you waste valuable employee hours trying to identify their true source.

And Ruby's poor story around async i/o ties your hands as your traffic patterns begin to require a more sophisticated request processing pattern than "receive request, block thread, return response." Phrases like "worker saturation" and "let's make it an async job" start to dominate your engineering retrospectives.

These are just a few of the sharp edges that come from trying to scale Ruby. You may point to solutions to them, but they don't compare in elegance to working in a language that obviate those problems in the first place. And while it's very easy to start a project in Ruby and gain a quick initial burst of momentum, it's commensurately difficult to switch to a more mature language+framework when you realize that your engineering org is suffering from Ruby/Rails shortcomings.

This is not a blanket indictment of Ruby/Rails -- just an acknowledgement that different languages and frameworks are better suited to certain types of problems. In my opinion, Ruby/Rails are very well suited for small projects with few maintainers, where the total surface area of the domain model is pretty small. Or quick MVP's where you have to deliver next week or die. But the dynamic duo are not well suited to the kinds of problems that start to emerge as those MVP's scale up in complexity/LOC/number of maintainers. It's a bit of a catch 22.

People will point to the big companies running Ruby/Rails. But from having worked at one of them (Shopify), I can say that we were spending an inordinate amount of time trying to plaster over their shortcomings; I'd imagine this is also true of the other big companies that run on the same stack.

I'll admit I've never worked on a team over 100, but I have worked on older code bases.

When we found bugs, we wrote new tests to cover the edge case.

Also if someone had "input" as a variable name for a public method, and that made it into main, that's a failing of the PR process.

Most of the complaints here could be replicated in almost any language. In a c++ project I worked on in the 2000's I had a dev create a function void rct(int data). I (as lead) made him rename both the function and the param.

This is more of a general criticism of dynamic typing than anything specific about Ruby, but If it's unclear from the code why is it so hard to put a binding.pry in there and inspect the object if you need to? You'd usually wanna put a breakpoint in there anyway when refactoring to see what the hell is going on. And on a normal codebase there will usually be an accompanying test.

I'm not 100% denying that in Java you'll have a type like FactoryBeanXmlConfig which you can go ahead and read the documentation to (which is often insanely verbose due to everything being a type in Java. So lots of reading).

To each his own I guess; I think we all get used to whatever stack we use and become very productive if we stick to it. I acknowledge I would've been productive in Java eventually to the same degree as I am with Ruby, I just wouldn't have enjoyed it as much.

The Shopify example is a bit extreme: you are talking about one of the biggest monoliths in the world; not strictly for Ruby, in any language. So yes you're gonna have to build some tools to accomodate that and yes, probably Java would have worked out better at that size. But how many companies become Shopify - 0.1%? It's either a "scrappy MVC" or Shopify? I disagree: Up to that size of millions of LOC and thousands of full time devs there's a whole spectrum of companies size where Ruby/Rails works out well. I can't see why a 50-100 man team can't work with Ruby successfully; if the monolith becomes a pain you break it into a few smaller monoliths/citadel/microservice. This essentially allows you to scale to any size, but I think the monolith will take you far; look at Gitlab. I'd say around 100 devs work on it full time (my guesstimate, could be wrong) and their feature development speed is brilliant imo. There are so many successful Ruby/Rails companies at those sizes it would feel silly to start naming them.

This is a lot slower and more tedious than just inspecting the documentation for a statically typed parameter and the cost of doing it over and over and over again adds up. Also there's no guarantee that whatever type you observe in your particular binding.pry experiment is the only one the function receives.

Of course people continue to build large & successful apps in Ruby. I'm just saying at a certain point it gets harder than it would be in other languages.

I honestly don't see many methods where it expects a user but it can also receive a shipment or a billingInfo where tons of callers just pass all sorts of stuff to it as they feel like, and me as a dev have to keep wondering what the param is. That's not common at all because most Ruby devs just don't operate that way (Why would they? That's pretty insane). Yes it's easier to shoot yourself in the foot in Ruby but that doesn't mean we all design crap code.

Static type people say your dynamic code is always littered with dozens of if param.type == 'user' else if param.type == 'baboon' etc etc. I rarely stumble into this in real life. I'd like to see some real examples (there's enough python/js/ruby open source code for us to make an intelligent discussion)

As your team grows it becomes harder and harder to prevent people from shooting themselves (and the rest of the team) in the foot in such a way, doubly so when you're working in a language that more easily permits it. To your point, if you're working in a smaller team with collaborators that you trust not to make these mistakes, that's a different situation.

The inscrutable-method-input scenario that haunts me the most is the case of "options hashes" in Ruby/Rails. Someone writes a method that accepts a single hash of possible options keys, instead of an N-arity method that accepts those scalar values directly. When someone needs to modify the behaviour of that method, the short-term path of least resistance is to just throw another key onto the blob. In the most notorious example I can think of, one of our applications had an options hash with 30 (not an exaggeration) possible keys, after several years of developers deeming that the easiest way to implement whatever feature they were tasked with implementing. It was a total nightmare trying to debug situations where Key A | Key B conflicted in subtle ways with Key C & Key D.

Of course there's nothing preventing that sort of scenario from emerging in a statically typed codebase, but I find there's more friction around doing so. Especially if you start out with a rigid interface (with non-nullable keys) that all your callsites must conform to. If someone tries to add a new key to the argument interface, those callsites will need to be updated to match.

I actually agree with this, but there's also a bit more bloat and less flexibility. Also, I like the fact that Ruby/Rails is powerful and flexible and deserves trained hands. I kidna hate the Go philosophy of "code written by a junior and code written by a senior looks about the same". That's not for me. I wanna enjoy the progress I make in the language.

The issues I describe with Rails are issues I’ve seen across many different apps and teams.

I have not found these issues occurring to anywhere the same extent in languages with stronger correctness guarantees.