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

Ruby 3.3 on Rails 1.0

nashby.github.io

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Ruby 3.3 on Rails 1.0

#41

Post by yxhuvud »

dchuk wrote: post #38

This is awesome to see that it's possible. I've always wondered about the same sort of concept, but instead it would be trying to use Crystal to run the latest Rails version. I lack the time/energy/knowledge to try it, but it would be interesting to see how close you could get to either power or port Rails to Crystal, and if it would even be worth it (in terms of speed and type safety, etc).

Well, you'd have to move a whole lot of code generation from load time to compile time, including the stuff based on db layout. So quite a bit of work.

Re: Ruby 3.3 on Rails 1.0

#42

Post by sidkshatriya »

Contortion wrote: post #39
sidkshatriya wrote: post #37

Earlier quoted context omitted.

> just because you prefer to find your exceptions at compile time doesn't mean that it's the best way to find them. It is indeed the best way to find them. At compile time, you get errors for all possible paths a program will take. For dynamic languages like Ruby you will get an error only if the program takes a path through problematic code and then Ruby will flag the error. This means a runtime error could lie late…

This seems like a semi-moot point considering that after you've updated something you (presumably) also run an automated test suite and (have someone) test the application manually. I've also had various occasions where code compiled successfully but no longer worked as intended.

The automated test suite can check many code paths but compilation of a statically typed language checks all possible code paths.

Put another way, automated test suites give you an extremely high level of assurance when using a statically typed language. When your test suite passes in the new version Ruby, you're happy but there still could be cases left that you've not dealt with in rarely triggered code paths/conditions.

Re: Ruby 3.3 on Rails 1.0

#43

Post by Lio »

Berone wrote: post #30
sidkshatriya wrote: post #22

This whole blog post is essentially an advertisment for why statically typed languages can prevent such madness. I'm sorry -- it is not my intention to start another non-useful static/dynamic typing debate. It seems crazy that when a new version of Ruby comes out, developers need to hunt for runtime errors (that may or may not trigger depending on the path the application took) to see what incompatibility needs to be…

Heavy Ruby/Rails user here. We basically run type checking on major hand-offs between modules using DrySchema/DryValidation, a gem that makes it easy to set that up. Without doing this, the integrity of the codebase erodes with scale.

I'm not sure I'd recommend DrySchema or DryValidation.

I've had real problems upgrading client's projects built using DryValidation prior to v1 in the past.

They changed the syntax of the validations just enough to break stuff and completely removed features like shared predicates. The upgrade process was very poorly documented with suggestions to go read random blog posts.

I think the replacement for shared predicates was supported be macros but even that is marked as likely to be removed in v2.

Just looking through some of the Dry changelogs the work BREAKING still features far more than I'm happy with. I'd be much happier to use Sorbet or an RBS based typing solution than work with Dry again.

It might have advantages over ActiveModel but ActiveModel is far better supported.

Re: Ruby 3.3 on Rails 1.0

#44

Post by bdcravens »

wavemode wrote: post #10

As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.

From an outsider's perspective (I've written a little Python, but not enough that I consider myself a Pythonista) I didn't think it was backward incompatibility that was the problem as much as community libraries and frameworks not moving forward to v3 for a long time.

Re: Ruby 3.3 on Rails 1.0

#45

Post by peteforde »

formerly_proven wrote: post #12
wavemode wrote: post #10

As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.

Ruby is used a lot less so the base population of people able to complain is much smaller.

It's used less but those who use it mysteriously make a lot more money.

I know which group I'm happy to be a part of.

Re: Ruby 3.3 on Rails 1.0

#46

Post by jshen »

sidkshatriya wrote: post #42
Contortion wrote: post #39

Earlier quoted context omitted.

This seems like a semi-moot point considering that after you've updated something you (presumably) also run an automated test suite and (have someone) test the application manually. I've also had various occasions where code compiled successfully but no longer worked as intended.

The automated test suite can check many code paths but compilation of a statically typed language checks all possible code paths. Put another way, automated test suites give you an extremely high level of assurance when using a statically typed language. When your test suite passes in the new version Ruby, you're happy but there still could be cases left that you've not dealt with in rarely triggered code paths/condi…

The problem with this argument is that you never mention the costs or trade-offs of a statically typed language. You presume that you get the benefits for free and I'm certain that is not the case. The worst systems I've ever worked on were ones with complex and poor types and type hierarchies.

Re: Ruby 3.3 on Rails 1.0

#47

Post by peteforde »

rfw300 wrote: post #28
zilti wrote: post #24

Earlier quoted context omitted.

I don't get people who voluntarily use JS outside a browser. I'd rather jump into a pit filled with rusty spikes.

That’s fair, but TypeScript coupled with modern JS dev tooling makes it actually a pretty palatable experience these days. Speaking as someone who used to want to jump into pits for JavaScript-related reasons.

Isn't that the difference, though? People who legitimately love Rails because of how productive they are, versus "pretty palatable".

It's wild how people insist on using less-good tooling because that's what they've heard they are supposed to do... and that that's as good as they are going to get.

It's not!

Re: Ruby 3.3 on Rails 1.0

#48

Post by tonyedgecombe »

fny wrote: post #13
wavemode wrote: post #10

As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.

But it was done slowly enough not to piss anyone off.

The transition to Python 3 took a very long time. I often wonder if they would have saved themselves a ton of grief if they had done it quicker.

Re: Ruby 3.3 on Rails 1.0

#49

Post by Alifatisk »

latortuga wrote: post #31
kichik wrote: post #2

That was a fun read. You should do Rails 8.0 on Ruby 1.8 next.

In theory this is a funny idea but I think it would be a huge waste of time. Ruby syntax has changed and added so much since since 1.8 that you'd be stuck fixing thousands of syntax errors.

There is a polyfill gem that allows older Ruby versions access the newer stuff, wouldn’t that help?

Re: Ruby 3.3 on Rails 1.0

#50

Post by kshahkshah »

wavemode wrote: post #10

As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.

Hard disagree. For a moment there it wasn't clear if there was going to be a hard Python 2 vs 3 fork and people would literally refuse to migrate to 3. There was never such a moment in Ruby. The migrations from version to version were relatively smooth except 1.8.6 to 1.9 MRI -> YARV
Post reply on HN