Hacker News Reader

Comment by midrus | Hacker News Reader

I really hope some sanity comes back to this industry. Rails and Laravel are the best tools by far to build like... 90% of what we build on the internet (Other 10% being offline first apps and stuff like figma, etc).

It just hurts to see how my team, and previous teams I worked with struggle with all the SPAs and microservices, and Go backends and GraphQL nonsense when what we're doing are just fancy crud forms with maybe one or two really interactive widgets overall.

So much time and money wasted just for following fashion.

View on HN

There is no "sanity" lost, nor are the masses "following fashion". That is unfair to those who put real thought, time and effort in their software.

Rails has its strong sides. And its weak sides. Trade-offs are to be investigated. An extremely weak side of Rails, is how it is very tightly coupled to the database. Which -its strong side- is perfect for simple CRUD applications. But it falls down quickly when you have much more event-driven or domain-logic heavy applications.

And yes, I know Rails can be used for this. But just like I can, potentially write a web-app in Bash, it's not where it shines and it will bring you pain.

For Rails, the pain quickly becomes evident when a lot of business-rules are spread out through "Validators". Or when migrations become a pain to manage. Or when you have more and more complexity moved into async jobs. All of these are signs that the CRUD-nature and/or the tight database-coupling is harming you more than helping you.

Choosing some other architecture that better fits your domain is not "following the latest fashion". It's sane, proper due-diligence.

>There is no "sanity" lost, nor are the masses "following fashion". That is unfair to those who put real thought, time and effort in their software.

It's also a forthright description. Developers chase fads, the new shiny, just like everyone else does. Neither are we immune to cargo-culting; I'd go so far as to make the absurd comparison to web apps written in shell script to be an instance of this.

I've been behind the curtain on large Rails apps. Every issue you mentioned is either reasonably mitigated or exists more-or-less equally on other frameworks.

Well, Rails wants to be on a relational database. That's a pretty strong constraint that - say - NextJS or Flask avoid.

I think it's true that it sometimes feels a little crazy that form posts are so much tricker in the SPA world. I sometimes wonder if NextJS has got this right: build a semi-old fashioned web app with a frontend and a backend, so all the data transport in between those is pretty light on code, and then use APIs to data services with nicely defined domain objects.

Still yet to put my money where my mouth is on NextJS though.

Most data is relational. It’s important to embrace the efficiencies and safety guarantees that come along with that.

