4 ms·

Crystal has had concurrency, almost identical to goroutines, for a long time. It's just as if you're always running with GOMAXPROCS=1. And you can still get som

by RX14 8y ago

Crystal has had concurrency, almost identical to goroutines, for a long time. It's just as if you're always running with GOMAXPROCS=1. And you can still get some excellent performance on IO bound workloads with a single core. The challenge is expanding what crystal is already good at to CPU bound parallelizable workloads by implementing parallelism. This work should be done before 1.0, we have a lot more resources to work on crystal from now on, because brian is working on it full time. And as for windows support, I'm working on it right now. Cross-compiling "hello world" has been working for a while.

Blackstone4 8y ago
Thanks for the response. I'm no expert but when you have a server, would each request be handled concurrently by a separate thread (/fibre?)? So in that sense would the server's I/O be non-blocking? (I know each thread would be blocked as it waits for the response). Do you have a rough time frame for parallel concurrency? What's your view on the maturity of the language?
- RX14 8y ago
  No, each request is handled concurrently in the same thread using evented IO. You spawn fibers, which are the analogue to go's goroutines, and many of those run in one thread. Just like nodejs (without callbacks/promises/async/await) and similar to go with GOMAXPROCS=1. Unfortunately, I don't have a timeframe for parallelism, it's not my area of crystal and it's a fairly tricky issue. My (biased, i'm a core developer) view on Crystal's maturity, after using it in a few of my own side-projects, is that once crystal code compiles, it runs pretty much rock solid in production. Compiler bugs are fairly rare too, although the compiler clearly isn't as mature as gcc. The main issue you face is lack of available libraries, and being forced to make a few changes every couple months when a new release comes out with breaking changes. Depending on the size of your codebase, that could be a big issue or it could be a 5 minute easy commit.
  - Blackstone4 8y ago
    Thank you for adding more color around Crystal. I'm somewhat new to this so bear with me. With regards to the I/O, is it like node.js? i.e. all requests are handled inside a single thread (until Crystal gets parallelism) and when the thread waits for an I/O response (i.e. a database call), it will process some of the other requests?
    - RX14 8y ago
      Yep, exactly like that.

by RX14 8y ago

Blackstone4 8y ago

Thanks for the response. I'm no expert but when you have a server, would each request be handled concurrently by a separate thread (/fibre?)? So in that sense would the server's I/O be non-blocking? (I know each thread would be blocked as it waits for the response). Do you have a rough time frame for parallel concurrency? What's your view on the maturity of the language?

RX14 8y ago
No, each request is handled concurrently in the same thread using evented IO. You spawn fibers, which are the analogue to go's goroutines, and many of those run in one thread. Just like nodejs (without callbacks/promises/async/await) and similar to go with GOMAXPROCS=1. Unfortunately, I don't have a timeframe for parallelism, it's not my area of crystal and it's a fairly tricky issue. My (biased, i'm a core developer) view on Crystal's maturity, after using it in a few of my own side-projects, is that once crystal code compiles, it runs pretty much rock solid in production. Compiler bugs are fairly rare too, although the compiler clearly isn't as mature as gcc. The main issue you face is lack of available libraries, and being forced to make a few changes every couple months when a new release comes out with breaking changes. Depending on the size of your codebase, that could be a big issue or it could be a 5 minute easy commit.
- Blackstone4 8y ago
  Thank you for adding more color around Crystal. I'm somewhat new to this so bear with me. With regards to the I/O, is it like node.js? i.e. all requests are handled inside a single thread (until Crystal gets parallelism) and when the thread waits for an I/O response (i.e. a database call), it will process some of the other requests?
  - RX14 8y ago
    Yep, exactly like that.