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!)
Ruby 3.3 on Rails 1.0
51–60 of 76 posts
Re: Ruby 3.3 on Rails 1.0
#52Oof, anybody else get a wave of nostalgia seeing that start page!
Re: Ruby 3.3 on Rails 1.0
#53Earlier quoted context omitted.
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.
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 ?
Re: Ruby 3.3 on Rails 1.0
#54This 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…
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.
Re: Ruby 3.3 on Rails 1.0
#55This 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 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!
Re: Ruby 3.3 on Rails 1.0
#56As much as people complain about Python, Ruby really went through just as much (if not more) churn over the years from backwards-incompatible changes.
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 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?
Re: Ruby 3.3 on Rails 1.0
#57Earlier quoted context omitted.
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.
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 payo…
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.
Re: Ruby 3.3 on Rails 1.0
#58This 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…
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.
Re: Ruby 3.3 on Rails 1.0
#59This 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 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).
Re: Ruby 3.3 on Rails 1.0
#60I remember starting on Rails 0.8, where migrations were just sql files you ran
Where we're going, we don't need any rollbacks!