Yes, a lot of data is relational (although probably most of the world's data is not relational). But not all things need to persist data or are data driven.

If all data belongs to a user or an organization, which is usually the case, and that user does some actions to some objects, is that not relational? It's easy to see how most web apps fall into this pattern.

Building your own API to join data is absolute torture.

> Most data is relational.

No. It's not. It may be in your domain. But it really very much depends on the domain and use-case.

I daresay that purely on information density and amount of gigabytes, most data you use in your business is both document-based and hierarchical: files, docs, directories. But obviously I don't know you or your business, so this is just a wild guess.

This misunderstanding that "data is mostly relational", I believe, comes from the fact that it is easy to make most data relational (edit: to clarify: turning something into X is not the same as something being X to begin with). Much easier than to make most data document-based, indexed, hierarchical or into graphs. For one because the tools (RDBMSes) are mature and omnipresent. Practical: it's easy to put word docs and directories in postgres. But it's hard to have millions of CSVs with profile information accessible on directory structure

And, if what you say were true, that "most data is relational", then the best tool for most of our jobs would be a step-up in relationality from an RDBMS and we should be using graph-databases instead.

I'm talking as a whole. So yes, there are cases where it's not relational but on average most data is relational. A user has many projects. Those projects have many tasks. This is very common to most web-based software used today. Think of all the tools out there that work perfectly with this structure.

Most of our data isn't files, docs, directories. It's data given to us by our users or generated by our own processes. I'm not getting the reference to CSVs and word docs.

Yes, we store uploaded files but the metadata is stored in the database in a row that has some identifier that links to the directory where the file is stored. That works fine. We don't need a document database.

You're just only classifying relational data as data. YouTube's petabytea of data is mostly video and audio. Perhaps some of its data should be stored relationally, but definitely not most of it.

Isn't a hierarchy a relation? Item, item's parent, item's children. It suits itself well to a RDBMS.

> exists more-or-less equally on other frameworks.

You are probably just comparing apples-to-apples here, then. Certainly: replacing Rails with Django or Symfony won't solve the core issues one has with Rails, because Djange and Symfony follow the exact same pattern and architecture.

But architectures (please note that I deliberately don't use the term framework here) like CQRS, Event-sourcing, Event-buses, Actors, Reactive etc. all fit much better for many use-cases than MVC.

All architectures have downsides and upsides. The one's I mention above with which I have experience have severe downsides in other areas. Some of those downsides are solved in Rails, some in other architectures. It's always about weighting trade-offs and choosing what fits best for your use-case.

So please don't just label everyone who made such tradeoffs and chose to forego rails because it doesn't fit them as "chasing fads".

If anything, blindly choosing Rails is just as bad as "following fashion": both is making decisions without any basis.

Django has these same limitations in my experience, but to me the issues are largely caused by the common usage patterns which are encouraged by the official docs and community, and lead to absurd amounts of coupling/ball-of-mud apps.

you can be disciplined about clean architecture/DDD/hexagonal architecture, etc, but you have completely ignore the patterns encouraged by Django, Django Rest Framework, etc etc.

Hide the ORM behind Repository interfaces

Marshall ORM objects into true Domain objects

Do not call to the database in the HTTP adapter/validators

Etc etc

> Hide the ORM behind Repository interfaces

> Marshall ORM objects into true Domain objects

> Do not call to the database in the HTTP adapter/validators

The tradeoff for this is exploding the number of files, directories, and tests, needed for the project. Which has its own cost and overhead.

I'm not experienced in Django.

But doing this in Rails is very hard. It goes against the most strongest of opinions this opinionated framework has. So much, that if you strive for such a design (and you should, IMO) Rails is more in the way than helping you - I know, I tried.

Sure, writing boilerplate is always going to have overhead.

But in my experience the stricter-yet-more-verbose design strongly increases maintainability and velocity in the long term, which should be self-evident due to the massive reduction of coupling.

> Or when you have more and more complexity moved into async jobs

How does this cause pain in rails specifically? Any 3 tier architecture is going to have the same headaches.

> How does this cause pain in rails specifically

As long as the jobs are self-contained, cohesive and decoupled, there's no problem.

They hardly ever are decoupled. Often, jobs will reach back into the model-layer (rather than receiving all data with which to work). You are now coupling yet another concern tightly to your Active-records. In practice, e.g. you have 400 jobs waiting, which will do a `deliver_to(Report.find(report_id).recipient.email)` What happens if your domain-model Report changes to have `recepients` instead?

They hardly ever are cohesive. It's hard to orchestrate jobs - the tooling is simply not there in Rails-. So having tiny jobs spawning other jobs and/or sending eachother messages is not the common way: instead we build Giant Balls Of Sequential Code that perform a job. e.g. that ReportJob above will now (1) collect data, (2) prepare and filter it (3) push it into a template, (4) build a PDF from it, then (5) upload that to storage and (6) build an email and attach it. That is violating SRP on so many levels it hurts to write it down.

And they are hardly ever self-contained. As mentioned above, many jobs will reach back into the models rather than having all the data in their job. Worse: jobs in Rails lack own state and management thereof. So they'll often push (intermediate) state through your models into your database. e.g. that ReportJob may trigger a statemachine changes with things like @report.transition_to(:pdf_generated).save!. Causing all sorts of issues with transactional boundaries (what if an HTTP request comes in that updates the same Reports' name, while you are building a PDF from it?) and thus race-conditions, locking and other issues.

ActiveJob and the likes are very good as an aside on a CRUDdy app. To handle simple commands like notifications, emails, uploads, etc. But they lack severely when your domain is mostly command-based. In those cases, architectures such as Event-sourcing or Actors are a much better fit.

> And they are hardly ever self-contained. As mentioned above, many jobs will reach back into the models rather than having all the data in their job

This is usually for a very good reason.

If you passed in a user model into your job directly and then your job executed with that user there's a race condition here waiting to happen where the user might have been altered in between when the user clicked the button to issue the job and then job itself executing.

This could have very bad side effects like the user receiving an email that they opt'd out of or maybe the user doesn't even exist in the system anymore or your job saves the user back to the DB with stale data that the user updated since then.

It's super common and a best practice to send a unique ID of the user as a job argument and do the user lookup in the job at execution time of the job. This is typically something you'd do in any system, not just Rails. You mention "actors" which hints at Elixir but Oban (Elixir's most popular job processing library) also uses this approach of passing IDs because this problem isn't related to your tech stack.

Also, you listed out 6 sequential steps in your ReportJob example. Based on what you wrote it sounds like they need to be done sequentially and can't be further parallelized. Based on no other context and it being a typical web app I'd keep that as 1 job and have 6 functions calls in the job that have the implementation details for each step so the job itself is very readable. I wouldn't make a jumbled mess of jobs-calling-jobs spaghetti there.

> An extremely weak side of Rails, is how it is very tightly coupled to the database.

You mean that Rails — being an MVC framework — is tightly coupled to (or defined in terms of, even!) the schema you've chosen for your business domain, as understood by your RDBMS.

If that's a problem for you, it's very likely because you're using your RDBMS wrong. (E.g., not taking advantage of abstractions like views+triggers to provide schema [API] stability atop storage [implementation] mutability.)

An RDBMS schema is an encapsulating API for your data, just like a GraphQL schema is an encapsulating API for your data. It's just not in fashion to use it as one — very likely because the spectre of "non-standard SQL" and inter-RDBMS portability has scared all the framework developers away from actually using RDBMSes for what they're for (instead using them as glorified indexed document stores.)

> it's very likely because you're using your RDBMS wrong.

Sorry. But no.

RDBMSes make poor tools for complex domain logic, business-rules, etc. If your solution to "my database and business-logic are too tightly coupled" is to move more of that business-logic into the database, "you're using your RDBMS wrong".

RDBMSes are near impossible to test. They have no source-control, no collaboration models (pull-reviews, CI/CD). They have no deployment strategies. Lack distribution.

Which is why in e.g. Rails all business logic is in the models, commonly and not in your DB schema.

(and with "no", I do understand that it is possible, just that accessible tools, frameworks or even books and course lack severely).

> just that accessible tools, frameworks or even books and course lack severely

Right. Using an RDBMS "correctly" requires that you live in 1985. The result is actually better operationally (for model evolution, at least) than what living in 2022 gets you, though. If your product or service is "about" the data it captures/models in the DB, living in 1985 usually turns out to be worth the sacrifice.

The deeper problem is that because everyone uses RDBMSes wrong, the RDBMS vendors aren't being incentivized to invest into the developer-UX for the features that differentiate RDBMSes from other DBMSes. These features could give you a 2022 experience instead of a 1985 experience, but the vendors just don't care about the 2022 experience.

The exception to the incentives being analytical data warehouse services, like BigQuery and Snowflake. These companies do have these incentives, but they don't have the bandwidth to actually address them; nor do they operate on an open-core model where anyone outside the company could help them with their roadmap. (I say this in frustration; my own company is waiting on one of these vendors to implement support for arbitrary-precision integer columns that aren't actually just uint128s; and "lack of bandwidth to address features" is the common refrain I hear from them.)

And there's also the fact that the major RDBMS vendors are all stuck in a 1985 mindset, where they their primary users are analysts manually typing SQL. I still have yet to see an RDBMS whose pitch is "this database is for machines to talk to; it [literally] optimizes for the case of predictable — or even pre-registered† — queries, at the expense of efficient execution of arbitrary one-off queries." (Because, who runs arbitrarily-complex reporting queries against their service's production DB, rather than shoving those off to some other data-warehouse system? "Production DB for a service" should be its own product category.)

