#cruby — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #cruby, aggregated by home.social.
-
🚀 Another thrilling episode of "Why Memory Management Will Save Humanity" presented by CRuby's *finest* minds. 🎓 Spoiler: it involves a PDF that your browser definitely can't handle. And yes, it’s all made possible thanks to a visionary #collaboration with... the Australians? 🌏
https://railsatscale.com/2025-09-16-reworking-memory-management-in-cruby/ #MemoryManagement #CRuby #Technology #Innovation #Australia #HackerNews #ngated -
Reworking Memory Management in CRuby [pdf]
https://blog.peterzhu.ca/assets/ismm_2025.pdf
#HackerNews #Reworking #Memory #Management #in #CRuby #pdf #Ruby #MemoryManagement #CRuby #ProgrammingTechniques #SoftwareDevelopment
-
[Перевод] Ускоряем Ruby, переписав C… на Ruby
В последнее время я часто видел обсуждения репозитория сравнения языков . В нём CRuby был третьим снизу, обгоняя по скорости только R и Python. Автор репозитория @BenjDicken создал забавную визуализацию производительности каждого из языков. В одной из визуализаций из визуализаций Ruby по бенчмаркам Ruby оказывается третьим с конца.
-
I'm currently trying to get #RubyLang 3.3.1 to compile with `--enable-yjit` set. For some reason, the newest #CRuby version won't build on Sonoma because #RustLang is missing some include or header required for the latest #YJIT to be built.
It seems to be a problem with #rustc. I'm trying with #rustup instead, and will see how that goes.
-
Ah, nothing like posting on #StackOverflow to toughen up one's sense of self! I typically only answer the tricky questions there, so dealing with criticism of minor oversights, off-by-ones, and conversion errors are part of the fun. Ever try converting µs to femtoseconds when #benchmarking iterations on large data sets? Less fun than you think!
On the other hand, #TruffleRuby for the performance win. 900% faster for this use case than #CRuby, even with #YJIT.
-
@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.