31–40 of 76 posts
That was a fun read. You should do Rails 8.0 on Ruby 1.8 next.
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…
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.
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…
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).
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.
I had the opposite conclusion. This seems like a pretty minimal set of changes to get a 19 year old piece of software running.
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
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, ...}
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.
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.
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…
Not being able to run a 15 year old codebase on a 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…
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.
Earlier quoted context omitted.
Not being able to run a 15 year old codebase on a 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…
> 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…
I've also had various occasions where code compiled successfully but no longer worked as intended.
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).
On the other hand, Amber offers a look of what a Crystal rewrite of Rails would look like