---

† Picture: your applications would register versioned schemas in advance with the DB, including all the static templated queries the application plans to do; and then, in exchange, the application would get persistent a set of persistent cross-connection-sharable query-handles. Rather than allowing the user to define indices, the DBMS uses the knowledge of what queries the app will perform to build whatever indices best optimize its own query plans. Multiple app-versions can be registered + connected simultaneously, as versioned-API "portals" onto different projections of the same data. Etc. You know, the same 2022 stuff you expect to be handling yourself on the business layer — but exposed as part of the first-class meta-schema of your DB.

This overlooks the actual problem. In Rails, you have a db schema, models are tightly coupled to the db schema, then the community push is to put logic into these models.

Having two models pointing at the same table is disregarded as bad idea.

Then, validation for form data is coupled directly to the db schema, thanks to models, not separated by scenario.

Then, the json rendering part is coupled to the model, because it's "convention over configuration" and the community pushes for DRY everywhere, without concern for the cost. So now, the json api is surfacing any change to the underlying STORAGE mechanism of the data, instead of being stable.

Now, add a react + Typescript interface that so popular nowdays on top of it and the result is that an update to the DB schema causes changes in the model, in the controller, in the json view, potentially breaking typings in the frontend.

This is the most common situation in Rails applications.

Now, let's take this situation 2 years in the future:

