Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crystal: Fast as C, Slick as Ruby

blog.codeship.com

Post reply on HN
Print view View original

31–40 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#31

Post by transfire »

I've done some coding Crystal when I have Ruby scripts I really need to run faster. I generally see about a 5x performance over Ruby.

It certainly is great to be able to jump right into Crystal coming from Ruby. It isn't very hard to convert most Ruby code to Crystal -- you just have to go through and "typify" everything. A few methods have different names and of course some don't exist but most of it is there.

My one grip with Crystal however, and why I haven't adopted it more generally, is that much of the "Lisp-like" features of Ruby are all but lost. Crystal makes up for some of this with macros, but it doesn't quite cut it. For example, you can't splat an array into a lambda in Crystal. Arguments have to be tuples which are compile-time bound. Little things like this feel very limiting to an experienced Ruby developer.

Re: Crystal: Fast as C, Slick as Ruby

#32

Post by Svenskunganka »

catnaroek wrote: post #2

The really important questions in any modern language: (0) Does Crystal have a lot of undefined behavior like C? (1) Does understanding Crystal programs require a lot of trial and error just like in Ruby? (2) How good a job does Crystal do at preventing me from shooting myself in the foot? A language isn't to be judged just by the amazing programs you can write in it. (Turing-completeness and I/O facilities have that…

(0) It does not. It has a GC, and all features you'll likely use are memory-safe. You can of course use unsafe methods and raw pointers, but those are documented that they are unsafe and are usually only used for writing bindings to a C library. Macros for example are evaluated and constructed at compile-time, so no undefined behaviour can come from those. Most methods have different behaviour. For example, one method may throw an exception, another return an error, and another simply return Nil. You know if you are using `hello!` `hello?` or `hello`, so no undefined behaviour there.

(1) Not at all, look at the source implementation of their language implementation. For example, the lexer: https://github.com/crystal-lang/crystal/blob/master/src/comp... Seems pretty clear to me.

(2) Not entirely sure what you mean since that is such a broad case, but as stated, Crystal stdlib is mostly safe.

Re: Crystal: Fast as C, Slick as Ruby

#33

Post by dbaupp »

dikaiosune wrote: post #9
catnaroek wrote: post #7

Earlier quoted context omitted.

What happens if you try to mutate a shared object from two threads, without using mutexes and locks, in languages without either Rust's compiler-enforced ownership or a global interpreter lock?

ConcurrentModificationException?

