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

121–130 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#121

Post by piaste »

bluetomcat wrote: post #67
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 muc…

Nitpick: everything you say is probably correct, but such performant C programming is also the very opposite of a "minimalistic and terse style".

Which one is more minimalistic, 'new Foo' or a collection of various custom-tuned allocation methods? Which one is more terse, 'myList.Where(foo).Select(bar).Aggregate(baz)' or an explicit for loop?

Re: Crystal: Fast as C, Slick as Ruby

#122

Post by friendzis »

rm445 wrote: post #109
pcr0 wrote: post #93

Earlier quoted context omitted.

The parent comment is referring to hard real-time systems (where not responding within a certain timeframe would lead to catastrophy). We're talking things like pacemakers, anti-lock brakes, industrial control systems. Regardless of how good GC is you would never use it in a hard real-time system because it is non-deterministic. IRC chat is only soft real-time.

Just as a point of interest, I believe there are special forms of garbage collector that are suitable for hard real time systems. The principle is to regularly use a bounded amount of time for collecting - in line with the latency requirements for the whole system. I think the relevant term is 'tick tock', as in tick - compute, tock - collect.

The thing about hard real time systems is that they must be predictable, which is quite wide term. Predictable memory utilization, predictable computation cost, predictable response time. In an attempt to at least fit into these requirements GC must be "passive", on-demand i.e. callable from code. Even with bounded collect times, number of collectings must be predictable/controlled to predict computational cost/time of code paths. And that becomes not much different from manual memory management.

Re: Crystal: Fast as C, Slick as Ruby

#123

Post by bluetomcat »

piaste wrote: post #121
bluetomcat wrote: post #67

Earlier quoted context omitted.

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

Nitpick: everything you say is probably correct, but such performant C programming is also the very opposite of a "minimalistic and terse style". Which one is more minimalistic, 'new Foo' or a collection of various custom-tuned allocation methods? Which one is more terse, 'myList.Where(foo).Select(bar).Aggregate(baz)' or an explicit for loop?

It is minimalistic in the sense that the language provides a narrow set of primitives and a skilled programmer combines these primitives in the most sensible way to solve the problem at hand. Higher level stuff in most other languages is much more generic.

Indeed, it may not be minimalistic in terms of the code size.

Re: Crystal: Fast as C, Slick as Ruby

#124

Post by sitkack »

Taek wrote: post #110
fauigerzigerk wrote: post #104

Earlier quoted context omitted.

Crystal seems to be targeted at a domain where ruby is not fast enough. That includes domains where GC is a problem. A tracing GC means that you either have to deal with potentially long GC pauses or you need a lot of extra free memory at all times to give the GC time to catch up before running out of memory [1]. Go says it can achieve 10ms max pause time using 20% of your CPU cores provided you give it 100% extra me…

If you are on a server do you need 10ms max pause time? For most applications running go on a remote machine, 25ms should be in the realm of acceptable.

http://latencytipoftheday.blogspot.com/2014/06/latencytipoft...

Re: Crystal: Fast as C, Slick as Ruby

#125

Post by WalterBright »

bjz_ wrote: post #114
yamadapc wrote: post #92

Earlier quoted context omitted.

The D Language ( http://dlang.org/ ) has a @nogc pragma ( https://dlang.org/spec/attribute.html#nogc ). You just annotate functions that you don't want to use the GC in with it and it'll assert that they don't use it.

But then you lose memory safety

That's being fixed.

Re: Crystal: Fast as C, Slick as Ruby

#127

Post by spoiler »

kristianp wrote: post #54
Svenskunganka wrote: post #15

I'd like to put out there that Crystal is absolutely awesome. The language itself is Crystal clear, but the language documentation and API documentation - oh my! I had never worked with compiled languages before I tried Crystal, but had always had a huge interest in getting into that. When I wanted to learn the compiled ecosystem I looked at languages like Go and Rust, but the learning curve for those was a bit overw…

Maybe the makers of Crystal need to take a leaf out of Go's book. Despite the Go creators not being windows users (AFAIK), they support Windows as a primary target, to help adoption, I assume. Of course the Crystal people probably don't have the same number of developers working on it as Go did even early on. Edit: Go took a little while to support windows, not until around July 2010. See this question from November…

Crystal supported Windows (albeit unofficially, and it was an epic adventure to compile it, and I've never tried running any serious code on it), however all support practically ceased when it switched from libpcl to inline ASM for coroutines.

Re: Crystal: Fast as C, Slick as Ruby

#128

Post by solidsnack9000 »

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…

The biggest practical downside with Elixir relative to Crystal is lack of types. The per-thread GC is an important advantage, though.

Re: Crystal: Fast as C, Slick as Ruby

#129

Post by ricardobeat »

_uhtu wrote: post #69
sdogruyol wrote: post #43

Earlier quoted context omitted.

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…

Chiming in re. "googleability", go has the same problem (despite coming from Google :D). What you do is always search for 'crystal lang xxx'. It will get better as adoption increases.

Re: Crystal: Fast as C, Slick as Ruby

#130

Post by the_duke »

duaneb wrote: post #52
hubert123 wrote: post #37

Earlier quoted context omitted.

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.

Memory management is difficult, extremely difficult, to get correct in the way rust does. I don't think I've seen a leak or bad dereference in years. The only way it really manages this is by tying references into what amounts to a proof assistant. Every simpler method of which I can think either sacrifices capability (e.g. no references at all; only raii + copy on write) or it becomes a GC with all its wonderful tra…

I think you meant

-> 'extreymely difficult to get INcorrect in the way rust does'

Post reply on HN