The json produced by this app is massive, there are many more new endpoints. Each endpoint has json rendering, but DRY is a hard requirement, without evaluating the risk, so every json rendering for a given model is reused in other json rendering objects.

Now one change of the underlying storage ripples through many, many API endpoints, potentially affecting hundreds of files.

I think you misunderstood the thrust of my argument.

A Rails model that talks directly to an RDBMS table, does indeed couple your business logic directly to your data storage representation. I'm not arguing with that.

There are two ways to fix this, though. And most people only consider one of them.

The "software-oriented" way to fix the coupling — and the one that software developers usually reach for — is to embrace domain-driven Hexagonal architecture on the inward edge: to create a domain layer within the business layer that defines its own non-DB-synchronized domain objects; and then to write an explicit DB gateway that can be Commanded and Queried with those domain objects, where that layer translates those domain objects into relational row-tuples.

(Note that this is separate in concept from embracing Hexagonal architecture on the outward edge. Gateway abstractions + internal-domain/external-view model isolation+translation are well-suited concepts to encapsulating the different rates-of-change needs of your system vs. the external systems it interacts with. That's what the Hexagonal-architecture concept was invented for, and why MVC separates Controllers from Views.)

The "database-oriented" way to fix the coupling, is to continue to model your business domain within the DB, but to model it in a faceted, denormalized way, such that each query-schema gets its own view, and each command-schema gets its own writable view driven by a trigger + stored procedure, and the tables where data actually lives (and what columns/types/indices they have) are an implementation detail of how those views were written. Just like in OOP, you hide the data, encapsulating it behind an API (the views.)

When your Rails models bind to these "schemas", each Rails model then inherently represents a Query-result or a Command-changeset — without having to complexify your business layer. These objects can just be your domain objects. You're getting your domain objects directly from the database, and sending them directly into the database, because the database itself contains the translation layer mapping the domain into the storage representation. Just as with the first approach, you're free to change these mappings at any time — you just add some DB schema migrations which add/update/remove the views backing the models, and re-point your models at the new views. (If you create these views using unique-per-version names, then different versions of your app can even live in peace together, with all their versioned bits-and-pieces of translation layer co-existing and being shared between where relevant.)

Oh, yeah I definitely misunderstood your point.

This makes sense and it's an idea that makes me excited, I wish there was a community drive toward that.

I do think that most Rails developer will dismiss it because some reason like "It's weird to have a Model backed by a view" or something along those lines. I wish the Rails community pushed (way) harder on dramatically increasing SQL knowledge, because it's so important to the whole framework.

Instead most of that SQL knowledge is hidden behind active record, making it incredibly hard to acquire.

There is one thing that this approach doesn't solve, and that is the inherent flaw of activerecord: having Save on the business logic entity makes it so that returning such object back from a business-logic method is dangerous, since now any other code could potentially write to the DB (and this is what usually happens due to lack of software design principles).

I suspect you are going to suggest something along the lines of "set readonly some records and command records are only used in specific spots", which could make sense!

Calling it "fashion" is disingenuous.

I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server." We also had no typing then, so every bug was a runtime bug. Hopefully it's improved in the years since...

I've been happily running Go backends for the past 7 years now, and they're stable and fast and easy to refactor.

This is my experience, too. I'm currently working on a TypeScript+Node service, which is decent, but Go is my preference these days.

> I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server."

This hasn't been a serious problem in a decade.

> We also had no typing then, so every bug was a runtime bug. Hopefully it's improved in the years since...

The ecosystem has been introducing gradual typing, but even at high scale, types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug.

(ex-Braintree engineer, we processed billions of requests on Rails)

> types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug.

If you took that away from what I wrote, I apologize. I meant that without a compiler and type-checker, you would only find bugs at runtime. In my experience, the vast majority of these would be easily discovered by a compiler. Presumably that experience is shared by Ruby devs since they're now adding type-checking.

> This hasn't been a serious problem in a decade.

That may be true. I haven't had any need to revisit Ruby or Rails since I moved to Go. But it was a serious problem with no workaround, and I've never encountered any scenario like that since switching to Go.

If you're finding bugs in production that a compiler or typechecker could have found then there's something seriously wrong with your test suite. That's how Rails works, if you don't have 90%+ statement coverage it will be hell.

IME, adding that 90% statement coverage is much of the tedium and frustration of the job in Ruby-land--in particular for things that you just get solved for free with something like TypeScript.

It might have improved somewhat, but I find myself pretty comfortable with a much more pared-down test suite that focuses on correctness tests at logical module boundaries in TypeScript, rather than verifying things the computer can just do. I do look forward to seeing Ruby's gradual typing become more entrenched in the ecosystem, though, because I like the language--I just don't like using the language professionally because of the additional manual work I find myself doing.

> IME, adding that 90% statement coverage is much of the tedium and frustration of the job in Ruby-land--in particular for things that you just get solved for free with something like TypeScript.

I would argue that if your unit test is only testing things which would have been shown by the type system of another language, you are testing at too low of a level. In addition to being tedious, such tests are often very brittle.

Those tests are brittle, and they're also the thing that protects you at module boundaries when those boundaries are being hammered on by different groups of people.

Having them not be necessary is nice.

On the other hand, if you have a compiler/typechecker that finds things that your test suite could find I will always reach for the compiler/typechecker. No sense in writting tests against something a standard tool will find aside from sanitizing data from your inputs.

My experience with ruby is often documenting the expected argument and return types with comments and then writing code and/or tests to enforce the types.

Having also used Go a fair amount, I very much prefer the real type system which both documents and enforces.

I enjoy both languages though.

I’ve worked on many large rails apps at scale and large Java apps at scale. There has been no significant difference in the big count between them despite Java having static types.

Java has a bad type system that makes it awkward to express many well-typedness guarantees (too much boilerplate to create new types (classes or interfaces), no sum types (tagged unions), no null safety, exceptions are a mess especially with lambdas, and don't get me started about all the reflection madness of popular frameworks that throws type-safety out of the window, etc.). As a result you don't get much safety in exchange for all the boilerplate. Still, I find Java massively easier to refactor. You can remove a field from a class and verify that you've changed all the places that were using it (barring reflection, of course). In Rails, that requires at least running the whole testsuite which could be very slow (because Rails tests are often very slow). And even then, you have no guarantee you didn't miss a particular case.

Languages with better type systems do exist (Rust, Swift, Kotlin, from what I hear even typescript?, and all ML type languages including Haskell, ...). They are much better at preventing bugs. My life became better when I had to stop worrying about NPEs, for example.

I’ve had the same experience with Swift, Kotlin, and typescript. No clear difference in quantity of bugs or speed of development.

While I do like static typing, I find more bugs because people have no clue about security and they think they can do it better by just tying together a few libraries and storing a jwt in local storage or they forget to handle Prisma exceptions or they didn't know what session fixation is or because they forgot to consider a corner case of foreign key exceptions from the database library, etc, etc than because somebody passed a string where an integer was needed.

Giving up frameworks with 10+ years of hardening and documentation and libraries and support etc just because of coroutines or static types or nice syntax or because that's what google does then I should do it too makes absolute no sense to me.

Yes. And new projects are even better started now with Rails than in the past (aside from the JavaScript hell still plaguing rails).

Active storage and variants make life so easy.

> (aside from the JavaScript hell still plaguing rails)

It's not too bad now, set up a Node environment and there's first class support for using vanilla esbuild or if you want to go without Node entirely there's import maps and lots of goodies at the Rails level to help you manage your JS dependencies. Technically Webpack is still supported too but it's vanilla Webpack instead of Webpacker, that's all part of the new https://github.com/rails/jsbundling-rails abstraction for using a number of different JS bundling tools with their stock set ups.

Personally I went with the esbuild + tailwind combo and it's been smooth sailing. I have an example app here https://github.com/nickjj/docker-rails-example.

> [...] types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug.

That's a typical response from dynamic typing advocates, but the response is that in a language with a good type system, many more things can be type errors than would be in a dynamically typed one.

For example, from my time writing Ruby, trying to call methods on `nil` was an incredibly common error, but this is simply a type error in some more modern statically typed languages (including Kotlin and Swift).

I agree, I think it’s a good reason to use the static typing in Ruby > 3.0.

Any static analysis tool you can use to catch bugs before runtime in production is something we want.

A substantial number of bugs I see where a method is called on nil are business logic errors that result in something not being where it's expected, and those bugs would just manifest differently at runtime with static typing. Every web app I've ever seen in a statically typed language has plenty of logic relying on "unwrap nullable or raise error" mechanisms.

That may be your experience. It's not mine. Null-safety forces you to think about the exceptional case (and whether it is supposed to occur at all). If you do so poorly, yes, you'll have errors too. But it's not something that can happen to you by accident.

For example, if you have a method A that gets a foo from the method B and then does something to that foo, you might get a runtime error if B returns nil. If this happens over dozens of method calls, it can start to become very hard to see where the error was introduced.

But if you know that B is always supposed to return foo and never nil, then the compiler can show you where the error in your definition of B is ahead of time.

The value of null-safety is not in making everything nullable and then just proceed with unwrapping etc., the value is that we can make a lot of types explicitly non-nullable.

I don't think it's controversial that a good type system allows to verify more soundness guarantees at compile time. The only controversy is whether it's worth the effort.

I agree with you about the value of static typing and non-nullability, don't get me wrong. My experience is just that _web development_ and other use cases traditionally favored by dynamic interpreted languages tend to have a lot of unexpected nulls of a type that are not prevented by strict typing. There are other types of bugs that I absolutely expect to see less of with strict typing.

> I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server."

Nothing is perfect. In my book restarting a server because of memory leaks is an acceptable trade off versus all the crazynes of having to decide and maintain on how to tie together a database, error validation, background jobs, translations, react, redux, an API to interface with the backend, logging, etc, etc, etc. Also, Go is just part of your system, I'm pretty sure you also have a frontend stack, and complexity increases a lot as I explained here. Compare that to Laravel+Livewire or Rails+ Hotwire. Night and day. I'm pretty sure any serious business will take the restarts any day vs the increased complexity and developer time.

> I've been happily running Go backends for the past 7 years now, and they're stable and fast and easy to refactor.

Yes, and I bet something built in 7 years with Go would have taken 7 months with Rails or Laravel.

On the static typing stuff, I'm with you on that. PHP (and Laravel) are a bit closer to that, but nothing is perfect. And for Web Development using Laravel or Rails is a good trade off.

As someone who seems to work with Go backends quite a bit, what's your preferred way of doing this? I've been playing with net/http compatible routers and I've been liking them, but interested to hear what someone with more experience uses. Any good way of dealing with common boilerplate that frameworks like Django and Rails help remove?

On small projects, I just write out the boilerplate. It's annoying but it's straightforward to read and revisit years later.

On larger projects (100k LOC+) I use chi for my router in combination with codegen via sqlc and moq, and I wrote a small program to generate the routes for me automatically with a config file.

sqlc is very interesting. Gives me sqlx (from Rust, not the Go package) vibes. Definitely will play around with this.

There's a variety of projects out there. gorilla/mux, chi, httprouter are all pretty commonly used for just defining routes. If you want a full on framework, gin and beego are also common. For the database (I'm unfortunately mainly familiar with postgresql related projects) there's pgx, sqlx, gorm, and then code generators like sqlc such as sqlboiler and entgo.

Golang encourages libraries and frameworks with much smaller surface, so there is indeed a boilerplate issue, but that's also an issue with golang as a whole.

Go is good and all, but it's odd to compare it to the vast feature set that Rails provides. The point of Rails is to give you standard tools so you don't have to consider / reimplement / configure / hook up e.g. background processes for every app you build.

> I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself

Curious - were these actual memory leaks or Rails memory bloat due to how ruby allocates memory and holds on to them?

I’ve seen a few times where a company replaced one guy using a Rails monolith with jQuery and replaced em with a 30 person team that is far less effective.

THIS

I think that if we were more pragmatic and less about following the current fashion or trying to do what FANG does (which probably is just the opposite of what everyone else needs) we wouldn't be in such a high need of developers... which... I shouldn't be saying out loud probably :-)

