Live data from Hacker News

Ruby 3.3 on Rails 1.0

nashby.github.io

71–76 of 76 posts

Re: Ruby 3.3 on Rails 1.0

#71

I remember starting on Rails 0.8, where migrations were just sql files you ran

Didn't most people use ant to deploy back then? I think it was a Java build tool or something? I feel like I should know this better - the maintainer of ant was actually working for us at the time, deploying early Rails apps using ant. I just remember deciding right then and there that I very much preferred writing code over troubleshooting deploys (and what we now call "devops").

Re: Ruby 3.3 on Rails 1.0

#72

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.

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.

I agree with your strong disagree.

I know, and help maintain, Ruby code written for 1.8 that hasn't been touched and is running fine in 3.2. No breakage along the way.

To be fair, that's not always possible, but Ruby's changes haven't ever been drastic.

I've not had as much experience with Python as a programmer - more as a user of apps written in Python, and I sense there's a bigger issue there than Ruby has ever had. It seems like a frequent problem that something that works in Python 3 doesn't work with Python 2 and vice versa.

Re: Ruby 3.3 on Rails 1.0

#73
post #63

Earlier 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…

> I haven't seriously used Python in a long time, but from occasionally glancing at release notes, they seem to regularly deprecate things.

The meaning of deprecation changed a bit. Before 3.6 or so things were deprecated, but just left in and maybe eventually removed when they broke for good, which would rarely happen. Nowadays deprecation means it will actually be removed after two releases (years), and a lot of stuff was deprecated basically just because it was old. I don't think that's an amazing signal to send, honestly.

Re: Ruby 3.3 on Rails 1.0

#74

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 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 maint…

This so much. In the first part my my work carrier I was fixing old PHP applications, nobody ever bothered to even mention software updates.

The next part, in a ruby shop, was different. We would update all the software all the time, usually pretty painless or with one or two expected issues that are easily fixed.

There was no point when it turned to old, every app was running the most recent rails and usually ruby just days after the release

Re: Ruby 3.3 on Rails 1.0

#75

I remember starting on Rails 0.8, where migrations were just sql files you ran

Didn't most people use ant to deploy back then? I think it was a Java build tool or something? I feel like I should know this better - the maintainer of ant was actually working for us at the time, deploying early Rails apps using ant. I just remember deciding right then and there that I very much preferred writing code over troubleshooting deploys (and what we now call "devops").

I don't know about ant... we were using Capistrano back then.

Re: Ruby 3.3 on Rails 1.0

#76

Earlier quoted context omitted.

Didn't most people use ant to deploy back then? I think it was a Java build tool or something? I feel like I should know this better - the maintainer of ant was actually working for us at the time, deploying early Rails apps using ant. I just remember deciding right then and there that I very much preferred writing code over troubleshooting deploys (and what we now call "devops").

I don't know about ant... we were using Capistrano back then.

I do recall when capistrano became a thing (it was called switch tower but had to change for trademark reasons if I recall). Prior to that, most folks working with Rails in production were using ant. I wouldn't be surprised if there were other ways as well back then, given it was early days.
Post reply on HN