Hacker News Reader

Comment by everdev | Hacker News Reader

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.

View on HN

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 ^^

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

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.

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.

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.

https://luckyframework.org

>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?

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. :(

"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.

Reply on news.ycombinator.com