Also, note that when not going the microservices/spa/kubernetes route, the alternative is not "old style reloads on every click and jQuery spaghetti", I'd say that's equally as bad.

Nowadays there are alternative middle ground solutions such as Livewire, Hotwire, LiveView, Unpoly, Htmx, etc which provide a great way to organize the code and keep it maintainable.

I think these are all bad ideas on the other extreme. Once you incur the cost of a round trip to the server the additional latency due to sending HTML instead of JSON is pretty close to 0. You really only need something like Turbolinks to avoid a full page reload/render.

Amusingly enough at $Current_Job the JSON we send back that is larger in size than the HTML it's rendered into. We'd likely have better performance doing all server side rendering + Turbolinks.

Yeah, this is the case I was talking about with the 90% of cases I was referring to.

At a previous job, we had a many, many thousand lines codebase of typescript, redux, observables, epics, thunks, custom server API libraries, websockets, Elixir backend, Kafka to communicate with other microservices, etc, etc..for...a frigging signup wizard.

Which then failed in so many stupid ways, had almost no server validation (everything unexpected was a 500) and it took days to do the smallest of the changes. But hey, don't dare to suggest doing this with Laravel would take 2% of the effort because you'd be crucified in the next frontend guild meeting.

At the end, it's all trade-offs.

