Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Ruby to Crystal: A Quick Look

spin.atomicobject.com

Post reply on HN
Print view View original

11–20 of 44 posts

Re: From Ruby to Crystal: A Quick Look

#11

Post by shawn42 »

prh8 wrote: post #10
deedubaya wrote: post #4

Crystal could be a really powerful tool for enhancing existing Ruby code. Imagine a world where you write your code in Ruby, but farm out the expensive operations to a Ruby-like Crystal extension (similar to what is commonly done with C or Rust). I think this is possible already (just after a quick Google search[1]), just not friendly for the average Ruby dev to implement. [1] https://www.slideshare.net/AnnaKazakova/…

This is definitely possible-- I've done even more than basic PoC (Anna's slide deck was one of my starting points in fact). https://github.com/phoffer/crystalized_ruby

Sweet. I'm glad to see progress on this already.

Re: From Ruby to Crystal: A Quick Look

#12

Post by RX14 »

vidarh wrote: post #9
ajamesm wrote: post #6

70x faster? If Crystal gets its own port of Ruby on Rails, oh boy.

70x faster, with the caveat that the way that Ruby code is written really does not lend itself to speed. E.g. using method calls inside the class instead of accessing instance variables instantly springs to mind, as does the "unsorted priority queue" which is basically a horrible abuse of Array but wrapped in a class that makes it even slower by adding additional method calls for every operation. That's not to dimini…

Crystal does the same as ruby for instance variable access, it's just that such methods are such an easy target for inlining by LLVM there's practically no performance penalty. The flexibility of gets and sets simply being method calls is very awesome and very worth it.

Re: From Ruby to Crystal: A Quick Look

#14

Post by vidarh »

mnarayan01 wrote: post #7

My biggest takeaway from reading this is that Crystal is much more divergent from Ruby than I expected.

I'm confused by why there's so many small things that appears to be pointless differences. E.g. "property" vs "atter_accessor". It'd seem that ease of converting Ruby code is the major selling point, and especially with things like TruffleRuby + Substrate, it seems like it's about to face more serious competition that doesn't depend on rewriting your code nearly as much.

Re: From Ruby to Crystal: A Quick Look

#15

Post by shawn42 »

vidarh wrote: post #9
ajamesm wrote: post #6

70x faster? If Crystal gets its own port of Ruby on Rails, oh boy.

70x faster, with the caveat that the way that Ruby code is written really does not lend itself to speed. E.g. using method calls inside the class instead of accessing instance variables instantly springs to mind, as does the "unsorted priority queue" which is basically a horrible abuse of Array but wrapped in a class that makes it even slower by adding additional method calls for every operation. That's not to dimini…

Author of the article here. This implementation of A* was me playing around. It is definitely not optimized for either Ruby or Crystal It was merely a chunk of Ruby code that I had lying around. You are right about the unsorted queue being a hack around Array, but it was part of another experiment of using a "Fast Stack"[1] for the A* algorithm. It allowed me to swap in other Queue implementations easily.

The point of the article was merely "How much work does it take to port Ruby to Crystal" The performance differences were just fun to see, not the intent.

If I get time, maybe I'll run this through jRuby+Truffle as a comparison, that would be interesting to see.

[1] https://github.com/SteveRabin/JPSPlusWithGoalBounding

Re: From Ruby to Crystal: A Quick Look

#16

Post by vidarh »

ricardobeat wrote: post #13
mnarayan01 wrote: post #7

My biggest takeaway from reading this is that Crystal is much more divergent from Ruby than I expected.

In fact being similar to or compatible with Ruby is not a language goal at all.

That's communicated very poorly, when the first thing on the website is "fast as C, slick as Ruby" followed by mentioning how similar the syntax is to Ruby.

Re: From Ruby to Crystal: A Quick Look

#17

Post by kavok »

ricardobeat wrote: post #13
mnarayan01 wrote: post #7

My biggest takeaway from reading this is that Crystal is much more divergent from Ruby than I expected.

In fact being similar to or compatible with Ruby is not a language goal at all.

If the goal is not to be similar to Ruby then what makes Crystal better than Rust or Go? I can understand being compatible ith not being a specific goal.

Re: From Ruby to Crystal: A Quick Look

#18

Post by vidarh »

RX14 wrote: post #12
vidarh wrote: post #9

Earlier quoted context omitted.

70x faster, with the caveat that the way that Ruby code is written really does not lend itself to speed. E.g. using method calls inside the class instead of accessing instance variables instantly springs to mind, as does the "unsorted priority queue" which is basically a horrible abuse of Array but wrapped in a class that makes it even slower by adding additional method calls for every operation. That's not to dimini…

Crystal does the same as ruby for instance variable access, it's just that such methods are such an easy target for inlining by LLVM there's practically no performance penalty. The flexibility of gets and sets simply being method calls is very awesome and very worth it.

It sounds like more substantial semantic differences then, as in the Ruby case the challenge with making it fast is that you can't take shortcuts like that without first verifying that there are no possible calls to any code that can have side effects like making changes to the receiver - you need to be prepared to "deoptimize" the code back to doing full method calls at any point, as in the general case you have no guarantee that the code will remain a simple getter/setter.

Re: From Ruby to Crystal: A Quick Look

#19

Post by prh8 »

vidarh wrote: post #14
mnarayan01 wrote: post #7

My biggest takeaway from reading this is that Crystal is much more divergent from Ruby than I expected.

I'm confused by why there's so many small things that appears to be pointless differences. E.g. "property" vs "atter_accessor". It'd seem that ease of converting Ruby code is the major selling point, and especially with things like TruffleRuby + Substrate, it seems like it's about to face more serious competition that doesn't depend on rewriting your code nearly as much.

A lot of the differences are based around choosing what is optimal, instead of what is similar to Ruby. Without context, I'd prefer `property` over `attr_accessor`.

As for the effect on porting code, it's still very easy to port code. I ported over ActiveSupport's Inflector module(s), and approximately 75% of the code was untouched, 20% was minor tweaks (i.e. single to double quotes), and 5% required actual changing. It was a rather quick process.

If curious, https://github.com/phoffer/inflector.cr

Re: From Ruby to Crystal: A Quick Look

#20

Post by RX14 »

vidarh wrote: post #14
mnarayan01 wrote: post #7

My biggest takeaway from reading this is that Crystal is much more divergent from Ruby than I expected.

I'm confused by why there's so many small things that appears to be pointless differences. E.g. "property" vs "atter_accessor". It'd seem that ease of converting Ruby code is the major selling point, and especially with things like TruffleRuby + Substrate, it seems like it's about to face more serious competition that doesn't depend on rewriting your code nearly as much.

The idea behind crystal is not to make a faster ruby, but to make a rethought ruby for the modern age: compiled, statically typed and removed of warts.

Crystal should feel familiar to ruby developers in it's syntax and stdlib, but we have absolutely no problems with throwing away ruby's ideas when they are deemed substandard.

Crystal doesn't aim to draw in as many ruby developers as possible, it aims to create the best programming language possible. It just happens to have ruby as a conceptual starting point.

Post reply on HN