191–200 of 304 posts
Earlier quoted context omitted.
What about recording and replaying traffic to the servers? It's not a magical solution, but it should catch regressions.
Replicating the production env to do that sounds beyond our capabilities tbh. We are slowly replacing Ruby with typed languages like TS and Rust which is working wonders for reliability.
Earlier quoted context omitted.
Even if GvR promotes it fully, it won't be adopted unless c extensions work out of the box. Python without its crazy amount of extensions in c-api won't survive.
This is something that's up to the community really. The PyPy developers early on made a new FFI that is also available for CPython, sadly not entirely as easy as the classic API but completely functional and if there was a push to rewrite extensions to use that FFI (or provide dual-paths) then the gap could be bridged.
I do hope it takes off.
It's been a sec since I've used Ruby. How's the typing story? Seems like Sorbet is doing quite well, but are there comprehensive typings for the ecosystem, like TypeScript? Because with ergonomic, comprehensive type checking and a JIT, Ruby might be a tempting option again.
The problem, I think, is the restrictions that not having a compilation step places on what typing you can do without a big breaking change. Typescript didn't have this problem because everyone already used bundlers/minifiers/etc. Adding another compiler like step to that process was pretty natural. Ruby doesn't have that and adding it in poses problems for REPL development. They chose to go with a separate file for…
Sorbet also provides a gradual typing system where you can start adding types to a large code base and gradually make the checking more strict. Stripe claims to be using it on a huge ruby code base and that their developers generally like it.
However I think many devs don't want static types on Ruby. We like our duck typing!
I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?
Tragically, one of the principals behind TruffleRuby (and researcher at Shopify) was Chris Eaton and he passed away a few months ago. I'm not sure where this leaves TruffleRuby itself, or plans to implement it at Shopify. (Rest in peace, Chris, and may your memory be a blessing to those who knew you)
I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?
Source: I work in a team that's nearby as the org chart flies.
Earlier 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.
Earlier quoted context omitted.
I don't quite understand the YJIT excitement. A few benchmarks show that TruffleRuby generally beats YJIT, sometimes by a 10x margin. [0]: https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj... says
And by many accounts Oracle makes the fastest database yet everyone still uses Postgres. Also our experience with truffleruby is death by a thousand subtle differences. It might be 97% compatible but chasing down that 3% undocumented behavior difference on every minor version update for every gem got exhausting fast. Everyone uses and tests against cruby.
It's been a sec since I've used Ruby. How's the typing story? Seems like Sorbet is doing quite well, but are there comprehensive typings for the ecosystem, like TypeScript? Because with ergonomic, comprehensive type checking and a JIT, Ruby might be a tempting option again.
Python have a 99% compatible jit implementation called PyPy and nobody much know about it. It was production ready since 5 years ago but ignored by mainstream. It is 400% faster than vanilla python on average and Guido and MS is working on for a few percent gain instead of promoting it or eventually making it default. PyPy.org
I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?