some of these benchmarks Fibonacci etc are superficial. don't reflect real world use. people need to start comparing languages on ecosystems etc, error reporting e.g Elm | Rust have beautiful error messages. time to write a feature and deployment. Your language | framework could run in microseconds etc but if getting started is a nightmare or it has cryptic error messages, then it's non starter
Ruby vs. Crystal Performance
81–90 of 151 posts
Re: Ruby vs. Crystal Performance
#82Earlier 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.
What is your editor of choice? Go to definition has worked for Ruby in Sublime for a long time. I actually can't remember a time it didn't work.
Re: Ruby vs. Crystal Performance
#83Earlier quoted context omitted.
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.
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..
Re: Ruby vs. Crystal Performance
#84Huge ruby ran here. Ruby on Rails has been my day job for a decade, and it pays the bills well enough. Crystal has always been a curiosity to me, but I have never been as productive in any other language or framework as I have been with Rails. I dont' care if you're language is "ruby-like" or "go fast" - if I'm not as productive with it as I am with Ruby, I'm not gonna touch it. Get back to me when there is Crystal o…
Here you go: https://spider-gazelle.net/
Re: Ruby vs. Crystal Performance
#85Huge ruby ran here. Ruby on Rails has been my day job for a decade, and it pays the bills well enough. Crystal has always been a curiosity to me, but I have never been as productive in any other language or framework as I have been with Rails. I dont' care if you're language is "ruby-like" or "go fast" - if I'm not as productive with it as I am with Ruby, I'm not gonna touch it. Get back to me when there is Crystal o…
I'm sure that it's nowhere near as productive as Rails, but this framework is probably best positioned to be the Rails of Crystal, in case you haven't seen it:
Re: Ruby vs. Crystal Performance
#86Earlier quoted context omitted.
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.
When you have +100,000 LOC written over many years by people with varying degrees of experience and familiarity with the language, Ruby/Rails becomes unmanageably difficult a lot faster than other languages. It isn't the only one though.
Not that you can't have a great, large Rails codebase but the "guardrails" are a lot less present than in some languages and it can be harder to try to clean up the mess once it's happened.
Re: Ruby vs. Crystal Performance
#87Crystal 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!…
[deleted]
Re: Ruby vs. Crystal Performance
#88Earlier quoted context omitted.
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 r…
A JS integer is actually an instance of the "Number" object, you can to a small degree alter fundamental behavior even with primitive types
Re: Ruby vs. Crystal Performance
#89Earlier 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. 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.
To be clear, crystal does have method_missing.
Re: Ruby vs. Crystal Performance
#90> If you recall Crystal is a statically typed language but you can omit explicit type restriction and the compiler will try to infer the type of variable. In our code Crystal uses the Int32 type for the n variable which has the maximum value of 2,147,483,647 but the 47th number is higher. In this case we need to specify the type of n. We can use Unsigned Int 64.
Both Ruby and Python use arbitrary-precision integers throughout. I thought Crystal would do the same, given the frequent comparisons to Ruby. I assume the reason it doesn't is to enable AOT compilation (i.e. not only because Crystal is statically-typed)?
Is there a statically-typed language that does use arbitrary-precision integers throughout?
More generally, what other features are common in dynamic languages and rare in static ones, that aren't directly related to type-safety?