Hacker News Reader

Hacker News

Comment by matthewrudy | Hacker News Reader

Full thread

matthewrudy

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 string literals.

View on HN

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.

There isn't really anyway to monkeypatch `try` to use the operator. `try` API is inherently based on metaprogramming (passing a symbol to call), and have different semantics than the operator (by default it won't throw if a non-existent method is called in a non-nil object, while the operator will thrown a NoMethodError)

https://github.com/rails/rails/blob/4-2-stable/activesupport...

`try` is pretty prevalent in rails dev from what I've seen in the field.

`try` is different from `try!`. the new lonely operator is like `try!`, which asks only if the object is nil and then calls the method on it if it's not (and will blow up if the object doesn't have the method publically defined). `try`, in contrast, asks if the object is nil or responds to the method and returns nil if it doesn't.

`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.

Keep in mind string literal freezing is still off by default.

I like that they did it this way, give a chance to see if it actually brings performance improvements in real world scenarios before imposing it on all code.

I've turned it on for all of my projects.

But I think the real benefits will always be in framework code.

Reply on news.ycombinator.com