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

Ruby vs. Crystal Performance

ptimofeev.com

Post reply on HN
Print view View original

21–30 of 151 posts

Re: Ruby vs. Crystal Performance

#21

Post by chrisseaton »

Crystal and Ruby do not even remotely have the same semantics. They look similar but the similarity is extremely superficial. The extra semantics that Ruby has have a massive impact on performance, for even the most optimising implementations. This is not a reasonable comparison if you do not consider the 'slick as Ruby' part. No runtime metaprogramming! The entire Ruby ecosystem is built on runtime metaprogramming!

(Crystal is a fine language and compiler - but it's nothing to do with Ruby.)

Re: Ruby vs. Crystal Performance

#22

Post by ngngngng »

Trasmatta wrote: post #9
jimbob45 wrote: post #8

What’s the elevator pitch on Crystal? Seems like typed Ruby with performance considerations.

Exactly, it's basically statically typed, compiled Ruby with really good performance. Also it has really powerful type inference, which allows you to write really Ruby-like code while maintaining your static typing. The downside of that is that it makes the compiler kind of slow.

Does go-to definition work in crystal? That was always my least favorite thing about ruby, I find it very awkward to write code without being able to jump to definitions.

Re: Ruby vs. Crystal Performance

#23

Post by deedubaya »

I really like Crystal and have had good success using it for web stuffs. I still reach for ruby first, because the dev feedback loop is a lot faster and the ecosystem is more vibrant.

The biggest gain I've found in using Crystal vs Ruby is reduced memory usage.

Most often my code isn't slow because of the language, but the data access behind it, so counting CPU cycles is less of a priority for me.

Re: Ruby vs. Crystal Performance

#24

Post by [deleted] »

WJW wrote: post #16
ksec wrote: post #10

Earlier quoted context omitted.

Or something like Sidekiq in Crystal [1], which was 7 times faster. But now I wonder how much faster would Sidekiq run on TuffleRuby. [1] https://github.com/mperham/sidekiq.cr

I'd be amazed if TruffleRuby could beat Crystal, given the problems most JITs have had with Ruby. By restricting the extreme dynamism of Ruby a bit, Crystal can allow for optimalisations that no Ruby implementation will be able to match. It's just really difficult to properly compile languages where it's possible to dynamically redefine the + operator based on input from HTTP requests. That said, Truffle is looking s…

[deleted]

Re: Ruby vs. Crystal Performance

#25

Post by Trasmatta »

ngngngng wrote: post #22
Trasmatta wrote: post #9

Earlier quoted context omitted.

Exactly, it's basically statically typed, compiled Ruby with really good performance. Also it has really powerful type inference, which allows you to write really Ruby-like code while maintaining your static typing. The downside of that is that it makes the compiler kind of slow.

Does go-to definition work in crystal? That was always my least favorite thing about ruby, I find it very awkward to write code without being able to jump to definitions.

There are go-to definition plugins that work for Ruby, depending on what editor or IDE you're using. They're just not always perfect, because in a non statically typed language, you can't always know what the implementation of a method is.

Last I checked, there wasn't great editor support for Crystal yet, but that might have changed by now.

Re: Ruby vs. Crystal Performance

#26

Post by tomphoolery »

jimbob45 wrote: post #8

What’s the elevator pitch on Crystal? Seems like typed Ruby with performance considerations.

Crystal isn't really "typed Ruby" because that would mean it includes all of the same metaprogramming capabilities that Ruby does. Crystal is a lot more limiting than Ruby in this regard. For example, Crystal doesn't allow you to automatically generate class constants.

I would say the elevator pitch is "A systems programming language with an expressive syntax, similar to Ruby".

Re: Ruby vs. Crystal Performance

#27

Post by watzon »

chrisseaton wrote: post #21

Crystal and Ruby do not even remotely have the same semantics. They look similar but the similarity is extremely superficial. The extra semantics that Ruby has have a massive impact on performance, for even the most optimising implementations. This is not a reasonable comparison if you do not consider the 'slick as Ruby' part. No runtime metaprogramming! The entire Ruby ecosystem is built on runtime metaprogramming!…

Care to explain more? Having been using Ruby for about 8 years and Crystal for about 4, they actually have an extremely similar syntax and are also semantically very close. To the point where many Ruby scripts are completely valid Crystal, or at the very least require only a few changes.

I do think that people trying to compare Crystal to Ruby kind of miss the point though. Ruby as an interpreted language, even optimized with JIT compilation, will never match the performance you can get out of a true compiled language. By the same token, Crystal as a compiled language will never be as quick to develop with since you have to wait for your code to compile after each change.

Re: Ruby vs. Crystal Performance

#28

Post by chrisseaton »

watzon wrote: post #27
chrisseaton wrote: post #21

Crystal and Ruby do not even remotely have the same semantics. They look similar but the similarity is extremely superficial. The extra semantics that Ruby has have a massive impact on performance, for even the most optimising implementations. This is not a reasonable comparison if you do not consider the 'slick as Ruby' part. No runtime metaprogramming! The entire Ruby ecosystem is built on runtime metaprogramming!…

Care to explain more? Having been using Ruby for about 8 years and Crystal for about 4, they actually have an extremely similar syntax and are also semantically very close. To the point where many Ruby scripts are completely valid Crystal, or at the very least require only a few changes. I do think that people trying to compare Crystal to Ruby kind of miss the point though. Ruby as an interpreted language, even optim…

> Care to explain more? Having been using Ruby for about 8 years and Crystal for about 4, they actually have an extremely similar syntax and are also semantically very close. To the point where many Ruby scripts are completely valid Crystal, or at the very least require only a few changes.

It doesn't have Kernel#eval. It doesn't have Kernel#send. It doesn't have Kernel#binding. It doesn't has Proc#binding. It doesn't have Kernel#instance_variable_get/set. It doesn't have Binding#local_variable_get/set. It doesn't have BasicObject#method_missing. It doesn't have BasicObject#instance_eval. I could go on. All these methods have extreme far reaching non-local implications on the semantic model and practical performance, and specifically defeat many conventional optimisations.

> To the point where many Ruby scripts are completely valid Crystal, or at the very least require only a few changes.

You can't even load most of the Ruby standard library without these methods!

And it doesn't matter if you use them or not. They're still there and they impact semantics and performance because the fact that you can use them affects performance. You can't even speculate against most of them as they're so non-local.

Rails and the rest of the mainstream Ruby ecosystem fundamentally depend on them.

> and are also semantically very close

Sorry I super disagree with this. They look similar. Dig into it just below the surface? Start to model it formally? Not at all. Method dispatch, which is everything in Ruby, isn't even close.

(Again, Crystal's great as its own thing, it's just not similar to Ruby's semantics. If you don't need Ruby's semantics or you can replicate them at compile time then maybe it's perfect for you.)

Re: Ruby vs. Crystal Performance

#29

Post by bjoli »

zucker42 wrote: post #5

The recursively written Fibonacci benchmark is terrible for comparing a interpreted language to a compiled language. When compiling with optimizations in C, for example, the compiler significantly transforms the program. [1] It's possible Crystal does too. [1] https://godbolt.org/z/vaESBG

It can be an ok way to measure procedure call overhead though (between languages with similar semantics)

Re: Ruby vs. Crystal Performance

#30

Post by nickbauman »

watzon wrote: post #27
chrisseaton wrote: post #21

Crystal and Ruby do not even remotely have the same semantics. They look similar but the similarity is extremely superficial. The extra semantics that Ruby has have a massive impact on performance, for even the most optimising implementations. This is not a reasonable comparison if you do not consider the 'slick as Ruby' part. No runtime metaprogramming! The entire Ruby ecosystem is built on runtime metaprogramming!…

Care to explain more? Having been using Ruby for about 8 years and Crystal for about 4, they actually have an extremely similar syntax and are also semantically very close. To the point where many Ruby scripts are completely valid Crystal, or at the very least require only a few changes. I do think that people trying to compare Crystal to Ruby kind of miss the point though. Ruby as an interpreted language, even optim…

Yeah how fast is that compiler? If it's just another compiled language (rather than the kind of wicked fast compiled language like Go), my enthusiasm will be dampened...
Post reply on HN