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

61–70 of 151 posts

Re: Ruby vs. Crystal Performance

#61

Post by nine_k »

nickbauman wrote: post #30
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…

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

If it has reasonable incremental compilation, it can take a few seconds to compile.

With good code structure, I see large Java projects compile small changes in seconds, even though compiling Java used to be a hog. You don't often rebuild from scratch during development, do you?

Re: Ruby vs. Crystal Performance

#62

Post by joelbluminator »

gavinray wrote: post #45
ngngngng wrote: post #41

Earlier quoted context omitted.

That's good to keep in mind, I strictly write code in vim but if I have to pick up ruby again I'll give those IDEs a shot. I really like the sales pitch of rails, but as someone that almost exclusively writes in modern, compiled languages, it's really tough to adjust to ruby and be productive with it.

I wrote Rails professionally for a few years back when that was THE de-facto tech for greenfield projects and new startups. At the time, I really enjoyed it, but I'd never written a modern-feeling typed/gradually typed language yet (C#, which I found really verbose and ugly, a lot of pre-ES6 JS and Ruby, some Lua + Python). I would never voluntarily write it again. Ruby/Rails completely falls apart in larger projects…

Sorbet ? So you can't write maintainable dynamic code without basically making it static is what you're saying.

Re: Ruby vs. Crystal Performance

#63

Post by hosh »

eggsnbacon1 wrote: post #49
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!…

Metaprogramming doesn't need to have a performance impact. VM languages like Java, C#, and JS allow you do define and modify code at runtime JS you can redefine anything, Java support is pretty good, C# better support is coming with generators

Ruby's "metaprogramming" is something Java, C# and JS don't do well -- dynamically redefining things during runtime. Everything in Ruby, including literals and operators, can be redefined during runtime, because everything is an object, and every message passed to any object can be redirected, filtered, transformed ad hoc. It's not just classes can be modified. Specific objects can be modified. Well-crafted Ruby code breaks things up into mixins that can be composed together. The closest comparison is one of Ruby's inspiration -- Smalltalk.

I think the most exciting optimization people have seen with Ruby is Truffle.

I don't regret the 14 years I put into writing Ruby professionally. I've used and abused metaprogramming, and it has shaped how I reason and architect things. I learned to appreciate well-designed, semantically-meaningful DSL. But I've moved on. I write server code with Elixir these days, and I'm exploring other ways of reasoning and writing code.

Re: Ruby vs. Crystal Performance

#64

Post by norswap »

nine_k wrote: post #57
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!…

Ruby has to have runtime metaprogramming because it has no other time but run time. Compile-time metaprogramming is way safer and more performant, but for it you need a compiler.

But Crystal doesn't have those either.

Re: Ruby vs. Crystal Performance

#65

Post by hosh »

eggsnbacon1 wrote: post #60
YorickPeterse wrote: post #51

Earlier quoted context omitted.

Ruby's meta-programming capabilities is why optimising Ruby is so darn difficult. It's extremely powerful, but also complicates a lot of things.

I reason the difference is mostly when metaprogramming can happen. In Java, redefining or adding code is very explicit, it can't just happen whenever. Same with C#. And there are lots of rules. A class can't modify itself, and there's limits to what changes you can make. And to make changes you must have control over the "classloader" that loaded that code. JS on the other hand can do most of what ruby does, to my kn…

However, JS does not treat everything as an object as pervasively as Ruby does. A JS object and a JS integer are two different abstract data types. A Ruby number literal "1" is treated as an object of the Integer class. There are no separate abstract data type other than an object. All operators for an Integer can be overriden (in runtime), or perhaps, a specific object's methods can be overridden. Now granted, the runtime cheats and implements certain things in C ... but those can be overriden during runtime ...

If you want to find out more about the limits of what can be done to optimize Ruby, check out the Truffle project. That came out of someone's PhD dissertation on novel methods for doing JIT optimization for Ruby. It is sufficiently difficult and novel to warrant awarding a PhD for. Last time I heard, Truffle still could not run Rails.

Re: Ruby vs. Crystal Performance

#66

Post by strken »

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…

To dig into method_missing a bit more: when you call a non-existent ruby method on any object it has to check for and run a method called method_missing, which can contain arbitrarily complex code, on the object itself as well as every class in the inheritance hierarchy. Because ruby is a dynamic language with dynamic dispatch, you can't easily precompute the results of doing this.

Re: Ruby vs. Crystal Performance

#67

Post by hamandcheese »

norswap wrote: post #64
nine_k wrote: post #57

Earlier quoted context omitted.

Ruby has to have runtime metaprogramming because it has no other time but run time. Compile-time metaprogramming is way safer and more performant, but for it you need a compiler.

But Crystal doesn't have those either.

Yes it does? https://crystal-lang.org/reference/syntax_and_semantics/macr...

Re: Ruby vs. Crystal Performance

#70

Post by coder543 »

ukd1 wrote: post #31

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

I find this perspective kind of funny, because every medium-sized Ruby project I've worked on takes 10+ seconds just to load and start rspec (before it runs any of my tests) or a REPL.

Because of this, working with Ruby is actually substantially slower than working with a similarly sized Go project, in my experience, even though Go theoretically has the disadvantage of needing to compile things before running them.

Plus, Go's type system will catch tons of bugs that Ruby optimistically treats as "maybe you meant to do this". Obviously Rust's type system is really awesome, but Go's is still really helpful, while compiling much faster than Rust.

Since Rust and Crystal are both LLVM-based, I would guess that Crystal's compile times also tend to be a bit painful on medium-sized projects, like Rust, but I've never actually used Crystal for anything more than "Hello, World".

(I've been paid to work full time with Ruby, Rust, and Go over the years, and they each have pros and cons, but I just don't think I would ever personally choose Ruby for any new project in 2020, if I had a say in it, given how great Go is for web development.)

Post reply on HN