Crystal: Fast as C, Slick as Ruby • Hacker News Board

Re: Crystal: Fast as C, Slick as Ruby

#41

Post by rdtsc » Thu, Aug 04, 2016, 5:59 AM UTC

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.

> Elixir is not a fast language.

Depends what we mean by fast. I have seen Erlang VM handle 100k requests per second on a distributed cluster. That's plenty fast. Moreover, because of fault tolerance, it means ability to have a better uptime, with less people on-call. "Fast" can also be measured to include that, if system goes 200k requests per second, but crashes at midnight and stays down for a few hours, the average "speed" can be quite low. In a laptop demo that's not visible, but in practice that's money and customers lost.

But if fast means, "let's multiple some matrices", then yeah can probably use Rust or C for that. It all depends on the problem domain.

Re: Crystal: Fast as C, Slick as Ruby

#42

Post by catnaroek » Thu, Aug 04, 2016, 6:01 AM UTC

Svenskunganka wrote: post #32

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 metho…

> (0) It does not. It has a GC, and all features you'll likely use are memory-safe.

Nice.

> (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.

How am I supposed to learn the language's semantics from a lexer?

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

Consider this use case: I spawn five fibers. Can I send the same mutable object to all five? If so, can they attempt to mutate the object without properly taking turns? (e.g., using a mutex)

Re: Crystal: Fast as C, Slick as Ruby

#43

Post by sdogruyol » Thu, Aug 04, 2016, 6:01 AM UTC

westoque wrote: post #30

Was wondering how many companies actually use Crystal in production. I was interested in Crystal but the lack of apps using it in production and proof of concept on the field is making me doubt its usefulness.

I'm the author of Kemal(kemalcr.com), a simple, fast and modern web framework for Crystal.

We've been using Crystal in production(at Protel) for more than 6 months for some heavy load APIs (100-200 req/s). We've replaced our Rails API with 64 unicorns to just 1 Kemal process and it's not even breaking any sweat while consuming nearly 100x less resource and 30x less CPU.

You can ask me about our experience.

Re: Crystal: Fast as C, Slick as Ruby

#44

Post by rdtsc » Thu, Aug 04, 2016, 6:06 AM UTC

continuations wrote: post #38

clessg wrote: post #34

Earlier quoted context omitted.

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=...

It is hard to say how they measure and what they measure. According to their "multiple queries" benchmark, which I guess is the real world one? (Unless everyone expects all custumers to line up and send their requests one after another one).

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

we should all be using Dart on the server coupled with MongoDB perhaps.

Re: Crystal: Fast as C, Slick as Ruby

#45

Post by kimshibal » Thu, Aug 04, 2016, 6:08 AM UTC

crystal on rails. i want this.

Re: Crystal: Fast as C, Slick as Ruby

#46

Post by catnaroek » Thu, Aug 04, 2016, 6:09 AM UTC

dbaupp wrote: post #33

dikaiosune wrote: post #9

Earlier quoted context omitted.

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 fa…

> they just have very weak guarantees about what happens (...) which is another alternative

Not a very usable one. It means that atomicity is something you have to fight very hard to actually get, and very easy to accidentally destroy.

Re: Crystal: Fast as C, Slick as Ruby

#47

Post by aidenn0 » Thu, Aug 04, 2016, 6:10 AM UTC

catnaroek wrote: post #10

dikaiosune wrote: post #9

Earlier quoted context omitted.

ConcurrentModificationException?

That's hardly any better than undefined behavior. It's not the program you want to write, under any possible circumstance, and the language should tell you so.

??? Ask any C programmer if they could wave their magic wand and turn every single undefined behavior in their programs into a segfault how much better their life would be. It's not a small improvement it's a huge improvement.

Re: Crystal: Fast as C, Slick as Ruby

#48

Post by viraptor » Thu, Aug 04, 2016, 6:12 AM UTC

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…

What do you mean by "sophisticated metaprogramming"? Rust has pretty sophisticated (sometimes I wish it was less) macro / compiler-plugin support.

Re: Crystal: Fast as C, Slick as Ruby

#49

Post by pjmlp » Thu, Aug 04, 2016, 6:12 AM UTC

happywolf wrote: post #5

What advantages Crystal has compared to other more modern languages that aim to compete with C? For example D and Rust.

It is Ruby done right if community would have bothered with performance.

Re: Crystal: Fast as C, Slick as Ruby

#50

Post by sanswork » Thu, Aug 04, 2016, 6:13 AM UTC

continuations wrote: post #38

clessg wrote: post #34

Earlier quoted context omitted.

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=...

Chris McCord said the following on reddit after the results came out:

"We don't know what caused the errors and unfortunately we didn't have a chance to collaborate with them on a true run. A few months ago they added Phoenix in a preview, but it was a very poor implementation. They were testing JSON benchmarks through the :browser pipeline, complete with crsf token generation. They had a dev DB pool size of 10, where other frameworks were given of pool size of 100. And they also had heavy IO logging, where other frameworks did no logging. We sent a PR to address these issues, and I was hoping to see true results in the latest runs, but no preview was provided this time and we weren't able to work with them on the errors. tldr; these results are not representative of the framework."

From my personal experience going from Rails/Sinatra to Phoenix it feels a lot faster but I haven't done any benchmarks so take that with a grain of salt.