Live data from Hacker News

Ruby vs. Crystal Performance

ptimofeev.com

111–120 of 151 posts

Re: Ruby vs. Crystal Performance

#111
post #83

Earlier quoted context omitted.

To be fair, method_missing has caused more nightmares and problems with debugging than probably any other feature in Ruby. I actively avoid using it, and even the Rails team has massively dialed back on its use in their libraries over the years...

I find this quite amusing because method_missing? has always been the difference between 'true' OO languages Smalltalk/Ruby and pseudo-OO language like C++; with the implication that true OO is better than pseudo OO for the ones making such distinction..

FWIW, Crystal does have compile-time method_missing. Which obviously is less powerful than the runtime variant, but it is still possible to get fairly far in many practical usages.

Re: Ruby vs. Crystal Performance

#112
post #106

Earlier quoted context omitted.

I agree that the comparison is unfair - but I think the larger point is that there are many simple bits of Ruby that can copy/paste to Crystal with an immediate performance boost. In fact, it'd be interesting to slowly re-write a Ruby codebase into Crystal. Of course, harder than it sounds, lots of specifics to figure out.

You are absolutely right. I have written Scheme interpreters in both languages. Compare https://github.com/nukata/little-scheme-in-ruby/blob/v0.3.0/... # Cons cell class Cell include Enumerable attr_reader :car attr_accessor :cdr def initialize(car, cdr) @car = car @cdr = cdr end # Yield car, cadr, caddr and so on, à la for-each in Scheme. def each j = self begin yield j.car j = j.cdr end while Cell === j j.nil? or r…

Thank you for the relevant example!

Re: Ruby vs. Crystal Performance

#113

Earlier quoted context omitted.

>> 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. I think you're missing the point. If 90% of Ruby code works in Crystal unmodified (even if it's because the standard library had to be rewritten from scratch), then the programmer experience may well be quite similar, regardless of how fundamentally…

> If 90% of Ruby code works in Crystal unmodified False, premise, since it's not the case at first place. 90% of your Ruby code will absolutely not work in Crystal unmodified.

That was an example, I was trying to offer chrisseaton a different notion of "similarity".

Another example: if 0% of Ruby code works in Crystal unmodified, but for 90% of code the transformation was extremely simple and mechanical like using curly braces {...} instead of begin...end and prepending $ to all variable names like Bash and PHP, they would still feel extremely similar in practice, albeit obviously less similar than the above example.

By contrast, Java and JavaScript are widely described as having very similar syntax, but it is rare to translate code from one to the other without require fundamental rethinking, because the relationship between JS objects, functions, and prototypes is so different from between Java objects, methods, and classes.

Re: Ruby vs. Crystal Performance

#114
post #98
post #61

Earlier quoted context omitted.

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?

I often switch between feature branches, when working on more than one project in a repo with multiple related modules. If there's a change near the top of that dependency graph, I'm forced to not exactly rebuild from scratch, but still to rebuild quite a lot.

Right now I'm at the very same situation. Yes, it is frustrating. This is why things close to the top of the dependency graph should be small, well-tested, and rarely need changes. But when you still need to troubleshoot them, there's no way around recompiling a lot of stuff if you want these static guarantees :(

Re: Ruby vs. Crystal Performance

#115

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.

The macros are really cool, too.

https://github.com/luckyframework/lucky/blob/master/src/luck...

Re: Ruby vs. Crystal Performance

#116

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.

Full time? Awesome! What is your start up?

Are you using a framework? Please tell us more :)

Re: Ruby vs. Crystal Performance

#118
post #34

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.

May I ask what language you decided to move to instead?

Re: Ruby vs. Crystal Performance

#119

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.

Huh, that seems a bit surprising to me. I did rails development for a year on sublime text and had a grand old time.

Re: Ruby vs. Crystal Performance

#120

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

> Metaprogramming doesn't need to have a performance impact.

Optimising away the performance impact of most of the metaprogramming features I mentioned there requires truly heroic optimisations, beyond what has ever been used for any other language.

Some of them are even worse - I'm not sure there any way to optimise away the non-local effects of Proc#binding, which allows you to access local variables not lexically referenced.

Post reply on HN