I'm still a shameless ruby fanboy at heart. To be fair, its almost all devops type tasks but there is something about that language that just clicks with me, and while I def have to use python more than ruby, I still love ruby.
Ruby 3.2’s YJIT is Production-Ready
61–70 of 304 posts
Re: Ruby 3.2’s YJIT is Production-Ready
#62Earlier quoted context omitted.
The main issue I have with Ruby / Python is the fact that it's duck typed, it makes the maintenance and refactor pretty hazardous. You get objects you don't know what's in there, 6 month later someone changed it, no compile error but it will break when you run it. And so to overcome those major issues they added really ugly stuff that is not core to the language, linters, annotations etc ...
The solution is to be religious about testing and writing tests. If you've done it well, refactors are pretty safe and your objects are pretty well understood.
The point is that compilation automates all this. It's just one more failure point you have to devote man hours to.
Re: Ruby 3.2’s YJIT is Production-Ready
#63I'm wondering about what impact would this have in Basecamp's hosting bills...
If you look at the breakdown per service, EC2 (assuming mostly Ruby) seem to be at best 20% of the bill: https://twitter.com/dhh/status/1613508201953038337 So if you are to make Ruby ~10% faster, you might reduce Basecamp hosting bill by 2% at best.
Thanks for spotting that, I had missed it! This goes to show (again) that the "Ruby/Rails does not scale" myth is fictional.
Re: Ruby 3.2’s YJIT is Production-Ready
#64Earlier quoted context omitted.
The solution is to be religious about testing and writing tests. If you've done it well, refactors are pretty safe and your objects are pretty well understood.
The point is that compilation automates all this. It's just one more failure point you have to devote man hours to.
Compilation won't tell you whether your code follows the business logic it's intended to do. You do need to rely on tests even if the implementation of the programming language compiles it or not.
Re: Ruby 3.2’s YJIT is Production-Ready
#65Earlier quoted context omitted.
The solution is to be religious about testing and writing tests. If you've done it well, refactors are pretty safe and your objects are pretty well understood.
Also, you need to be religious about testing and writing tests _anyway_.
As someone who spent a good chunk of their career teaching TDD, I agree and disagree. Yes, tests are crucial. However, which tests to write varies among other things by language. When I write Ruby, I benefit from testing even the simplest things. When I write Rust or even Type Script or Swift I'll focus much more on tests for complex logic and on integration and acceptance tests. Static typing eliminates an entire, larger category of issue I need to address with tests.
Re: Ruby 3.2’s YJIT is Production-Ready
#66Earlier quoted context omitted.
Also, you need to be religious about testing and writing tests _anyway_.
As someone who spent a good chunk of their career teaching TDD, I agree and disagree. Yes, tests are crucial. However, which tests to write varies among other things by language. When I write Ruby, I benefit from testing even the simplest things. When I write Rust or even Type Script or Swift I'll focus much more on tests for complex logic and on integration and acceptance tests. Static typing eliminates an entire, l…
Sure! But you need to be a testing practitioner anyway. I agree that perhaps the number of tests is different, but the teams processes and cultures should already be there.
But to counter myself, the perceived lack of developer speed and flexiblity of a strongly typed language (with Rust, I always get the feeling that I'm fighting with the compiler!) is also solved in the long run with practice and tooling.
Re: Ruby 3.2’s YJIT is Production-Ready
#67Does this work put Ruby into a faster category than Python until if/when Python gets a JIT in its official implementation?
If you believe the language benchmark game, Ruby is faster than Python on many of the microbenchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... And the benchmark game is using Ruby 3.1, whereas 3.2 is significantly faster. YMMV though, it is going to depend on your use case, but we are always working on making Ruby faster, and if you run into a use case where Python is a lot faster, you can pin…
Python 3.11 also claims [1] to be 10-60% faster than 3.10, which is the version that the benchmarks game is using at this time. The difference in used RSS is also quite interesting in this comparison.
[1]: https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-faster-cpythonRe: Ruby 3.2’s YJIT is Production-Ready
#68Earlier quoted context omitted.
Someone has to do this work, and I this is a good example of a company giving back to what was originally a non-industry project (Ruby).
Yes, I'm just asking whether that needs to be Shopify? And whether their time is best spent elsewhere.
Creating and sharing powerful tools for people to build the things that they want to exist is kinda in Shopify's DNA.
It's also important to me to give back to open source. It's done so much for us.
Re: Ruby 3.2’s YJIT is Production-Ready
#69Re: Ruby 3.2’s YJIT is Production-Ready
#70Is there a name for this syndrome? The same thing happened at Github. Ruby and Rails are slow enough in production that they dedicate a specialized, long-running internal team to it. This team doesn't contribute directly to the product. They hire core Ruby and Rails maintainers, also not to contribute to the product, just to try to help improve their slow software. It's a dream job that shouldn't exist.
If you tell me that Ruby and Rails scaled for Github and Shopify, be careful using that as an argument for choosing Rails for your company. Rails definitely didn't scale for Github, and doesn't appear like it scaled for Shopify, until a manager greenlit a year long JIT project unrelated to Shopify. If your company has as many resources, free cash, klout to hire core Ruby maintainers, and enough downtime you can throw a few engineers at a non-product problem for a few years, then sure, go ahead and use that reasoning.