Ruby 2.3.0 Released • Hacker News Board

Re: Ruby 2.3.0 Released

#71

Post by matthewrudy » Sun, Dec 27, 2015, 5:40 PM UTC

anonova wrote: post #32

matthewrudy wrote: post #7

This is actually a really great release. `&.` removes the really annoying (and slow) `try`. And I think the string literals freezing is going to solve a lot of problems with memory allocations. Check out this PR for Rails that covered a lot of similar performance problems created by too many string allocations. https://github.com/rails/rails/pull/21057/files I wish Rails 5 could go all in on Ruby 2.3.0 and frozen str…

How prevalent is `try` in rails/activesupport? My benchmarks show that the lonely operator is ~2x faster than `try`. I'd expect someone to create a gem that monkey patches `try` for those running 2.3.0.

`try` is bad for a number of reasons.

Because itll never throw an error, you see it hiding issues.

And I keep seeing colleagues writing `hash.try(:[], :some_key)`

`try!` is better.

But I'll stick to `&.` from now on.

Re: Ruby 2.3.0 Released

#72

Post by MrBra » Tue, Dec 29, 2015, 2:34 AM UTC

omarforgotpwd wrote: post #14

Ah, YARV finally adds bytecode compilation and loading as an "experimental" feature. It'll be interesting to see what people do with it.

As someone else pointed out, at https://bugs.ruby-lang.org/issues/11788 they explain that:

They are not goals of this project:

- packing scripts to one package

- migrate obfuscate binary to other node to hide source code

---

But.. what I don't get is: why wouldn't this works as a cheap way to obfuscate some ruby code?

After all, isn't it true that when a script is compiled to byte-code then it is interpreted by the runtime as-is (and without being re-translated to the original script in memory or on disk) ?

If so - I understand that rebuilding the original ruby script would not be a big deal for a developer - but wouldn't this still pose a small barrier to the casual prying user?

Re: Ruby 2.3.0 Released

#73

Post by kelseydh » Wed, Jan 06, 2016, 2:49 PM UTC

matthewrudy wrote: post #71

anonova wrote: post #32

Earlier quoted context omitted.

How prevalent is `try` in rails/activesupport? My benchmarks show that the lonely operator is ~2x faster than `try`. I'd expect someone to create a gem that monkey patches `try` for those running 2.3.0.

`try` is bad for a number of reasons. Because itll never throw an error, you see it hiding issues. And I keep seeing colleagues writing `hash.try(:[], :some_key)` `try!` is better. But I'll stick to `&.` from now on.

Using `try` is definitely a code smell, but unfortunately it's often a necessary one in production environments that have seen some wear and tear in the integrity of their database structures.