Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Returning to Rails in 2026

markround.com

Post reply on HN
Print view View original

231–240 of 254 posts

Re: Returning to Rails in 2026

#231

Post by oorza »

x0x0 wrote: post #198
bartread wrote: post #187

Earlier quoted context omitted.

> Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript. All right, fine: TypeScript uses structural typing which is if you like a specialisation of duck typing but, whatever, compared with JS's unadorned duck typing it still leads to embellishment of the resulting code in ways that I don't enjoy. I've been using TypeScript across different projects at different compa…

I found it not just to lead to embellishment, but (1) the problems it did flag mostly would be caught by minimal testing; whereas (2) it regularly missed deeper problems. For an example of the latter: using TanStack (React Query) api caching, you have different data shapes for infinite scroll vs non infinite scroll. There were circumstances were an app confused them. Typescript had nothing to say. Nominal typing easi…

> the problems it did flag mostly would be caught by minimal testing

Testing is more expensive up front and in maintenance than type annotations. A test suite comprehensive enough to replace type annotations would have an ass load of assertions that just asserted variable type; if you were involved in early pre-TS Node, you remember those test suites and how they basically made code immutable.

> (2) it regularly missed deeper problems

This is a skill issue. If your types do not match runtime behavior and you choose to blame the programming language rather than your usage of it, that's on you. There are a lot of unsafe edges to TS, but a diligent and disciplined engineer can keep them isolated and wrapped in safe blocks. Turn off `any`, turn on all the maximal strictness checks, and see if your code still passes, because if what you said about infinite scroll is true, it won't.

Re: Returning to Rails in 2026

#232

Post by 9rx »

akoboldfrying wrote: post #230
9rx wrote: post #226

Earlier quoted context omitted.

> The goal is to do this parsing exactly once, at the system boundary You are only parsing once at the system boundary, but under the dynamic model every receiver is its own system boundary. Like the earlier comment pointed out, micro services emerged to provide a way to hack Kay's actor model onto languages that don't offer the dynamicism natively. Yes, you are only parsing once in each service, but ultimately you a…

> but under the dynamic model every receiver is its own system boundary I'm not claiming that it can't be done that way, I'm claiming that it's better not to do it that way. You could achieve security by hiring a separate guard to stand outside each room in your office building, but it's cheaper and just as secure to hire a single guard to stand outside the entrance to the building. >micro services emerged to provide…

> I think microservices emerged for a different reason: to make more efficient use of hardware at scale.

Same thing, no? That is exactly was what Kay was talking about. That was his vision: Infinite nodes all interconnected, sending messages to each other. That is why Smalltalk was designed the way it was. While the mainstream Smalltalk implementations got stuck in a single image model, Kay and others did try working on projects to carry the vision forward. Erlang had some success with the same essential concept.

> I'm claiming that it's better not to do it that way.

Is it fundamentally better, or is it only better because the alternative was never fully realized? For something of modern relevance, take LLMs. In your model, you have to have the hardware to run the LLM on your local machine, which for a frontier model is quite the ask. Or you can write all kinds of crazy, convoluted code to pass the work off to another machine. In Kay's world, being able to access an LLM on another machine is a feature built right into the language. Code running on another machine is the same as code running on your own machine.

I'm reminded of what you said about "Parse, don't validate" types. Like you alluded to, you can write all kinds of tests to essentially validate the same properties as the type system, but when the language gives you a type system you get all that for free, which you saw as a benefit. But now it seems you are suggesting it is actually better for the compiler to do very little and that it is best to write your own code to deal with all the things you need.

Re: Returning to Rails in 2026

#233

Post by pcthrowaway »

e12e wrote: post #107
jeppester wrote: post #84

Earlier quoted context omitted.

Give AdonisJS a try, it's pretty much the JS sibling of Laravel and RoR.

Adonis is nice, but still young and lacking features. And in my experience very verbose compared to rails. That said, absolutely worth a look.

Adonis is over 10 years old... that's like 3 generations in software years, and 20 generations in web/Javascript.

The reason it's lacking features is because it's not very popular and hasn't gotten much outside contribution... I seem to also recall something about the founder being too hostile to outside ideas/suggestions also, but I could be misremembering

Re: Returning to Rails in 2026

#234

Post by liamgriffiths »

To all the folks in here that bemoan the lack of static types, I'd like to mention there are some great solutions in this space, eg. https://sorbet.org/

Having the productivity of Ruby + the static typing and LSP integrations is a wonderful combination. Sure, it might be less aesthetic than some might like, but at least in my experience, it works very well in practice and supports most of the needs I have from a type system for writing and understanding conventional software.

I'm rooting for further developments in this space because I love language and systems that can leverage it's strengths and layering on a type system makes it a very formidable technology for building real world products.

I have not used Rails in a few years, but I can also say that the Sorbet typing support for the framework is definitely there too -- to great credit to the folks at Shopify allowing users of the framework to benefit from this tooling.

