Hacker News Reader

Comment by arc-in-space | Hacker News Reader

Finding a description of what the language is actually about on the home page was hard, so here it is: https://crystal-lang.org/api/1.1.0/

View on HN

The old slogan used to be "Slick as Ruby, Fast as C" but I'm guessing that just invites people to constantly compare runtimes to C and be like "look! it's 50% slower when blahblahblah" when comparing 10ns to 15ns.

That said, I do think they should put the "why" in clear text. Ruby made no apologies for being a language "for the programer" while Crystal is meant to be a language "nice for the programmer with slick syntax and a modern type system AND compiles to very efficient bytecode that's comparable with C (at the cost of more time spent compiling to reach those goals)"

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

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