After working with Rails for 10 years, I ended up preferring the opposite end of the spectrum of just using small frameworks like Express and just writing our own boilerplate.

I agree with Elm's take on boilerplate: it's not boilerplate and glue code that makes application development hard, and I don't think it's always a net positive to build abstraction around it like you see in large frameworks. As a Rails app grows, I just find myself spending more and more time unrolling abstraction to figure out what's going on.

Most things, like authentication, I prefer to just read in the application code itself to see what's being written to the cookie rather than dissect, say, the highly-abstracted Devise gem in a Rails app to debug session issues.

Yes, me too. But it makes absolutely no sense business wise. We like to play with tech, and learn and use the new shinny. While you're writing your frontend in elm and building your graphql API with Apollo and your serveless functions on kubernetes your causing a cost to your company which could have been avoided.

That's not engineering. That's playing with Legos just because we can.

I don't think this is a fair characterization of their post. They aren't playing with legos. Rails trades boilerplate code savings for abstraction. The GPs point is that boilerplate isn't hard to write while abstraction makes everything harder. And I think it's a fair criticism. Large Rails projects are difficult to work in because of that abstraction. It can be hard to even figure out what code is running let alone identifying bugs there.

The abstraction hasn’t hindered me much and I work on a monolith.

One problem I have faced is when the amount of database queries on a page explodes it becomes hard to optimize without caching. I would prefer to avoid caching but that doesn’t appear to be the rails way (and for obvious reasons).

