@ruby_discussions As much as I dislike promoting anything #Java or Oracle related, I have to say that a lot of my #RubyLang code (so long as it doesn't require forking) runs ~1 gazillion times faster on #TruffleRuby than #CRuby even with #YJIT enabled. It's now my default for certain types of performance-oriented code, especially for threading.

If you're trying to update the #OpenSSL gem on #macOS for #TruffleRuby, you may need this to link with OpenSSLv3's #libssl library:

```bash
OPENSSL_PREFIX="$(brew --prefix openssl@3)" gem update openssl
```

Just replace "@3" with "@1.1" if you prefer OpenSSLv1.1 for whatever reason. Meanwhile, #CRuby still doesn't compile against v3 for me, but YMMV.

@rahoulb Without disagreeing with your points, I'd say that #RubyOnRails itself isn't _necessarily_ the problem. As an opinionated system, Rails can certainly drive some unfortunate design choices, but _any_ codebase can become unmanageable at scale.

Just a few ideas:

1. #REST has limitations, but #GraphQL might help.
2. Speed has a lot of factors. #CRuby is not a speed demon. If your code is thread-safe, try TruffleRuby instead.
3. Pre-rendering assets & fragment caching help too.

YMMV.