Ruby vs. Crystal Performance • Hacker News Board

Re: Ruby vs. Crystal Performance

#41

Post by ngngngng » Fri, Jun 05, 2020, 8:49 PM UTC

gavinray wrote: post #36

ngngngng wrote: post #22

Earlier quoted context omitted.

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.

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.

Re: Ruby vs. Crystal Performance

#42

Post by brokencode » Fri, Jun 05, 2020, 8:54 PM UTC

kotutku wrote: post #38

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?

Check out Crystal’s official website sometime to learn more about its modern features. Crystal doesn’t have immutability, but does have support for functional programming and union types. “Compile-time guarantees” is such a vaguely specified feature that virtually all programming languages have that, but its type system is actually pretty strong despite how it looks with all the type inference, and even prevents null pointer exceptions unlike a lot of static languages.

It also has a lightweight threading system that makes it work well as a web server. Not quite as elegant as something like Elixir, with its isolated processes, but still nice. It also supports macros, which can make the code a lot more elegant and performant compared to similar languages.

Re: Ruby vs. Crystal Performance

#43

Post by devmunchies » Fri, Jun 05, 2020, 8:54 PM UTC

Neat seeing crystal on here.

I built my startup using crystal and now I write crystal full time.

I’m still only using a single dedicated server with a SQLite database.

Re: Ruby vs. Crystal Performance

#44

Post by ptcodes » Fri, Jun 05, 2020, 9:01 PM UTC

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

The test was against compiled Crystal code:

crystal build program.cr

./program

Re: Ruby vs. Crystal Performance

#45

Post by gavinray » Fri, Jun 05, 2020, 9:07 PM UTC

ngngngng wrote: post #41

gavinray wrote: post #36

Earlier quoted context omitted.

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.

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 if the entire team doesn't stick to best practices + stringent code and doc standards with stuff like YARD or Sorbet. And so many magic, implicit methods injected everywhere.

Super happy writing Typescript and occasional Rust/Go now. I thought Kotlin was pretty nice too, the one small project I had to implement in it.

Re: Ruby vs. Crystal Performance

#46

Post by moonchild » Fri, Jun 05, 2020, 9:07 PM UTC

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 wonder if it would be possible to write in a common subset of ruby and crystal, and use the former for dev and the latter for prod?

Re: Ruby vs. Crystal Performance

#47

Post by ken » Fri, Jun 05, 2020, 9:09 PM UTC

bjoli wrote: post #29

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)

Maybe, but these two languages don't exactly have similar semantics.

You can't make a Ruby program that uses fixnums-only. You also can't make a Crystal program that's dynamic like Ruby. Interestingly, though, when the Crystal implementation is modified to use bignums, the Ruby implementation is over twice as fast while still being dynamic.

What I get from this is that Crystal's static compiler is slower than Ruby's dynamically dispatched interpreter, and Crystal's bignums are so slow you'll need to think hard about whether you want a 50x speed boost or correct arithmetic in all cases.

I think Crystal is a good concept, but it's only version 0.34.0. Every implementation is bad at version <<1.0. Ruby <<1.0 didn't have good performance, either. I'm sure Crystal will be great by the time it gets to 2.6.5, too.

Re: Ruby vs. Crystal Performance

#48

Post by qeternity » Fri, Jun 05, 2020, 9:10 PM UTC

nicoburns wrote: post #35

tmikaeld wrote: post #11

Earlier quoted context omitted.

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.

We recently finished our first node backend (typescript) and I have to say it was an amazing experience. The npm ecosystem definitely attracts its fair share of undesirables, but I struggle to see why JS full stack isn’t the default for 99% of people.

Re: Ruby vs. Crystal Performance

#49

Post by eggsnbacon1 » Fri, Jun 05, 2020, 9:18 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!…

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

Re: Ruby vs. Crystal Performance

#50

Post by rantwasp » Fri, Jun 05, 2020, 9:22 PM UTC

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

you obviously did not do metaprogramming in Ruby. Try it and you will never look at the "metaprogramming" capabilities of other languages in the same way.

no offence to JS, but JS and a proper programming language are not even the same species.