> If your first contact with rails is version 7+ and you’re only comfortable with JS/TS, then you’re not going to get it and might actually strongly dislike it

This is the primary issue with Rails in my experience. It takes intentional effort to internalize the idioms before it clicks and you unlock the magic that makes it so insanely productive. JS devs will keep trying to force backend business logic into Franken-React Stimulus components and complaining it's not very good.

Those people don't choose frameworks. It'll be chosen for them by some LLM and given the prevalence of JS, it'll likely be some flavor of React.

> Accelerate your agents with convention over configuration. Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write and beautiful for humans to review

This is so painful... I can't help but wonder who they're trying to target with such inane slogans.

Rails is amazing, but "token-efficiency" is not on the list of reasons why.

Having grown up playing with LEGOs, I can still distinctly remember the feeling of sore fingers pulling tiny pieces apart after a long session. It wasn't until a few years ago I learned there's an official brick separator tool [1]. Would've changed my life as a kid.

[1] https://www.lego.com/en-us/service/help-topics/article/lego-...

> But I prefer Rust over Zig. The main difference is Rust chooses a "closed world" model while Zig chooses an "open world" model: in Rust, you must explicitly implement a trait while in Zig as long as the shape fits, or the `.` on a structure member exists (for whichever type you pass in), it will work (I don't use Zig so pardon hand wavy description).

Do you happen to have a more specific example by any chance? I’d be interested in what this looks like in practice, because what you described sounds a bit like Go interfaces and from my understanding of Zig, there’s no direct equivalent to it, other than variations of fieldParentPtr.