Hacker News Reader

Hacker News

Comment by b3morales | Hacker News Reader

Parent Full thread

b3morales

There's a list of what they consider important highlights, with snippets, if you scroll down https://crystal-lang.org/

* Syntax: Crystal’s syntax is heavily inspired by Ruby’s...

* Type System: Crystal is statically type checked...

and so on

View on HN

I'd love to see a "why" somewhere in there... telling me that its syntax is similar to Ruby and that it has a type system (which Ruby also has as of version 3, yeah?) isn't particularly helpful in telling my why the language is compelling.

I don't really see a "why use Crystal instead of Ruby" (or any other language, really) explanation anywhere. Maybe the things listed on the main page are meant to be that? Even if it's not on the main page a comparison would be nice in the docs (https://crystal-lang.org/docs/) or the reference (https://crystal-lang.org/reference/)

Ruby's type system is completely optional using separate definition files (except Sorbet, which isn't part of the core language), while Crystal's is built in and required.

It also seems like Crystal is compiled, yeah? Would it be safe to say "Crystal is like Ruby but compiled and faster"?

Crystal is like Ruby but not dynamic, with macros, without reflection, with arbitrary API changes to the core types that are shared, with value/reference type dichotomy, compiled, and faster.

Or, with apologies to the late Douglas Addams, Crystal is almost, but not quite, entirely unlike Ruby.

Crystal has compile-time macros/reflection, instead of runtime.

You can also think of it as "what if golang had a real type system and ruby style syntax".

The "Why?" is literally right there, in a big bold heading, directly under the goals: https://crystal-lang.org/api/1.1.0/

Crystal is a programming language with the following goals:

Have a syntax similar to Ruby (but compatibility with it is not a goal) Statically type-checked but without having to specify the type of variables or method arguments. Be able to call C code by writing bindings to it in Crystal. Have compile-time evaluation and generation of code, to avoid boilerplate code. Compile to efficient native code.

Why? We love Ruby's efficiency for writing code. We love C's efficiency for running code. We want the best of both worlds. We want the compiler to understand what we mean without having to specify types everywhere. We want full OOP. Oh, and we don't want to write C code to make the code run faster.

Crystal started way before Ruby's static type system[0].

Matz even mentioned Crystal as a study case while explaining what Ruby's static type system would be like - back in 2016[1].

[0] https://manas.tech/blog/2016/04/01/the-story-behind-crystal/ [1] https://youtu.be/1l3U1X3z0CE?t=1755

Reply on news.ycombinator.com