Also, at a company with a Rails app you do sometimes get other sources and processes polluting your Rails app. And when that happens you can’t utilize the efficiencies that rails provides.

> Large Rails projects are difficult to work in because of that abstraction. It can be hard to even figure out what code is running let alone identifying bugs there.

I read this a lot, but I have never experienced it, even on projects that I have joined after they were already huge.

Rails conventions are pretty reliable. Most Rails developers choose predictable patterns that resemble the framework conventions. Obviously people coming from other frameworks will often build things differently (sometimes fighting Rails to do so), but a few minutes in the REPL makes everything clear.

Throw a junior rails developer in a big app and let them work. Is shocking the amount of overhead we get used to as Rails developers.

You get used to it, but it shouldn't be like that

I think this is a universal truth, with nothing specific to Rails.

What framework/language/environment can you think of where a junior dev can be dropped in to a big project, and not flounder?

It's probably a problem related to any framework with a lot of magic.

With Go and Phoenix, this problem is not there. They are very explicit, so when something unknown is found, it's written there what it does.

With rails there are things going on at all time: write a record? Some stuff is written on the db, other stuff is triggered, some stuff depends on thread variables, then other stuff is magically saved in other tables, other is updated (touched), which in turn might trigger more things. It is painful for a new developer because all of this happens implicitly.

Coming from a systems background, I might have a higher tolerance for "implicit" actions. They're always there, and almost never covered in code, although your code depends on them to function.

But I think I understand your point. You can ask a neighbor to "run to the market to get bread and milk" and expect reasonable results -- but you'll need to be more explicit with a foreign visitor.

Rails optimizes for neighbors, but in fairness the phrasebook and guidebooks are excellent. :)

They are, indeed

>I read this a lot, but I have never experienced it, even on projects that I have joined after they were already huge.

You've never been in an IDE, tried a go to definition, and have it not work?

No, but I do not use an IDE to write Rails code.

I can think of a few cases where Rails architecture would be relatively difficult for IDEs: ActiveRecord callbacks, and of course metaprogramming and magic methods like "find_by_x".

In most cases this sounds like a mismatch between IDE and framework, but the "method_missing" chain could be a unique challenge.

I avoid using that construct in application code, and just accept that some of it exists in the framework -- but that it's almost certainly not the cause of any problem I'm debugging.

But sometimes it is. As an example, I've been trying to track down the code that runs for uncaught exception in a controller. It's (probably) somewhere in ActiveController but there's no easy way to find it.

The complexity is still there even with microservices or a Go or a Clojure codebase, it's just that either you've created a mess or you've created your own framework.

