181–190 of 304 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
I’ve been doing Rails development for 10 years now and I just don’t think it’s possible to safely update anything in Ruby. Our app has 20,000 rspec unit tests and 5,000 cypress browser automation tests and basically every ruby patch version creates breakages that somehow slip through all of that despite nothing being mentioned in the changelogs.
What about recording and replaying traffic to the servers? It's not a magical solution, but it should catch regressions.
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.
I've never seen that credibly claimed. Why would their license ban benchmarking if their performance was any good?
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)
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.
Ruby's typing story is still the worse-than-modern-Java boilerplate of writing loads of unit tests just to make sure an object is the type that you think it is.
In Ruby, tests are the same you'd write in any other language. You test that things do what they are supposed to do, not the types of parameters or return values.
Earlier quoted context omitted.
It's not like strong typing came after Ruby. In fact, duck typing was a _feature_ of Ruby on its days. At the end of the day, you choose your battles, it's not a black-or-white decision.
Static typing was a nightmare (by modern standards) in the 1990s. Dynamic scripting languages were such a breath of fresh air that we were willing to pay the steep performance penalties without hardly a thought. Sort of like the saying "deleted code is debugged code", code that you actually write always performs better than the code you didn't write because it was too soul-sucking. But static typing languages, librar…
Earlier 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 ...
I used to have that attitude. Then I wrote my first Ruby project as an experiment. That was 17 years ago, and the majority of the code I've written since has been Ruby. What clinched it was that the first Ruby project I wrote involved trying to reimplement a piece of C code we had. It ended up 10% the size with more functionality, and it took me a tiny fraction of the time to write. If you write code the way you writ…
Earlier 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_.
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
For quite a while it used to have some terrible performance if you ever reached out to C libraries in a hot loop. It's still a bit iffy on the C / FFI front, though the performance issues are much improved
It's certainly good enough for production use, with careful evaluation.
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