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

91–100 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#91

Post by Svenskunganka »

ghayes wrote: post #84
thinkpad20 wrote: post #62

Earlier quoted context omitted.

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…

One of the largest areas of concern is for real-time systems (systems which fail if they do not respond within some small time threshold). Most GC involves stopping the world to perform the GC which can pause your program's execution for some number of milliseconds. If GC pauses exceed your real-time requirements, you're out of luck. Some languages, like erlang, do slightly better by garbage collecting erlang process…

This is known, but it's always possible to overcome these situations and its part of the language maturing. Golang has already had its run with optimizing their GC for real-time systems. Twitch uses Golang for their IRC chat, and they've taken the Golang GC on a journey which you can read about here: https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06...

Crystal will at some point also be forced to optimize their GC for these cases, although it currently uses an out-of-the-box GC called Boehm-Demers-Weiser conservative garbage collector http://www.hboehm.info/gc/ which they have acknowledged they need to replace sooner or later.

Re: Crystal: Fast as C, Slick as Ruby

#92

Post by yamadapc »

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.

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.

Re: Crystal: Fast as C, Slick as Ruby

#93

Post by pcr0 »

Svenskunganka wrote: post #91
ghayes wrote: post #84

Earlier quoted context omitted.

One of the largest areas of concern is for real-time systems (systems which fail if they do not respond within some small time threshold). Most GC involves stopping the world to perform the GC which can pause your program's execution for some number of milliseconds. If GC pauses exceed your real-time requirements, you're out of luck. Some languages, like erlang, do slightly better by garbage collecting erlang process…

This is known, but it's always possible to overcome these situations and its part of the language maturing. Golang has already had its run with optimizing their GC for real-time systems. Twitch uses Golang for their IRC chat, and they've taken the Golang GC on a journey which you can read about here: https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06... Crystal will at some point also be forced to optimize…

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.

Re: Crystal: Fast as C, Slick as Ruby

#94

Post by djur »

_uhtu wrote: post #65
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.

This isn't true. Ruby uses native integers when possible and then switches to bignums when the integer gets big enough.

Re: Crystal: Fast as C, Slick as Ruby

#95

Post by Svenskunganka »

pcr0 wrote: post #93
Svenskunganka wrote: post #91

Earlier quoted context omitted.

This is known, but it's always possible to overcome these situations and its part of the language maturing. Golang has already had its run with optimizing their GC for real-time systems. Twitch uses Golang for their IRC chat, and they've taken the Golang GC on a journey which you can read about here: https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06... Crystal will at some point also be forced to optimize…

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.

Ah, I see what you mean. Thank you for clarifying!

Re: Crystal: Fast as C, Slick as Ruby

#96

Post by makufiru »

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…

In my experience, Golang's Windows support is actually fairly poor. I think it is largely to do with the clunky interface that is CGo. I found Rust to be less "warty" by a large margin with good library support in a lot of areas. Your mileage may vary, of course.

Re: Crystal: Fast as C, Slick as Ruby

#97

Post by dx034 »

makufiru wrote: post #96
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…

In my experience, Golang's Windows support is actually fairly poor. I think it is largely to do with the clunky interface that is CGo. I found Rust to be less "warty" by a large margin with good library support in a lot of areas. Your mileage may vary, of course.

This is not what I experienced so far. I use Golang on both Linux and Windows (50/50) and I didn't have any problems. What are you referring to exactly?

Re: Crystal: Fast as C, Slick as Ruby

#98

Post by makufiru »

dx034 wrote: post #97
makufiru wrote: post #96

Earlier quoted context omitted.

In my experience, Golang's Windows support is actually fairly poor. I think it is largely to do with the clunky interface that is CGo. I found Rust to be less "warty" by a large margin with good library support in a lot of areas. Your mileage may vary, of course.

This is not what I experienced so far. I use Golang on both Linux and Windows (50/50) and I didn't have any problems. What are you referring to exactly?

As I said, YMMV but the biggest standout that I remember was trying to play sounds using the windows API. There weren't any packages our team could find that really did it correctly, the one that everyone pointed to leaked memory like crazy and it was hard for us to track down since it relied on bouncing back and forth between C and Go so frequently (making malloc/free lifetimes difficult to follow because C can't know what things have been GC'd by the Go runtime)

Re: Crystal: Fast as C, Slick as Ruby

#99

Post by dikaiosune »

eridius wrote: post #61
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?

I don't personally think any of them should go away. I just note that many newcomers to the language feel they're opaque. Having written a good bit of rust now I do sometimes find the sigils impact readability (especially in macro_rules).

Re: Crystal: Fast as C, Slick as Ruby

#100

Post by erez »

First thing I look for whenever I run across another "C competitor" is to look which language it is implemented in. Usually that's C, or C++, but this time, it does look like Crystal is implemented in Crystal, which is, to me, a very good indication that this is a "real" system language.

I believe Rust is also implemented in Rust and Go, after a few years of being implemented in C has now a compiler written in Go.

Post reply on HN