I would happily work on a Rails system today too. It's an amazing testament to the community how the design has been able to continue to develop to meet the needs of the many developers building with it up to this point. I hope more people feel the same joy I do discovering the kinds of things they can make with the language and frameworks like Rails.

With the amazing advancements with the AI tools we have now the only real limits are with how big our imaginations and ambitions can get.

Re: Returning to Rails in 2026

#235

Post by gls2ro »

leke wrote: post #162

Ruby and RoR is cool and all, but as these web apps got more and more complex, the need for static types became too important. What gave PHP it's edge was types and is the reason I'm still using it after nearly 20 years. PHP seems to implement those important things just in time. OOP, better OOP, types, speed boost, and next probably concurrency.

Is is the need for static types or the need for better testing that is not focused on coverage of line of code?

Because if the domain logic is getting more complex then more types will not catch the bugs unless you are willing for codify business rules within types so then you have to test the types.

Re: Returning to Rails in 2026

#236

Post by shanjai_raj7 »

chrisweekly wrote: post #113
shanjai_raj7 wrote: post #79

we run next.js on the frontend and the page router to app router migration was really painful. rails having stable conventions sounds very good when you go through something like that. I keep thinking about this trade off - move fast with the latest thing or just pick boring tech that works for 5 years.

nextjs pages -> app router is a massive change: new paradigm, practically replatforming.

yes exactly. we had to rewrite most of our data fetching logic. there was no real way to do it gradually, one day we just had to commit and do the whole thing. took way longer than expected.

Re: Returning to Rails in 2026

#237

Post by kreyenborgi »

sensanaty wrote: post #110

I love Rails, but after working for a few places with huge Rails codebases and then several other places with .NET and other frameworks with actual typing, I just can't go back to Rails for anything that isn't a personal project. Working with a large codebase with an untyped codebase is just a nightmare, even with powerful IDEs like RubyMine that are able to cover some of the paint points. I wonder how good Sorbet is…

https://ihp.digitallyinduced.com/ is a rails-inspired framework for Haskell that tries to get the best of both worlds. Highly recommend trying it if you have a weekend

Re: Returning to Rails in 2026

#238

Post by robertlagrant »

akoboldfrying wrote: post #230
9rx wrote: post #226

Earlier quoted context omitted.

> The goal is to do this parsing exactly once, at the system boundary You are only parsing once at the system boundary, but under the dynamic model every receiver is its own system boundary. Like the earlier comment pointed out, micro services emerged to provide a way to hack Kay's actor model onto languages that don't offer the dynamicism natively. Yes, you are only parsing once in each service, but ultimately you a…

> but under the dynamic model every receiver is its own system boundary I'm not claiming that it can't be done that way, I'm claiming that it's better not to do it that way. You could achieve security by hiring a separate guard to stand outside each room in your office building, but it's cheaper and just as secure to hire a single guard to stand outside the entrance to the building. >micro services emerged to provide…

> I think microservices emerged for a different reason: to make more efficient use of hardware at scale.

Scaling different areas of an application is one thing. Being able to use different technology choices for different areas is another, even at low scale. And being able to have teams own individual areas of an application via a reasonably hard boundary is a third.

Re: Returning to Rails in 2026

#239

Post by OpenClawguru »

liamgriffiths wrote: post #234

To all the folks in here that bemoan the lack of static types, I'd like to mention there are some great solutions in this space, eg. https://sorbet.org/ Having the productivity of Ruby + the static typing and LSP integrations is a wonderful combination. Sure, it might be less aesthetic than some might like, but at least in my experience, it works very well in practice and supports most of the needs I have from a type…

[dead]

Re: Returning to Rails in 2026

#240

Post by lowenbjer »

blandflakes wrote: post #218
lowenbjer wrote: post #213

Earlier quoted context omitted.

I know that feeling. Just because a tool is good doesn't mean you enjoy using it. I moved deeper into streaming infra with Python, C/C++, Go, and funnily enough Elixir. Then a complete path change into fintech and later AI/ML, which meant a lot of JavaScript/TypeScript and reluctant Python. I appreciate the Python ecosystem but find the language itself ugly to read and write. Always a last resort for me. Today it's m…

Ha, I can relate WRT Python. I've been doing more Elixir these days for both a really pleasant web experience and because it has some unique primitives baked into the ecosystem that most JVM projects I work on spend a lot of time approximating through grotesque frameworks.

Ha, same. I wrote a VOD transcoding orchestrator in Elixir that triggered libav transcodes and custom packaging code in Python. Loved the syntax, and in particular the pattern matching in function headers. It was so clean for recursive branching that I ended up favoring recursion over conditionals and loops everywhere. Whether that was overuse or just good taste is subjective. We did hit a real scaling problem with the BEAM though. Distributed Erlang uses a full mesh, every node connects to every other node. When we got close to 50 nodes the inter-node communication overhead was eating a significant chunk of our CPU. Adding more nodes started giving diminishing returns because the mesh traffic grew faster than the compute we gained. Interesting constraint that I haven't hit in any other runtime since.
Post reply on HN