Ruby 3.3 on Rails 1.0
21–30 of 76 posts
Re: Ruby 3.3 on Rails 1.0
#22It 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.
Re: Ruby 3.3 on Rails 1.0
#23This 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…
Re: Ruby 3.3 on Rails 1.0
#24RoR was cool way back when, but these days I'm much happier using nodejs with a framework like Adonis
Re: Ruby 3.3 on Rails 1.0
#25RoR was cool way back when, but these days I'm much happier using nodejs with a framework like Adonis
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?
Re: Ruby 3.3 on Rails 1.0
#26This 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…
Re: Ruby 3.3 on Rails 1.0
#27This 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…
Java is “statically typed” amd has the same issues during runtime with different JVM versions.
Re: Ruby 3.3 on Rails 1.0
#28RoR was cool way back when, but these days I'm much happier using nodejs with a framework like Adonis
I don't get people who voluntarily use JS outside a browser. I'd rather jump into a pit filled with rusty spikes.
Re: Ruby 3.3 on Rails 1.0
#29Earlier quoted context omitted.
Java is “statically typed” amd has the same issues during runtime with different JVM versions.
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.
Re: Ruby 3.3 on Rails 1.0
#30This 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…
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.