Live data from Hacker News

Ruby 2.3.0 Released

ruby-lang.org

31–40 of 73 posts

Re: Ruby 2.3.0 Released

#31
post #25

Earlier quoted context omitted.

Why? Genuinely curious.

'try' is relatively slow compared to other control logic, as allowing an exception to be thrown involves constructing an exception stack trace. This is slow in all VMs I know. Theoretically you could detect that the trace isn't used and remove it through escape analysis, but this is not easy, or you could do some crazy thing with lazily creating the stack trace, but that's a research project.

I think you are confused, `try` is not raise/rescue. The ActiveSupport `try` implementation does not involve allowing an exception to be raised.

https://github.com/rails/rails/blob/v4.2.5/activesupport/lib...

It should be as performant as other ways of checking for nil/empty.

Re: Ruby 2.3.0 Released

#32

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.

Re: Ruby 2.3.0 Released

#33
post #17

with the existence of Perl6, Clojure, F#, Rust, Go, and few others ... For someone who doesn’t know Ruby, why learn it today?

if everything came down to just what you type in the editor (e.g. functionally equivalent programs in any language performed the same everywhere), i would always prefer ruby.

it's just a nicer language to use than most, or maybe all others.

Re: Ruby 2.3.0 Released

#35

Earlier quoted context omitted.

'try' is relatively slow compared to other control logic, as allowing an exception to be thrown involves constructing an exception stack trace. This is slow in all VMs I know. Theoretically you could detect that the trace isn't used and remove it through escape analysis, but this is not easy, or you could do some crazy thing with lazily creating the stack trace, but that's a research project.

I think you are confused, `try` is not raise/rescue. The ActiveSupport `try` implementation does not involve allowing an exception to be raised. https://github.com/rails/rails/blob/v4.2.5/activesupport/lib... It should be as performant as other ways of checking for nil/empty.

Ah yes you're right - I was confusing this with raise/rescue.

Re: Ruby 2.3.0 Released

#36
Looks like some nice additions. I try to limit the use of .try in rails, however when working with legacy codebases it is much nicer then:

if @user && @user.address && @user.address.city city = @user.address.city end

Even though I write less Ruby then I once did, I still credit it as the language which shaped my career the most. I have worked so many great jobs because of Ruby.

Re: Ruby 2.3.0 Released

#37
post #32

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.

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

Re: Ruby 2.3.0 Released

#38
post #20

Anyone knows if Ruby has accepted IBM's contribution of JIT for Cruby?? https://news.ycombinator.com/item?id=10715610 And below is the Presentation from Ko1 on compiling Ruby http://rubykaigi.org/2015/presentations/ko1

(IBMer working on said JIT here)

As Chris Seaton points out as well, we're not really open source yet. Working on getting there, but it's going to take time. The important thing now is that we can start talking with the community and making it more likely that when we do get open source, it can happen in a way consumable by the Ruby community.

Re: Ruby 2.3.0 Released

#39
post #17

with the existence of Perl6, Clojure, F#, Rust, Go, and few others ... For someone who doesn’t know Ruby, why learn it today?

It's got an elegant syntax, great for meta-programming (tends to be useful in large and/or complex applications), strong community (there are gems for almost everything, i.e. no need to reinvent the wheel over and over again).

It's used by some interesting applications, such as Github, Shopify, Heroku, Square, Zendesk and AirBnB.

Re: Ruby 2.3.0 Released

#40
post #17

with the existence of Perl6, Clojure, F#, Rust, Go, and few others ... For someone who doesn’t know Ruby, why learn it today?

For me: because nothing else approaches it in terms of linguistic flexibility. I learned Ruby about two years ago, after learning...a dozen-ish languages? Something like that. I don't write web applications in it, because Rails grinds my gears for a whole host of reasons, but for my money it is the can-opener language. If I have a problem, I feel like I can generally explore it faster in Ruby (holla, Pry) and build a solution iteratively without really burning a lot of mental effort on it.

The second part, aside from Ruby's general applicability and ease of exploration, is that I think Ruby scales, in terms of application design, from that garbage-y first-cut code to really elegant, really clean code that's fun to work in and easy to maintain. That first solution, borne mostly out of dumping my REPL history, may not be great, but that's okay: with the help of the excellent ecosystem around the language I can reify my expectations in tests and swap out the original exploratory system for good, easy-to-work-with code that's clear in its behaviors. Of course you can do that with other languages, too--but I've never found one that makes it as easy to stretch in both directions, from noodling around to code I'd trust with my business (and I'm doing exactly that), other than Ruby.

But as for the languages you namedropped:

- Perl 6 is great, but it's a decade late and it isn't sufficiently compatible with Perl 5, so it's starting miles and miles behind where Ruby is right now. It's not dead out of the gate, but it keeps lurching toward the green and making everybody nervous. Practically nobody knows Perl 6 now, I don't know why somebody would pick it over Ruby if they're lining both languages up side by side.

- Clojure is super interesting and Rich Hickey is a supergenius and we're all lucky he didn't go into supervillaining because I think he'd be really good at it. And Leiningen is an amazing build system. But Clojure suffers from what I view are the usual problems a Lisp has around readability and the hands-on-keyboard experience (and I like Lisp, I've got DrRacket installed on my laptop for a reason, but I've been writing Lisps for a decade or more now and grinding out Clojure code is slow). Love the people, love the community...would rather write Ruby.

- Rust doesn't do nearly the same thing as Ruby. They're useful for different things. I feel like Rust inherited the good parts of the Ruby ethos from the participation of folks like Steve Klabnik. Big fan of the language and the community, but it's not incompatible with Ruby where it matters anyway so who cares?

- F# is a great language and, like Rust, also has little overlap with what I use Ruby for. If I cared about Ruby for the web, maybe there would be more overlap, but F#-for-web is swimming upstream anyway. (Doable, but harder than C#.)

- Go, while it as a language deserves some small credit for introducing co-routines to people who come from Python (he said, only somewhat snarking while he makes Lua gang signs), is close to an unmitigated disaster of an ecosystem that tries to be prescriptive when it should be hands-off and hands-off when it should be prescriptive. It is also a tremendously limited language in terms of syntactic flexibility and ability to do stuff like "second-order" metaprogramming; this is a design decision that can be debated, or could be debated if I hadn't been convinced long ago by better languages that crippling a programmer to make writing an execution environment easier to always be the wrong thing. Do not want.

Post reply on HN