I say this genuinely enjoying JavaScript programming, but my mind immediately jumped to "as opposed to immediately, like most JS frameworks?"

Does HN not use lockfiles or something? Your node/npm project will work just fine if you use the same version of node/npm and have a lockfile.

Maybe you're using npm i (which can upgrade dependencies in some cases) instead of npm ci [0] (which always uses the lockfile dependencies).

In any case, this is a general problem of package managers and has nothing to do with the language. You'll need something similar if you're using _any_ external dependency in Rust, Python, Go, etc.

[0]: https://docs.npmjs.com/cli/v10/commands/npm-ci

A good chunk of chaos in Rails apps is caused by people who either insist they know better than the out-of-the-box solutions, or they “just prefer it my way.”

ActiveRecord can both offer fast development and create issues (especially those that only come to bite you later). It exists in a multi-faceted environment. Tradeoffs, as always.

I think most would agree. It is the "doesn't make much sense" part that we're discussing, though. How does it not make sense when you seem to have the same opinion of it? It seems, as an onlooker, that it makes perfect sense to you.

Well, what remains of Rails or of ActiveRecord once you remove the part that's done outside the database? It just seemed like a very shallow view of what rails is.

It is just not tenable where latency poses a practical constraint under an implementation that is not theoretically sound. There are plenty of hacks to work around it, though, so it is not really a problem in practice. To call those hacks to work around a system with shortcomings "using the database properly" is a bit of a stretch, though.

Just so we're clear, the use of JOIN, IN, etc. are not hacks in and of themselves. They serve a purpose even where latency doesn't exist. But when applied to solving the N+1 problem, their use is a hack. Again, one that gets the job done and solves the problem – hacks aren't bad, but is not theoretically sound. If you did not have latency constraints to contend with, you would not prefer it.

The better question is: Why use a database that sucks? Latency periods are small enough in SQLite, for example, that you don't have to worry about the N+1 problem in any real-world situation. It doesn't have to be a problem in need of hacks.

Previously, ActiveRecord gave newer programmers a legible, fluent interface to the database in a language they already knew. So instead of learning SQL, we abused the heck out of AR. I think that the industry, and rails itself, has matured since then and I see a lot less of this nowadays.

EDIT: I'm not bothered by this, but this is a very odd comment to downvote. What on earth is so offensive or distracting about saying someone else is likely more knowledgable than you are? Very confusing.

I've spent my whole career on Rails and I think it's amazing when starting small but mature applications are a nightmare to refactor. Every monolith Rails app feels like it hits tech bankruptcy after ~5 years.

I've been using Rails since 1.0, owe much of my career to it, and still think it's an incredible framework that I love using.

But I have seen plenty of startups—mostly filled with junior developers—who don't have the maturity and experience to avoid some really bad ideas absolutely wall themselves into a corner. Thankfully the worst of this was in the Ruby 1.8 and Rails 2.3 era, but it still happens today.

A lot of the issue is the tendency that Ruby libraries have toward exposing internal details that end up getting relied upon (Hyrum's law in action).

  With a sufficient number of users of an API,
  it does not matter what you promise in the contract:
  all observable behaviors of your system
  will be depended on by somebody.

It's interesting to think about the implementation being necessarily coupled with the interface. In some context that's obvious, but the idea that another implementation can't be freely swapped in -- because nuanced behavior (sometimes called a bug) in the original implementation is still expected -- is one I hadn't, as such, thought much about before.

I think the fact that we are trying to shove typing onto Ruby with Sorbet and RBS are a sign that maybe it's not the best programming language once you reach critical mass.

It's possible the grass is greener and this is what happens to every tech department... but I'm not totally convinced. I always hit a point with Rails apps where I can see the refactorings I'd like to make but I know it's not worth the pain of the inevitable `NoMethodError` at run-time in production. And that's _with_ a giant test suite.

Anyway over 10 years later now and I find myself writing an API and my initial thinking was to return to rails but then I remembered the bad experience (which was probably my own fault I acknowledge).

Now I find myself writing this API in Rust because the ethos that an app can actually be done is attractive to me. It's taking me longer to write but hopefully I've made a good decision!

The API I'm working on is pretty simple and I want to finish it and forget about it so in my circumstances it seems that rust is a better choice.

If someone gives you a paint-by my-numbers page, and you just scrawl all over it… is that the “fault” of the page?

* Time from idea to deployed solution * Ease of pivot * Ease of finding other devs who can take over

If I were a staff engineer at a large company with an existing tech stack tasked with spinning up some new internal microservice, I'm probably not choosing Rails.

But if I'm truly greenfield on a strict budget, still searching for product market fit? If that application ever truly outgrows rails (and it can become wildly successful without doing so --- look at stripe, instacart, github, shopify) then we've already won by surviving long enough for rails to be the problem.

Keyword arguments and pattern matching have improved this quite a bit, but not everybody is using it yet. I'm not sure how much Rails is using it either, which doesn't help.

It's def a dicey situation, but improving.

    This is exacerbated by ruby's tendencies towards 
    "fluent" interfaces, which is actually code for 
    lots of methods that take undocumented hashes of 
    arguments

    and hash access with strings and symbols? nightmare fuel.

    After running a number of rails applications in production 
    for going on a decade, this is really hard,

The issue is one's apps dependency graph. You keep dependencies flowing in one direction. Or you do not and you get spaghetti. I have not worked with languages that are really better or worse at this.

To take the example of a typical Rails app: it's very easy to add code to your Model A that depends on Models B, C, and D. Do that in a few models and...boom! spaghetti! Rails does not discourage or warn about this in the slightest.

It's relatively easy to avoid: have a rule that "no model can contain a reference to another model. if you have to do a thing that involves two models, put it in a service class" or some such. Of course, nobody ever does this.

Are there languages and frameworks that encourage/enforce The Right Thing in a more active way?

I don't think so, as evidenced by the fact that I'm still so pro Rails after a decade of doing this. But that doesn't mean we can't be vocal about the things that still suck.

> I like hash access with symbols

Oh, I vastly prefer symbol access to string access, but this is really a ruby problem, not a rails problem. The fact that I can pass `{ "foo" => "bar" }` and `{ foo: "bar" }`, and my method has to either call `with_indifferent_access` or _strictly_ enforce being called with one of the two access types is a huge footgun, because improper access doesn't result in an error, it just results in a `nil`.

Official way? I thought there is none.

As long as there is no support for gradual typing in the core language it will never be used outside of niche programming.

And then I have a hard time imagining that Rails would use it anyway. Unless the performance boost would be tremendous.

is the "officially supported" one. It's terrible, as is Sorbet. No offense to anyone involved with either of the projects, they just miss the mark in pretty fundamental ways.