Live data from Hacker News

Returning to Rails in 2026

markround.com

221–230 of 254 posts

Re: Returning to Rails in 2026

#221
post #220

Earlier quoted context omitted.

the problem is that nobody listened to Alan Kay and writes dynamic code the way they'd write static code but without the types. I always liked Rich Hickey's point, that you should program on the inside the way you program on the outside. Over the wire you don't rely on types and make sure the entire internet is in type check harmony, it's on you to verify what you get, and that was what Alan Kay thought objects shoul…

That's a terrible solution because then you need a bunch of extra parsing and validation code in every recipient object. This becomes impractical once the code base grows to a certain size and ultimately defeats any possible benefit that might have initially been gained with dynamic typing.

>then you need a bunch of extra parsing and validation code in every recipient object.

that's not a big deal, when we exchange generic information across networks we parse information all the time, in most use cases that's not an expensive operation. The gain is that this results in proper encapsulation, because the flipside of imposing meaning globally is that your entire codebase is one entangled ball, and as you scale a complex system, that tends to cost you more and more.

In the case of the OP where a program "breaks" and has to be recompiled every time some signature propagates through the entire system that is significant cost. Again if you think of a large scale computer network as an analog to a program, what costs more, parsing an input or rebooting and editing the entire system every time we add a field somewhere to a data structure, most consumers of that data don't care about?

this is how we got micro-services, which are nothing else but ways to introduce late binding and dynamism into static environments.

Re: Returning to Rails in 2026

#222
post #220

Earlier quoted context omitted.

That's a terrible solution because then you need a bunch of extra parsing and validation code in every recipient object. This becomes impractical once the code base grows to a certain size and ultimately defeats any possible benefit that might have initially been gained with dynamic typing.

>then you need a bunch of extra parsing and validation code in every recipient object. that's not a big deal, when we exchange generic information across networks we parse information all the time, in most use cases that's not an expensive operation. The gain is that this results in proper encapsulation, because the flipside of imposing meaning globally is that your entire codebase is one entangled ball, and as you s…

> when we exchange generic information across networks we parse information all the time

The goal is to do this parsing exactly once, at the system boundary, and thereafter keep the already-parsed data in a box that has "This has already been parsed and we know it's correct" written on the outside, so that nothing internal needs to worry about that again. And the absolute best kind of box is a type, because it's pretty easy to enforce that the parser function is the only piece of code in the entire system that can create a value of that type, and as soon as you do this, that entire class of problems goes away.

This idea is of using types whose instances can only be created by parser functions is known as Parse, Don't Validate, and while it's possible and useful to apply the general idea in a dynamically typed language, you only get the "We know at compile time that this problem cannot exist" guarantee if you use types.

Re: Returning to Rails in 2026

#223

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…

It's not just the untyped problems, the runtime definitions of functions, properties, etc make it nearly impossible to debug unless you have the state of your production data locally. (Or you ssh into your prod server and open up a REPL, load the state and introspect everything there). Good luck debugging locally in a nice IDE. It's a horrific nightmare. I use to love Ruby until I had to debug it live.

Yeah, dynamic typing is one thing, but the magical dynamic imports into the processes globally scoped namespace add another level to debugging difficulty.

At least in Python (as a comparison example), imports are only available in the module doing the importing - it's more explicit. You'd have to really work to get the same "everything all at once" as Rails has.

Re: Returning to Rails in 2026

#224

Earlier quoted context omitted.

What is it about large untyped codebases that make it a nightmare?

Anything can return anything and you only realize it at runtime is a massive headache. When you can't keep the entire code base in your head it becomes a liability. I never used Ruby, but Python code bases love mixing in strings that are actually enums and overloading functions that accept all kinds of types. You just had to hope that the documentation was correct to avoid a crash. Java 1.7 to Python feels very freei…

When CI/CD becomes your compiler you are in a tough spot

Re: Returning to Rails in 2026

#225

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…

Also the language/framework is mattering less by the day with agentic coding.

Why would anyone ever choose ruby, python, etc when you don’t need to write it?

These languages are undoubtedly dead as of now. Python may live on in ML for a bit but probably not much longer

Re: Returning to Rails in 2026

#226

Earlier quoted context omitted.

>then you need a bunch of extra parsing and validation code in every recipient object. that's not a big deal, when we exchange generic information across networks we parse information all the time, in most use cases that's not an expensive operation. The gain is that this results in proper encapsulation, because the flipside of imposing meaning globally is that your entire codebase is one entangled ball, and as you s…

> when we exchange generic information across networks we parse information all the time The goal is to do this parsing exactly once, at the system boundary, and thereafter keep the already-parsed data in a box that has "This has already been parsed and we know it's correct" written on the outside, so that nothing internal needs to worry about that again. And the absolute best kind of box is a type , because it's pre…

> 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 are still parsing many times when you look at the entire program as a whole. "Parse, don't validate" doesn't really change anything.

Re: Returning to Rails in 2026

#227

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…

Also the language/framework is mattering less by the day with agentic coding. Why would anyone ever choose ruby, python, etc when you don’t need to write it? These languages are undoubtedly dead as of now. Python may live on in ML for a bit but probably not much longer

Ruby has "undoubtedly" been dead for at least a decade now, or so I've heard. Glad to hear Python is undoubtedly joining the party.

Re: Returning to Rails in 2026

#228

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…

Rust/Loco is unironically the most interesting framework right now. Loco follows up the Rails formula pretty closely, and makes easier to learn Rust by taking care of a load of boilerplate code.

I'm at a point now where I'm not even a little interested in new frameworks. I want tried and tested. Preferably something that has been around for 15 years.

Re: Returning to Rails in 2026

#229

Earlier quoted context omitted.

Also the language/framework is mattering less by the day with agentic coding. Why would anyone ever choose ruby, python, etc when you don’t need to write it? These languages are undoubtedly dead as of now. Python may live on in ML for a bit but probably not much longer

Ruby has "undoubtedly" been dead for at least a decade now, or so I've heard. Glad to hear Python is undoubtedly joining the party.

Least informed comment Ive read here

Re: Returning to Rails in 2026

#230
post #226

Earlier quoted context omitted.

> when we exchange generic information across networks we parse information all the time The goal is to do this parsing exactly once, at the system boundary, and thereafter keep the already-parsed data in a box that has "This has already been parsed and we know it's correct" written on the outside, so that nothing internal needs to worry about that again. And the absolute best kind of box is a type , because it's pre…

> 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 a way to hack Kay's actor model onto languages that don't offer the dynamicism natively

I think microservices emerged for a different reason: to make more efficient use of hardware at scale. (A monolith that does everything is in every way easier to work with.) One downside of microservices is the much-increased system boundary size they imply -- this hole in the type system forces a lot more parsing and makes it harder to reason about the effects of local changes.

Post reply on HN