Oof, anybody else get a wave of nostalgia seeing that start page!
Yeap straight back to late 2007 when I first created a rails project in prep for my first job out of Uni.
Ruby 3.3 on Rails 1.0
61–70 of 76 posts
Re: Ruby 3.3 on Rails 1.0
#62Earlier quoted context omitted.
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…
> 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).
True; the generator for a "hello world" works to generate a "hello world" app that works!
It's definitely way less than full support for a real Rails app though!
Re: Ruby 3.3 on Rails 1.0
#63Earlier quoted context omitted.
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 imp…
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…
> I think perhaps the ruby community was also smaller
Back in 2008-2010 when Python 3 was released, Python really wasn't as huge as it is today. It probably was bigger than Ruby, but not by that much.
One datapoint (that doesn't give the full picture), Pycon 2008 had 1k attendees [0], Railsconf 1k8 [1].
IMO It's really in the early/mid 2010's with the rise of "big data" that the Python community really became huge compared to Ruby's.
> I have never been a serious python user, so can't really compare
As an ex-pythonista, now Rubyist, IMO one huge factor was that Python 2 and 3 were developed concurrently for several years, that played in the messaging. Python 3.0 was released on 2008, Python 2.7 in 2010, and Python 3 wasn't really deemed production ready until 3.2 or 3.3 if I remember correctly. So there was a 4-5 years limbo. Whereas in Ruby's case, it was very clear to the community that 1.9.x was the future.
Also Python 3 did make some absolutely necessary breaking changes (like unicode), but also some minor syntax changes that made it much harder to support both with a single codebase for questionable gains.
e.g. the `try/except`syntax was `except Class, var:` in 2.x, and `except Class as var:` in 3.x. That kind of changes made it hard for packages maintainers to support both versions. Ruby 1.9 didn't have this problem. It was much easier if not trivial to write code that worked on both Ruby 1.8 and 1.9.
> typical python "minor" releases may actually have fewer backwards breaking changes than typical ruby "minor" releases?
I haven't seriously used Python in a long time, but from occasionally glancing at release notes, they seem to regularly deprecate things. Can't say if more or less than Ruby.
[0] https://pycon.blogspot.com/2008/04/part-2-attendance-registr... [1] https://www.endpointdev.com/blog/2008/06/railsconf-2008-repo...
Re: Ruby 3.3 on Rails 1.0
#64Earlier quoted context omitted.
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?
Polyfill libraries can provide methods that were added in newer versions of the language (e.g. to std lib classes), but they can't provide the new syntax that has been added.
Ruby has had a lot of syntax changes over the years that are incompatible with an older interpreter. An easy example is the 1.9 shorthand hash syntax for symbol keys `{ name: "pants" }` instead of the hashrocket syntax `{ :name => "pants" }`. More recent examples would be keyword args or pattern matching.
Re: Ruby 3.3 on Rails 1.0
#65RoR was cool way back when, but these days I'm much happier using nodejs with a framework like Adonis
I'm actually really excited about the direction Rails is going in. It's like it's shedding some of the complexity that was accumulated over the years in favor of things I can finally understand again.
Re: Ruby 3.3 on Rails 1.0
#66Earlier quoted context omitted.
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 imp…
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…
Well, the most vocal ruby community was RoR users, while python even back then was used by multiple camps.
Ruby done a smart upgrade path - new features in 2.x and breaking changes in 1.9.x. Ruby also got a "new" VM (it wasn't new, but it was the new default VM).
Before 1.9.3 the best way to deploy ruby was Passenger with RubyEE. RubyEE was based on 1.8.7 and with all the improvements that the mainline ruby implementation got there was no reason to maintain RubyEE fork. The 2.0.0 release meant to be 100% compatible with 1.9.3 and had ABI version 1.9.1.
Also, prior 2.1.0 Ruby used versioning very different from SemVer, hence 1.9.x had multiple breaking changes in its lifetime. It didn't mean "patch" version back then.
I think the main difference is that the newer ruby was actually faster than the older ruby and gave plenty of reasons to move. The main pain point im ruby migration was that it became encoding aware. Python 3 wasn't as lucky.
Re: Ruby 3.3 on Rails 1.0
#67Earlier quoted context omitted.
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.
That's not what they meant. Ruby made breaking change by breaking change, and it was still easy to have gems work with both ABI versions. Python 3 had changes that made it necessary challenging to support both, all while being slower (IIRC).
Re: Ruby 3.3 on Rails 1.0
#68This 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).
I've done that with Liquid (https://github.com/wmoxam/liquid-crystal), and it's roughly 2X faster than Ruby 3.2 w/yjit
Re: Ruby 3.3 on Rails 1.0
#69This 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).
I've done that with Liquid ( https://github.com/wmoxam/liquid-crystal ), and it's roughly 2X faster than Ruby 3.2 w/yjit
Admit it, you just did it because the name is perfect.
Re: Ruby 3.3 on Rails 1.0
#70Earlier quoted context omitted.
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…
> I think perhaps the ruby community was also smaller Back in 2008-2010 when Python 3 was released, Python really wasn't as huge as it is today. It probably was bigger than Ruby, but not by that much. One datapoint (that doesn't give the full picture), Pycon 2008 had 1k attendees [0], Railsconf 1k8 [1]. IMO It's really in the early/mid 2010's with the rise of "big data" that the Python community really became huge co…
> Ruby 1.9 didn't have this problem. It was much easier if not trivial to write code that worked on both Ruby 1.8 and 1.9.
Oh yeah, that is hugely important, and I agree ruby does this; it's usually not hard to write code that will work on at least the last handful of ruby releases.
The keyword arg changes initially made this difficult in one particular case -- and this was seen as a problem, so they introduced the `ruby2_keywords :method_name` thing, to make it possible with an opt-in to make sure you had identical behavior in all versions, before the ruby version was released that would have made it impossible.