Ruby vs. Crystal Performance • Hacker News Board

Re: Ruby vs. Crystal Performance

#31

Post by ukd1 » Fri, Jun 05, 2020, 8:23 PM UTC

A massive point for me missing in this article is the experience of having to wait for Crystal to compile - especially for development, this sucks. Try timing puts "Hello, world" on both:

  ~ % cat test.rb 
  puts "Hello, world"
  ~ % time ruby test.rb
  ruby test.rb  0.03s user 0.05s system 25% cpu 0.312 total
  ~ % time crystal run test.rb
  Hello, world
  crystal run test.rb  1.48s user 1.09s system 72% cpu 3.559 total

Re: Ruby vs. Crystal Performance

#32

Post by dwheeler » Fri, Jun 05, 2020, 8:24 PM UTC

chrisseaton wrote: post #28

watzon wrote: post #27

Earlier quoted context omitted.

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…

Agreed. Crystal looks like it has many positive characteristics, but having similar syntax has nothing to do with having similar semantics. Without constructs like missing_method, you cannot run practically any of the Ruby ecosystem libraries, including everything involving Rails.

Java and C also share a similar syntax, but that does not make that you can easily swap one for the other.

Re: Ruby vs. Crystal Performance

#33

Post by bovermyer » Fri, Jun 05, 2020, 8:28 PM UTC

Coming at Crystal from a Go and PHP development background, here are my thoughts:

- The syntax is lovely. No, really.

- I hate waiting for it to compile, especially compared to Go's compile time.

- It's really young yet, and the ecosystem is just getting started.

Re: Ruby vs. Crystal Performance

#34

Post by G4BB3R » Fri, Jun 05, 2020, 8:32 PM UTC

I really liked Crystal some years ago, even used in a prototype. Soon I realized that despite its cute syntax and good performance, coming from Elm, I would prefer a simpler language with type safety, good error messages and very fast compile time. Maybe in the next years I'll experiment again, especially due to Lucky web framework.

Re: Ruby vs. Crystal Performance

#35

Post by nicoburns » Fri, Jun 05, 2020, 8:33 PM UTC

tmikaeld wrote: post #11

mauricio wrote: post #6

Here are thorough benchmarks of Crystal and C up against other interpreted languages: https://github.com/kostya/jit-benchmarks . It has other examples besides Fibonacci.

I'm quite surprised to see Javascript / Node so high up the ranks, quite impressive the amount of optimizations that's been done to the engine throughout the years.

Yeah, a lot of people don't realise that JavaScript performance is closer to Java than Python, even though the semantics are much closer to Python.

Re: Ruby vs. Crystal Performance

#36

Post by gavinray » Fri, Jun 05, 2020, 8:38 PM UTC

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.

This is the reason why I have to keep IntelliJ Idea Ultimate/RubyMine laying around.

I don't have the greatest laptop, and run a lot of containers, so Jetbrains IDE's are generally a no-go for me and I stick to VS Code, but trying to develop Ruby/Rails without a Jetbrains IDE Is crippling.

I think ctrl+click definition jump does work in Crystal and it has a decent language server.

Re: Ruby vs. Crystal Performance

#37

Post by choxi » Fri, Jun 05, 2020, 8:40 PM UTC

If `brew install crystal` is taking more than an hour to complete, in my case it was because llvm is a dependency and for some reason it was trying to compile it from source. If you manually install a precompiled llvm (you can do `brew install llvm` with some flags) it should skip that step during the crystal installation.

Re: Ruby vs. Crystal Performance

#38

Post by kotutku » Fri, Jun 05, 2020, 8:44 PM UTC

I would like Crystal to include some modern features instead just being a fast and nice language. How about stuff like: immutability, good functional programming support, complex union types, compile-time guarantees?

Re: Ruby vs. Crystal Performance

#39

Post by choxi » Fri, Jun 05, 2020, 8:47 PM UTC

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!…

It has macros at least: https://crystal-lang.org/reference/syntax_and_semantics/macr...

Re: Ruby vs. Crystal Performance

#40

Post by kipply » Fri, Jun 05, 2020, 8:48 PM UTC

I think language-to-language comparisons are often "unfair". Comparing Ruby and Crystal is probably not much better than comparing Ruby to C. Syntax is not an absolute signal for language similarity, and the most important parts of Ruby (in my opinion) more or less require it to be interpreted and not compiled. One can always make languages look the same (which Facebook did with OCaml JS transpiler) without the languages being similar by other measures.

tl;dr "yes, that one is faster and looks similar to the other one so our developers will be less scared and this is good" is important and valid but "that one is just the fast language but slower" is not a valid comparison, which I'm kind of getting.