[HN Gopher] Ruby 3.3 on Rails 1.0
___________________________________________________________________
Ruby 3.3 on Rails 1.0
Author : thunderbong
Score : 192 points
Date : 2024-01-16 11:48 UTC (11 hours ago)
(HTM) web link (nashby.github.io)
(TXT) w3m dump (nashby.github.io)
| kichik wrote:
| That was a fun read. You should do Rails 8.0 on Ruby 1.8 next.
| latortuga wrote:
| 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.
| Alifatisk wrote:
| There is a polyfill gem that allows older Ruby versions
| access the newer stuff, wouldn't that help?
| lambdaba wrote:
| If the author reads this, I think you shouldn't bind space to the
| side menu, I (hope) many people know you can scroll with space.
| anamexis wrote:
| I don't know if they fixed it really quickly, but space does
| the normal scrolling for me, on Chrome and Safari.
| andrewmutz wrote:
| I dont experience that. Perhaps you pressed tab once beforehand
| to focus the menu?
| lambdaba wrote:
| ah, yes, but since there's no focus indicator it's not
| obvious
| nightpool wrote:
| Looks like it has a focus indicator to me, although I can
| see why it might be confusing: https://imgur.com/a/Mc6A7Dn
| lambdaba wrote:
| Yeah, I guess I pressed tab right away and thought it was
| the design of the button.
|
| I think it's better to keep the focus style as the
| default outline, and uniform.
| alberth wrote:
| Regression testing.
|
| It'd be a nice regression test to have:
|
| - Rails pegged at a particular version number and test the
| runtimes.
|
| - Ruby runtime pegged at a particular version and test Rails
| versions
| semiquaver wrote:
| The rails team already does the latter, subject to their
| specified compatibility matrix. Current rails requires Ruby
| 3.1, so CI only runs on that version and later.
|
| https://buildkite.com/rails/rails/builds/103981
| lloeki wrote:
| Hold my refreshing beverage
|
| https://github.com/lloeki/minimal-rack
|
| {rack 1 2 3, rails 3.2-7.1, sinatra 1 2 3, grape} x {ruby
| 2.1-3.3} x {puma, thin, webrick, ...}
| wavemode wrote:
| 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.
| formerly_proven wrote:
| Ruby is used a lot less so the base population of people able
| to complain is much smaller.
| peteforde wrote:
| 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.
| fny wrote:
| But it was done slowly enough not to piss anyone off.
| tonyedgecombe wrote:
| 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.
| multiplegeorges wrote:
| I had the opposite conclusion.
|
| This seems like a pretty minimal set of changes to get a 19
| year old piece of software running.
| shellac wrote:
| Ditto. Having had to update python code over the years, this
| looked much easier than python migrations. To be honest
| moving earlier python 3.x code to current 3.x is comparable,
| so good job ruby devs.
| byroot wrote:
| Almost all of the issues mentioned in this post were during 1.8
| -> 1.9 transition.
|
| At that time odd release numbers where development versions,
| until this policy changed a bit later and 1.9 became an actual
| "GA" release.
|
| The 1.8 -> 1.9 is really Ruby's "Python 3" moment, as it
| similarly improved String encoding handling, but the breakages
| were much more limited and it also came with pretty significant
| performance improvements, so the community didn't split like
| Python 2 and Python 3.
|
| If you follow Ruby's development, or watch Matz talks, you see
| that avoiding a Python like split is really his number 1
| concern.
| jrochkind1 wrote:
| I agree with your analysis, as a rubyist since ruby 1.8.
|
| > but the breakages were much more limited and it also came
| with pretty significant performance improvements, so the
| community didn't split like Python 2 and Python 3.
|
| I think perhaps the ruby community was also smaller (or at
| least not TOO large), had an average higher level of skill
| (goes with the first, usually), and was fairly committed to
| ruby and/or rails at the time (we loved it, there were few if
| any similar alternatives).
|
| I agree that there hasn't been a similar level of backwards
| breaking since 1.8 => 1.9, and that if there were now it
| would be much more disastrous. Keyword arguments in ruby ~3.0
| come closest, but still were much less disruptive than
| 1.8=>1.9.
|
| I have never been a serious python user, so can't really
| compare to python 2=>3, but my impression is that python 2=>3
| was bigger even than ruby 1.8=>1.9. *BUT* that other typical
| python "minor" releases may actually have fewer backwards
| breaking changes than typical ruby "minor" releases?
| halostatue wrote:
| Ruby has had two major backwards-incompatible change
| inflections: 1.9 and 3.0 (although I think that most of the
| removals were actually in 3.1).
|
| The painful one is 1.8->1.9, because that's where Ruby's string
| grew encoding awareness.
|
| Going from 2.7->3.0 was not nearly as painful (mostly dealing
| with warnings and some code being removed from the standard
| library as gems that people can use if they want).
|
| I still maintain code that is _nominally_ 1.8 compatible and it
| works just fine on 3.2 (I haven 't yet tested on 3.3).
|
| What is surprising about this exercise is how little code
| needed to be changed on code designed for Ruby 1.8 to allow it
| to run on Ruby 3.3. The author doesn't say how long they spent
| on this, but it _looks_ like 3-4 hours for a fairly complex
| piece of infrastructure code.
|
| How much effort would be required to run Django 1.0 on Python
| 3.12? At least this much, I'm sure. I suspect more, but I don't
| know the 2->3 differences well enough to be able to estimate
| that.
| JohnBooty wrote:
| Strongest possible disagree.
|
| There was some pain around Ruby 1.8->1.9 because of string
| encodings, but no huge schism ala Python 2/3.
|
| Did you experience both transitions or is that just your
| feeling based on this article? If anything, I think the article
| proves how relatively painless the transition was.
| bdcravens wrote:
| 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.
| kshahkshah wrote:
| 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
| renewiltord wrote:
| Haha, this is really cool. And if I'm honest, very often it'll be
| a blog post like this that will solve some other issue I'm
| encountering. Thank you!
| W3cUYxYwmXb5c wrote:
| RoR was cool way back when, but these days I'm much happier using
| nodejs with a framework like Adonis
| zilti wrote:
| I don't get people who voluntarily use JS outside a browser.
| I'd rather jump into a pit filled with rusty spikes.
| rfw300 wrote:
| 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.
| peteforde wrote:
| 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!
| tomca32 wrote:
| Ooof...I'm not honestly. I don't do Rails that much these days
| but when I do it's just crazy how productive I can be. I think
| it's still a great fit for a huge number of web applications.
|
| If performance is very important there are better options like
| Rust or Go, but otherwise RoR is my go to. Pretty much
| everything you need is baked into the framework and it's still
| being actively developed. Some of the new stuff is pretty great
| like Turbo frames and streams.
|
| I respect that you enjoy working in Nodejs but Nodejs
| frameworks are just so barebones in my experience. I haven't
| tried Adonis but I still remember when I was looking how to
| parse query params in Koa. The official docs said to use a
| third party lib or regex them yourself from the request
| string...like why would I even use a framework at that point?
| cortesoft wrote:
| I remember starting on Rails 0.8, where migrations were just sql
| files you ran
| sidkshatriya wrote:
| 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 fixed.
|
| Take any decent statically typed language. When a new version of
| the language comes out, your code will not compile on constructs
| or functions that are no longer called or present or used the way
| they should.
| ahoka wrote:
| Java is "statically typed" amd has the same issues during
| runtime with different JVM versions.
| harikb wrote:
| People try to run JVM versions across 10 years and face
| "small" issues with builtins. GP's point was mainly about
| missing interfaces, missing methods, typos etc.
| sidkshatriya wrote:
| > People try to run JVM versions across 10 years and face
| "small" issues with builtins. GP's point was mainly about
| missing interfaces, missing methods, typos etc.
|
| Indeed -- well put.
|
| > Java is "statically typed" amd has the same issues during
| runtime with different JVM versions.
|
| Nothing is ever perfect -- there can be some occational
| runtime incompatibilities when very old Java code is run on
| new VMs.
|
| But the effort in moving between one Java version and
| another Java version that came out many years later is
| likely order of magnitudes less than if you did the same
| thing in Ruby. There is simply no comparison.
| Berone wrote:
| 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.
| Lio wrote:
| 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.
| apiguy wrote:
| Not being able to run a 15 year old codebase on a < 1 month old
| runtime without making some modifications has nothing to do
| with static or dynamically typed languages.
|
| But first - why don't we point out that the bulk of the issues
| the author faced had nothing at all to do with types? The
| issues were primarily with syntax changes.
|
| Regardless - with a statically typed, _compiled_ language, you
| find these issues at compile time. With any other language you
| find them at runtime. Either way, you 'd have to fix a whole
| lot before you deploy the code, and just because you prefer to
| find your exceptions at compile time doesn't mean that it's the
| _best_ way to find them.
| sidkshatriya wrote:
| > 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 latent in your codebase for many more weeks and months.
| Only if a rare condition triggers a code path that contains
| the incompatibility. This is also why refactors in languages
| like Ruby are more difficult and conservative. As you're
| never sure you fixed everything.
| Contortion wrote:
| 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.
| sidkshatriya wrote:
| 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.
| jshen wrote:
| 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.
| sidkshatriya wrote:
| What are the costs of a Ruby incompatibility just waiting
| to be discovered in production ? You can't assume you
| wrote tests to exercise every possible branch in every
| method in every object ?
|
| The costs of static typing are reasonable as long as
| you're not using a fancy dependently typed language. Ask
| companies that are maintaining long running software --
| types help. The investment is there in the beginning, the
| payoff is over the lifetime of the project.
|
| If types are complex and poorly defined, you can change
| them ! The compiler will help you evolve your system
| through type errors. If you have a poorly structured
| program in a dynamically type language like Ruby then it
| becomes more difficult to evolve your system fast and
| with confidence. You're always asking -- have I missed
| something out ?
| jshen wrote:
| I've been writing software for a long time in many
| different types of languages. I've led many software
| teams for a long time that use different languages and
| tech stacks. I have not seen any measurable difference in
| productivity or defect rate across different languages. I
| have also looked at all of the research on this and it is
| inconclusive at best.
|
| Ultimately, I think that choice of language is one of the
| least significant predictors of outcomes, yet it's one of
| the most debated and obsessed over.
|
| Edit: I thought it would be helpful to give examples of
| what I think is more important. Good CI/CD practives,
| good observability, robust test and staging environments,
| etc have been far more important in my experience than
| static vs dynamic language choice.
| rapind wrote:
| I've been using rails for well over a decade (since version 2),
| and loving it. For the most part upgrades have been relatively
| painless by choosing to always lag a little behind on non-
| security related upgrades.
|
| There have been times though when upgrades have been extremely
| painful. The massive shift between versions 2 and 3 (merb
| integration), the openssl shenanigans (ruby v2 -> v3), and the
| mimemagic / shared-mime-info licensing issues are the major
| ones that come to mind.
|
| That being said, I use Elm on the front end a lot and the
| confidence it gives me about my code is like night and day
| compared to ruby (or javascript).
| wavemode wrote:
| This is a great example of the difference between theory and
| practice.
|
| In theory, you're correct and type errors could be hiding out
| in a dynamically-typed codebase after a language version
| upgrade, lying in wait to take your system down.
|
| In practice, nothing like what you're describing has ever
| happened to me when working in large (1M+ LOC) Ruby and Python
| codebases.
|
| In my experience the difference maker is testing, not type
| checking. I've worked in poorly tested Java codebases where
| upgrading a dependency still allowed the application to compile
| and deploy successfully, but then at runtime things started
| blowing up randomly. Meanwhile with well-tested dynamically-
| typed code I've never had any such issues.
| TheSmoke wrote:
| sure, take some scala 2 library and make it work with scala 3 /
| dotty with an effort similar to this one. or java 1.8 and 17.
| we'll wait.
| dchuk wrote:
| 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).
| helen___keller wrote:
| My understanding is that this tends to be difficult because
| certain really-dynamic-stuff that Ruby offers (effectively
| metaprogramming) are not supported by Crystal, but are heavily
| used by Rails.
|
| On the other hand, Amber offers a look of what a Crystal
| rewrite of Rails would look like
| yxhuvud wrote:
| 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.
| jrochkind1 wrote:
| I mean, by making some changes to Rails source code, it was
| possible to get a simple "hello world" to display.
|
| Presumably you'd run into more bugs if you tried to do more
| than that.
|
| Rails does have a test suite (hopefully Rails 1.0 had a decent
| one?) , I guess the interesting experiment would be how much
| code do you have to change to get Rails 1.0 test suite to pass
| on ruby 3.3.
|
| Safe to say quite a bit more than for the hello world to run!
| e12e wrote:
| > it was possible to get a simple "hello world" to display.
|
| That's not really the whole story. It was possible to
| generate a hello world web application server.
|
| Would've been interesting to see if other generators,
| generated migrations, models, controllers, views and tests
| worked (scaffolding blog posts and comments).
| ryanbigg wrote:
| This is pretty incredible work!
|
| (Action web service was an attempt to make Rails generate SOAP
| APIs as that was the style du jour at the time. Fortunately, JSON
| came along!)
| Rodeoclash wrote:
| Oof, anybody else get a wave of nostalgia seeing that start page!
___________________________________________________________________
(page generated 2024-01-16 23:01 UTC)