In my experience, you either use one of these big frameworks, or you end up building one. I've seen that happen more than once, and these "home made frameworks" are far worse, less documented, more buggy and have like 6 different patterns depending which generation of developers before me built it (and of course, I had left own opinions and mistakes too).

Writing microservices in Go or Flask or Sinatra won't make all the complexity related to the Web go away magically. The're still there. Now they're distributed across services and implemented mostly from scratch.

If you are not FAANG and don't use one of these big frameworks, you have only two options:

1. Create a distributed spaghetti mess of random libraries tied together 2. Build your own "big framework".

I've been many times in companies which were through the process of breaking up the monolith into separate services. It never finished, and every single service was just a proxy to the monolith, and everything took twice the time to implement, and now both all the services and the monolith have to be kept running and maintained. The only "positive" was the group of devs that wanted to play with new tech and somehow managed to become a team that only works on one of those services, so now they're "free" from the monolith hell. Business wise it was a disaster, would have been better to just let those engineers find another job with the tech stack they preferred and hire new ones willing to work on a single codebase and keep things simple. Again, this was not a Google scale company, these were 50 ~ 100 engineers organizations.

How can it not make sense, if when there is an issue with devise, then it takes weeks to debug vs 1 day with the handrolled code?

I’d add Elixir and Phoenix to that list and then agree with you.

I'd add Phoenix to the list when it gets its documentation in the same echelon as that of Rails or Laravel. It may be as productive if you already know how to use it, but good luck building anything non-trivial on your own if you don't.

What do you find lacking in the Phoenix docs? I've always been impressed with the docs in the major Elixir and Phoenix libraries.

There's a good deal that I feel is lacking, but a big issue is the lack of continuity of documentation between Phoenix's component parts. If I want to build a CRUD app with Rail, Django, or Laravel, then I can get all the information I need from their docs. If I want to do the same in Phoenix, I'll have to jump between the docs for Phoenix, Ecto, Plug, and HEEx/Liveview.

Rails, while it has its equivalent of these modules, presents them in a cohesive manner and makes it clear the role they play in the greater context of the application. Phoenix doesn't make it nearly as clear and instead of being able to gradually learn these various concepts as they become relevant you have to take on the burden of them all before being able to even begin to be productive.

Have you looked at the Phoenix Guides [1]?

[1] https://hexdocs.pm/phoenix/overview.html

Yes. They do a poor job of the above and I still stand by what I said.

Don’t you usually learn how to use your tools before you build with them? This feels like a strange response.

I've always found the Phoenix docs to be more like references. There's "guide-like" aspects to it but in my opinion it's no where near the level of where the Rails docs are. I agree with the person we're replying to, I almost always found myself having to research third party sources when learning Phoenix (blog posts, IRC, etc.) to get answers to questions that I never had to ask about Rails, Flask or Django because their docs covered it very well.

The Rails doc feels like you have DHH at your side guiding you on exactly how to do something in the context of a practical application and whenever you think to yourself "that's great, but what if I want to do...", often times the very next sentence in the docs will answer your exact question.

The Rails routing docs https://guides.rubyonrails.org/routing.html are a great example of this when they talk about namespaces and scopes but there's a million other examples.

It feels like it was written by folks who have been through the thick of it and back 100 times over to extract out the exact questions folks would have when using various features of the framework. Each piece of the docs feels like it's a mini book written on par with any book on a technical subject and then there's a completely separate reference guide docs with more examples.

Even the styling of the page itself just feels good. It's really easy to skim and navigate. The Phoenix docs feel more like a big wall of text with a few small headers and code blocks. It's hard to explain but personally my brain identifies the Rails docs as easy to mentally parse where as the Phoenix docs are not based on nothing more than the styling aspect alone.

Overall the Rails docs feel like they are written with a ton of empathy around the person reading them, completely holding your hand from beginning to end to solve a practical issue which is exactly what you need when learning something new. The reference guides are always there if all you care about are a few quick examples.

That’s true. Rails docs are fantastic.

Don’t get me wrong here, I’m a big Rails fan as well. Been using it for a decade at this point. It’s the best development experience out there. But eventually, you’re going to run into issues that are harder to address with it. Happens on every big project I’ve run into.

But, they all became big projects thanks to the productivity of Rails.

As a bronze league engineer who still pulls a decent wage, you absolutely do not need to understand your tools to build things.

I like Phoenix, I really really do...but you are correct regarding docs. The documentation in Phoenix is fine for "what does this function do?". However, if you want the Rails Guides experience - it's just not there.

Reply on news.ycombinator.com