Java's collections don't (and can't, without high cost) make any guarantees that they will throw such an exception whenever they are modified concurrently... for one, data races can have weird consequences that aren't easy to detect. On that point, data races in Java are not undefined behaviour, they just have very weak guarantees about what happens (basically isolated loads and stores do reasonable things, and no fancier operations are available) which is another alternative to the Rust approach and the GIL approach.

Re: Crystal: Fast as C, Slick as Ruby

#34

Post by clessg »

acangiano wrote: post #24
clessg wrote: post #4

Looks very nice. I hope it gains momentum. For now, if you want a fast language with the beauty and productivity of Ruby, check out Elixir [0] and its web framework, Phoenix [1]. I've been using Phoenix for a year, and it's the first framework that I've actually liked more over time. And I've been a web developer for a decade. With its recent 1.0 release, Phoenix is gaining a lot of momentum. If you want some idea of…

Elixir is not a fast language. Not even close. Yes, it handles concurrency and parallelism beautifully which in turn enable distributed applications to perform quite well. But the language itself is significantly slower than Crystal / Rust / Go / Swift. It's not in the same category at all. That said, it's a great language worth recommending.

Oops, you're right that Elixir is not a computationally fast language. If you're looking for fast, raw number-crunching, look elsewhere. That said, real-world performance tends to be extremely good for real-time and networked applications (read: web apps). It's common for requests to be handled in microseconds, even in development.

Re: Crystal: Fast as C, Slick as Ruby

#35

Post by Illniyar »

catnaroek wrote: post #7
Illniyar wrote: post #3

Earlier quoted context omitted.

Is undefined behavior a thing outside of C? Is that really something you should question rather then just assume that modern language have no undefined behavior?

What happens if you try to mutate a shared object from two threads, without using mutexes and locks, in languages without either Rust's compiler-enforced ownership or a global interpreter lock?

Thats not really what peole refer to in C when they talk about undefined behaviour.

Re: Crystal: Fast as C, Slick as Ruby

#36

Post by rdtsc »

sundarurfriend wrote: post #25
clessg wrote: post #4

Looks very nice. I hope it gains momentum. For now, if you want a fast language with the beauty and productivity of Ruby, check out Elixir [0] and its web framework, Phoenix [1]. I've been using Phoenix for a year, and it's the first framework that I've actually liked more over time. And I've been a web developer for a decade. With its recent 1.0 release, Phoenix is gaining a lot of momentum. If you want some idea of…

Elixir gets plugged so often in other-language threads - whether it's Julia or Ruby or, like here, Crystal - that if it wasn't FOSS I'd have decided it's being astroturfed. I guess it's a good thing that people like it so much, but it's really starting to feel marketing-y by now.

> that if it wasn't FOSS I'd have decided it's being astroturfed.

That's a good sign!

You know why? Because it has a great community and is very friendly for new comers. Jose, Eric and the rest of the team made that a priority and it shows. It doesn't just mean being nice on IRC, it also means putting usability first, putting more effort in how example looks, how documentation looks and so on.

If Google invented a language then proceed to push and sponsor it, by paying authors to work on it, organizing marketing, hackathons etc, then it is hard to say if it popular because of Google's backing or because it has its own merits.

Re: Crystal: Fast as C, Slick as Ruby

#37

Post by hubert123 »

anp wrote: post #8

From this post, Crystal appears to have some of the things many people have been lusting after in Rust: sophisticated metaprogramming, fewer sigils, a bigger standard library, fibers/coroutines/whatever-they're-called-now. But it still has a GC :(. Rust has completely spoiled me with making it easy to minimize dynamic memory allocation and copies, and to know (almost always) deterministically when something will go a…

Yeah it's weird how Rust has suddenly made me look for no GC languages everywhere I look. It opened up a whole new desire to not accept no for an answer in that regard. I have this burning thought in the back of my head that there just has to be a simpler way to offer it than Rust does it too.

Re: Crystal: Fast as C, Slick as Ruby

#38

Post by continuations »

clessg wrote: post #34
acangiano wrote: post #24

Earlier quoted context omitted.

Elixir is not a fast language. Not even close. Yes, it handles concurrency and parallelism beautifully which in turn enable distributed applications to perform quite well. But the language itself is significantly slower than Crystal / Rust / Go / Swift. It's not in the same category at all. That said, it's a great language worth recommending.

Oops, you're right that Elixir is not a computationally fast language. If you're looking for fast, raw number-crunching, look elsewhere. That said, real-world performance tends to be extremely good for real-time and networked applications (read: web apps). It's common for requests to be handled in microseconds, even in development.

Is Elixir really fast for web apps though? According to the web framework benchmark [1] the performance of Elixir is pretty bad - it's consistently slower than python and ruby frameworks.

[1] https://www.techempower.com/benchmarks/#section=data-r12&hw=...

Re: Crystal: Fast as C, Slick as Ruby

#39

Post by ori_b »

hubert123 wrote: post #37
anp wrote: post #8

From this post, Crystal appears to have some of the things many people have been lusting after in Rust: sophisticated metaprogramming, fewer sigils, a bigger standard library, fibers/coroutines/whatever-they're-called-now. But it still has a GC :(. Rust has completely spoiled me with making it easy to minimize dynamic memory allocation and copies, and to know (almost always) deterministically when something will go a…

Yeah it's weird how Rust has suddenly made me look for no GC languages everywhere I look. It opened up a whole new desire to not accept no for an answer in that regard. I have this burning thought in the back of my head that there just has to be a simpler way to offer it than Rust does it too.

Yes. I'm currently trying to think of a good way to add it to Myrddin, which currently makes it more or less manual. Doing it in a simple way is a tough problem.

The simplest solution is to add the moral equivalent of 'null' -- objects that transition to an idempotently destructable state, which solves a lot of complexity with the data flow and analysis (yay!) at the cost of some safety (boo), and nulls (louder boo).

Re: Crystal: Fast as C, Slick as Ruby

#40

Post by piyushpr134 »

boyter wrote: post #23

The Fibonacci comparison is a poor example of performance gains because Ruby is using large number data types to ensure the correct result. This is according to the crystal language website itself. "However, Crystal might give incorrect results, while Ruby makes sure to always give the correct result." https://crystal-lang.org/2016/07/15/fibonacci-benchmark.html

That is true. Ruby does a lot in the background and one of the reason why it is slow
Post reply on HN