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.

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?

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.

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?

Yep, exactly like that.

I've programmed in both and as far as I can tell here's the best use case for each:

Go - I want to program explicitly and don't mind a little extra code or syntax to do it. I want close to the best performance possible and a single distributable binary. I don't mind being encouraged to "roll my own" api / web app rather than using a framework.

Crystal - I want to feel like I'm writing in Ruby, but with type checking at compile time and much better performance. I don't mind being a little less performant than other compiled languages. I want access to Rails/Sinatra-like frameworks for web/API apps rather than having to "roll my own".

Basically, if you want something quick and fun that can run in production, I love Crystal. If you want something that needs to be custom and highly performant, I love Go.

Great response. [EDIT - as highlighted by the replies below you can't use Rails with Crystal...my fault for misreading the parent] I didn't quite realize that I could use Rails with Crystal. That would be make it more interesting if I knew how to use Rails ^^

Unfortunately, you can’t use actual-Rails in Crystal (it’s written in Ruby which is similar but not exactly the same).

But there are Rails-like frameworks you can use in Crystal that are just as much fun (though understandably less mature).

Check out Amber, Lucky, and Kemal to give you an idea of what’s out there.

I would definitely recommend amber. It's probably the most rails-like, and is more mature than other solutions at this point (kemal is more like sinatra, though it is obviously more mature being rather ancient by crystal standards)

Lucky uses type safety extensively preventing a lot of bugs. My team really enjoys working with it. You should definitely check it out.

While you can't use Rails, there are frameworks that I have heard are "similar", such as https://luckyframework.org/.

Disclaimer: I haven't used it, just read a bit about it.

You can't use rails with crystal, the keyword is "rails-like".

>I don't mind being a little less performant than other compiled languages.

The same, if not more so, goes for Go. It might be statically compiled, but it's far from the most optimised performer.

Crystal - because it uses LLVM's optimizer - is probably better optimized at the codegen level than go. We still have a long way to go to get an optimized GC and similar though. Luckilly, bdwgc isn't too terrible.

> I don't mind being a little less performant than other compiled languages.

What other languages? Because the language uses "Fast as C" as part of it's tagline. Is this a false claim?

"Fast as C" should maybe be changed to something else. Crystal can bind directly to C functions and libraries without any overhead, plus you have pointers and other stuff. So you could really write code that runs as fast as C if you program like in C, but with Crystal syntax. That's where the tagline comes from. But of with course normal usage of the language, with its heap-allocated stuff, garbage collector and usual stuff (like Array#map, which does allocate a new array), you won't get performance like C, but it will be acceptable, and usually faster than dynamic/interpreted languages.

That's definitely such an underspecified claim that it's not even wrong. Fast as C under what conditions?

I've personally found that a lot of Go's marketing is, if not misleading, outright false. As an example: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

If you were to use Go you would know that the GC is indeed pretty fast, on part or faster than Java / C# in many scenarios.

That's exactly what the article I linked said, isn't it? It has low pause times, at the expense of everything else.

Beware trading a visible cost for an unbounded number of smaller costs. In Go's case, in return for minimal pausing you get memory fragmentation, terrible performance if the GC is ever seriously taxed, and a 100% (!) heap memory use overhead. If you're just writing commandline daemons or servers you restart every ten minutes though, who cares?

Go doesn't come off too badly in this because it's not Java, which allocates like crazy. That's a laudable tradeoff, but that does not mean they solved garbage collection very well.

Crystal's definitely up there, faster than java at least for most workloads. That can be improved much further by innovating on the GC.

It really ought to say "fast LIKE c" because none of the core devs actually want crystal to be used for systems programming.

All they want is ruby with static types, that runs fast. Those things will satisfy them alone.

Intelligently written C/C++/D/Zig/Rust will always knock Crystal out of the park. :(

I think what we'll see coming soon, assuming some people work on it, is the recognition that Go's stdlib and all the supporting libs is where the real awesomeness lives. And for langs that support Go-style concurrency (like Crystal basically does, Kotlin, etc), people will start transpiling with only a couple of things dropping into the target language. There're just too many good pieces of crypto, http2, etc to rewrite it over and over.

I can attest to this, the amount of times I've had a look and used go's stdlib as a reference for what to do when implementing something in the std for crystal is too many to count!

Unfortunately, transpiling has a huge bunch of problems, which you can see in for example how quickly nim vs crystal compiler matured - even though the crystal compiler is more complex. I'd be interested in seeing go's stdlib, ssa backend, and toolchain turned into a robust library. Like LLVM but including a GC, a stdlib with a CSP implementation, and a complete toolchain for static compilation.

I'm curious about the transpiling problems from, say, Go to Crystal (not after SSA, but before w/ the high level constructs). I have toyed with Go to Kotlin and even though duck typing is unimplemented in the latter, I can basically get there. I even started a project to dump Go AST and type info[0] but I haven't completed it really. There are just too many amazing Go libs out there to not exercise this option.

Go does have a buildmode for c-archive and c-shared, but it's built around the hobbled Cgo, so you have to explicitly export funcs, and things like structs cannot be exported. Still, a swig-like shim/bridge could be developed, but I am unsure at what cost (I think the go mobile stuff does a form of this).

0 - https://github.com/cretz/go-dump

What do you think of Nim?

No opinion as I didn't look at it. I was more focused on more mature languages and Crystal came up on my radar so I read around it.

Hrm. Your post implies that Crystal is more mature than Nim, is that intentional? If so, what makes you think that?

Oh I didn't mean to imply that. I meant I was researching mature/mainstream languages and outside of the scope of that research, it just so happened a friend mentioned Crystal. So I looked into it.

I know absolutely nothing about Nim so I can't comment either way.

>I decided to learn Golang instead

So what has been your experience with Golang so far?