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

61–70 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#61

Post by eridius »

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…

Rust already lost most of its interesting sigils. I'm curious which sigils that are left you think should go away?

Re: Crystal: Fast as C, Slick as Ruby

#62

Post by thinkpad20 »

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…

Manual or deterministic memory management might be a must-have for certain usage domains, but for any domain in which one would be using ruby, this seems unlikely, and presumably one could FFI into C when this is the case. There are hardly any languages commonly used in industry which don't have GC (essentially just C/C++). And many of these garbage-collected languages are capable of blazingly fast code with a small memory footprint.

Regardless, for a language which is meant to operate in the same domain as ruby and be as easy and declarative, not having a GC would be a puzzling decision.

As a side note, I'm curious what areas you are programming in where the presence of a GC is such a downside. Having written almost exclusively in garbage-collected languages over the last few years, it's something I almost never think about (and happy not to). Of course I don't deny that stricter memory control is sometimes necessary.

Re: Crystal: Fast as C, Slick as Ruby

#63

Post by rdtsc »

Scarbutt wrote: post #51
rdtsc wrote: post #44

Earlier quoted context omitted.

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.

The Dart vm is pretty damn fast, way faster for any CPU bound stuff than the BEAM.

Faster than C++, Java, Go?

Re: Crystal: Fast as C, Slick as Ruby

#64

Post by eridius »

dikaiosune wrote: post #55
viraptor wrote: post #48

Earlier quoted context omitted.

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

Perhaps that's not the right way to phrase it. I guess I'm mostly thinking of compiler plug-ins which are very unstable right now. Which means that most users probably never write procedural macros in their own code. (I certainly don't)

There's also syntex (https://crates.io/crates/syntex), which basically provides compiler plugins for stable rust. It does so via code generation though.

Re: Crystal: Fast as C, Slick as Ruby

#65

Post by _uhtu »

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

i actually think it's a good example for just that reason. Ruby will automatically use those big number types on production applications as well as the fibonacci application, so it's demonstrating that difference and the effect that it has.

Re: Crystal: Fast as C, Slick as Ruby

#66

Post by TickleSteve »

aidenn0 wrote: post #47
catnaroek wrote: post #10

Earlier quoted context omitted.

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.

Thats simply not true.

UB is simply the latest stick to hit C with. In day-to-day working nobody worries about UB at all as you generally don't notice it.

Same with lack of a GC; this is a plus point for C for most applications, not a negative.

(and yes, I do have plenty of experience in it, I've been using it for the past 20 years, have you?).

Re: Crystal: Fast as C, Slick as Ruby

#67

Post by bluetomcat »

Athas wrote: post #6

The claim is "fast as C", so I was surprised that the performance comparison was with Ruby, not with C. On my machine, the Ruby Fibonacci program executes in 47.5s, while a corresponding C program executes in 0.88s - that's a factor 54 difference, while the article reports a factor 35 for Crystal. That's good, but what causes the difference? This benchmark is pretty much all function call overhead, so I doubt it's re…

All of these "fast as C" claims about modern, high-level Python-like languages (be they statically typed and natively compiled) are missing the point. It is mostly the minimalistic and terse programming style that C encourages that makes C programs performant. You avoid allocations wherever possible, you write your own custom allocators and memory pools for frequently allocated objects, you avoid copying stuff as much as possible. You craft your own data structures suited for the problem at hand, rather than using the standard "one size fits all" ones. Compare that to the "new this, new that" style of programming that's prevalent today.

Re: Crystal: Fast as C, Slick as Ruby

#68

Post by acangiano »

duaneb wrote: post #57
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.

I'm not sure why you're grouping those four languages as they overlap very little. Go has latency and emphasizes network bound services (and randomly docker for some reason, I'm sure a good one); rust is a c replacement; swift is for writing iOS/Mac apps; and crystal is a newborn. I'd actually call it quite close to go: a high emphasis on concurrency and services. Single thread performance matters much less when scal…

I listed a few examples of emerging languages to clarify that Elixir is not in the same class when it comes to computational performance on a single machine. The performance profile is indeed Erlang-like.

Keep also in mind that my reply was within the context of a thread on Crystal. OP sort of sold Elixir as a fast language that we can use now while we wait for Crystal to mature.

My point is not that Elixir is useless. My point is that we must not oversell Elixir as a fast language. Generally speaking, it isn't. It excels at horizontal scaling, which is great, but I wouldn't call it "fast" without proper qualifiers.

Re: Crystal: Fast as C, Slick as Ruby

#69

Post by _uhtu »

sdogruyol wrote: post #43
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.

My biggest concern if i were to try to use Crystal in production would be the lack of "googleability". I'm guessing your team is very familiar with the language, so it's not as much of a problem that you can't Google a problem when it happens. Do you feel that this is a major roadblock for people new to crystal, or are the majority of errors very intuitive? the second thing is that according to the site crystal is in alpha and making breaking changes sometimes. how often do you have to refactor after an update and how difficult has it been to spot and fix that something is broken by an upgrade? Very interested in using it myself but can't bring myself to commit an app to it.

Re: Crystal: Fast as C, Slick as Ruby

#70

Post by damagednoob »

sdogruyol wrote: post #43
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.

1. Has the lack of multithreading been a problem in any way? 2. Do you do the standard deployment of putting nginx/haproxy in front of a load of processes? 3. Have you been able reuse any Ruby code (including gems) or do they have to be Crystal specific.
Post reply on HN