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.
Why SQLite?
Ruby vs. Crystal Performance
101–110 of 151 posts
Re: Ruby vs. Crystal Performance
#102The 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
Recursive fibonacci is highly artificial, but the fact that a compiler can greatly transform the program is an important advantage of compilers over interpreters.
When you're doing something like writing your own routine for calculating fibonacci numbers, perhaps. But that's not the kind of optimization that's likely to be significant to most developers writing business applications.
I would also argue that the ubiquity of things like BLAS wrappers largely blurs these lines. For example, one of the big reasons I choose Python over Java (my company's primary language) for my work is that, thanks to numpy, Python absolutely smokes Java at crunching numbers, for my purposes. This despite Java being a compiled static language and Python being an interpreted dynamic language.
Re: Ruby vs. Crystal Performance
#103Earlier quoted context omitted.
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.
For real metaprogramming try Clojure. It's another world entirely.
isn’t clojure like a lisp with extra steps?
Re: Ruby vs. Crystal Performance
#104Neat 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.
Why SQLite?
That’s how I started it. I didn’t want to start a company with a complex setup. The whole service runs on a single machine so it’s very fast and simple. I just back up the SQLite file every hour to s3. Its easy to download that file from s3 to use production data in development.
If I start getting scaling problems I’d have to start using multiple servers and at that point I’d need Postgres.
But we’re at ~36 employees and 8 figures of revenue on a single server.
I can probably go another year or 2 without a big database.
Re: Ruby vs. Crystal Performance
#105Earlier 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..
There has never been a "true" OO language. And if it there was, Smalltalk was not it. Alan Kay did coin the term, but Simula existed long before Smalltalk. The tree of languages that include C++, Java, and C# can be traced back to Simula while Smalltalk inspired Ruby. There is a distinct camp of "statically typed OO" (Simula and its children) and "dynamically typed OO" (Smalltalk and its children).
Yet none of this is the one true OO. All of it remains a way of describing a human mode of expression, and so is rightly subjective.
Re: Ruby vs. Crystal Performance
#106Crystal 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!…
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 raise ImproperListException, j
end
end # Cell
# Cons cell
class Cell For the performance boost, see https://github.com/nukata/little-scheme/tree/v1.3.0#performa... which shows times to solve 6-Queens on a meta-circular Scheme as follows:
* Crystal 0.34.0: crystal build --release scm.cr: 2.15 sec.
* Crystal 0.34.0: crystal scm.cr: 9.88 sec.
* Ruby 2.3.7: ruby scm.rb: 84.80 sec.
Compiled (and complex enough) Crystal code runs 39 times faster than the equivalent Ruby code in this case.
Re: Ruby vs. Crystal Performance
#107Earlier quoted context omitted.
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..
There has never been a "true" OO language. And if it there was, Smalltalk was not it. Alan Kay did coin the term, but Simula existed long before Smalltalk. The tree of languages that include C++, Java, and C# can be traced back to Simula while Smalltalk inspired Ruby. There is a distinct camp of "statically typed OO" (Simula and its children) and "dynamically typed OO" (Smalltalk and its children). Yet none of this i…
https://cs.brown.edu/~sk/Publications/Papers/Published/kf-pr...
Programming Paradigms and Beyond, Shriram Krishnamurthi and Kathi Fisler:
OO is a widely-used term chock-full of ambiguity. At its foundation, OO depends on objects, which are values that combine data and procedures. The data are usually hidden (“encapsulated”) from the outside world and accessible only to those procedures. These procedures have one special argument, whose hidden data they can access, and are hence called methods, which are invoked through dynamic dispatch. This muchseems to be common to all OO languages, but beyond this they differ widely:
* Most OO languages have one distinguished object that methods depend on, but some instead have multimethods, which can dispatch on many objects at a time.
* Some OO languages have a notion of a class, which is a template for making objects. In these languages, it is vital for programmers to understand the class-object distinction, and many students struggle with it (Eckerdal & Thune, 2005). However, many languages considered OO do nothave classes. The presence or absence of classes leads to very different programming patterns.
* Most OO languages have a notion of inheritance, wherein an object can refer to some other entity to provide default behavior. However, there are huge variationsin inheritance: is the other entity a class or another (prototypical) object? Can it refer to only one entity (single-inheritance) or to many (multiple-inheritance), and if the latter, how are ambiguities resolved? Is what it refers to fixed or can it change as the program runs?
* Some OO languages have types, and the role of types in determining program behavior can be subtle and can vary quite a bit across languages.
* Even though many OO aficionados take it as a given that objects should be built atop imperative state, it is not clear that one of the creators of OO, Alan Kay, intended that: “the small scale [motivation for OOP] was to find a more flexible version of assignment, and then to try to eliminate it altogether”; “[g]enerally, we don’t want the programmer to be messing around with state” (Kay, 1993).
In general, all these variations in behavior tend to get grouped together as OO, even though they lead to significantly different language designs and corresponding behaviors, and are not even exclusive to it (e.g., functional closures also encapsulate data). Thus, a phrase like “objects-first” (sec. 6.1)can in principle mean dozens of wildly different curricular structures, though in practice it seems to refers to curricula built around objects as found in Java.
Re: Ruby vs. Crystal Performance
#108Earlier 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…
Another issue with writing rails is the "bug in production that would've been caught at compile" issue lots of people have. There's been multiple instances early in my career when I missed a nil guard somewhere that broke months later because someone else used the method and sent it a nil. Types are super useful because they also work as on-demand accessible documentation, and the compiler helps you figure out well in advance when you're sending an invalid input etc.
Re: Ruby vs. Crystal Performance
#109Earlier 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.
With solargraph I have great go-to-def when working with ruby in VSCode. It doesn't do well with jumping to def for gems/ dynamic methods, but a solid 80% of the time I can jump to/from references easily.
Re: Ruby vs. Crystal Performance
#110Earlier 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.
Depends on how you count. On a application level, no. On a class level, also no. On a method level, no but we are getting close. On a row level, possibly. On a token level, definitely.