
Overview of the Crystal language - sdogruyol
https://marmelab.com/blog/2017/12/14/lets-cook-some-crystal.html
======
RX14
The consensus in this thread is that Crystal has lost a lot of steam recently
and little is being done. In fact, it's been nearly 6 months since the last
release. As a member of the core team, I'll be honest: this is correct.

Manas, Crystal's main commercial backer has had a very tough year and has been
unable to donate as much manpower to the project as previous years. The non-
manas members of the core team have had difficulty finding time too. This has
been a low point in the project, but it's very possible that 2018 will be a
different story. Development is picking up right now, extremely basic windows
support is just a few days from being merged into master, and the 0.24.1
release is imminent. There will be a blog post regarding this on crystal-
lang.org soon.

~~~
krylon
I have had my eyes on Crystal for a while now, and one of my New Year's
Resolutions for 2018 is to learn it.

I really hope the project does not collapse. What little I have seen was very,
_very_ exciting. I used to love Ruby, I did most my scripting in it for pretty
long time.

More recently, I have discovered the joys of strong static typing. A language
that combines Ruby's expressiveness with type safety and good performance
(let's face it - ruby's performance is not that impressive) sounds really
sweet.

This is definitely a language I would like to get to know. ;-)

~~~
RX14
Thanks for your kind words. If you ever find the time to learn it, you'll find
the gitter channel useful for any questions.

------
eatonphil
Crystal seems like a great high-level language and alternative to Ruby, but
the biggest blocker for me using it more generally is the lack of multi-
threading support. There is WIP support for threading but it has not been
committed. Moreover the Crystal developers either don't do a great job of
updating their multi-threading roadmap [0] or work on multi-threading has died
off. (I assume it is the latter because the thread-support branch has not
gotten any commits in 10 months [1].) Ultimately if I wanted the high-level
aspects of Ruby or Python and wanted more performance and great thread support
I'd probably go with Elixir (even taking into consideration BEAM weirdness).

[0] [https://github.com/crystal-lang/crystal/wiki/Threads-
support](https://github.com/crystal-lang/crystal/wiki/Threads-support)

[1] [https://github.com/crystal-lang/crystal/tree/thread-
support](https://github.com/crystal-lang/crystal/tree/thread-support)

~~~
k__
What is so good about multi-threading?

~~~
Doctor_Fegg
If you're considering Crystal over Ruby, chances are that speed is part of
your reasoning.

And if speed is important to you, then you want to use all 4/8/16 cores of
your machine, not just one.

~~~
smitherfield
Any web application is going to be almost entirely network and database-bound,
not CPU-bound. CPU-bound tasks are stuff like scientific computing, video
encoding, the Ruby interpreter and Crystal compiler themselves, etc.

The advantage of multithreading in a web application is not "using all cores"
but rather that the application can spawn a thread to "asynchronously" wait
for a response from the network or database while it continues doing other
work in the main execution thread, instead of "synchronously" blocking all
work while it waits.

In other words, web applications leverage concurrency with their use of
multithreading, not parallelism.

I will caveat that having more cores can give concurrent applications a small
performance improvement, because even though each thread is only using a CPU
core at around 0 to 15% (in short bursts) of capacity, switching between two
threads on the same core is a context switch, a fairly expensive operation.
More cores means fewer context switches.

But, unlike with parallelism, making use of more cores is not the reason
concurrency offers performance benefits. ~99% of the performance benefit of
concurrency is realized on even a single-core machine, whereas parallelism by
definition requires multiple cores to offer a speedup. Concurrent applications
such as web servers (e.g. Apache, Nginx) typically spawn hundreds or even
thousands of threads per CPU core.

~~~
cookiecaper
While this argument is valid and fine, I think it has mostly played out.
Previous language design choices that consciously ignored multithreading were
made in the mid-late 90s when the future of consumer SMP was unclear. Now it
is clear that multi-core is and will be an important component in everything
-- we have quad-core phones, dual-core cameras, etc.

While an application may be fine without good/native support for parallelism
in most cases, it's really nice to be using a language that allows you to bolt
it on easily when it turns out that you _do_ need it. At this point, it's a
language feature that's not worth leaving on the table without compelling
rationale.

Arguably, the class of high-level dynamic languages that were on the rise in
the mid-00s (Python, Ruby) lost a lot of steam to newcomers like Swift and Go
due to the language designers' hesitation around embracing parallelism.
Crystal should not repeat that mistake.

~~~
eatonphil
This is exactly the reason I'm concerned about investing in Crystal (and
OCaml, where multicore is also in an awkward state). I need to be confident
that when I need parallelism, the language supports it (good threading
primitives are imperative too, so not just pthreads).

~~~
RX14
We really really want to support parallelism and we've had some basic
successes so far. We're very confident we want this, and we're confident we
can come up with a performant solution: despite being a different language our
parallelism solution will likely end up close to Go's which has largely solved
this already.

We're not there yet but I'm confident the main barrier is time and manpower to
implement it, not willpower or technical reasons.

------
willcodeforfoo
Worth nothing: Thoughtbot is working on a web framework for Crystal, called
Lucky: [https://luckyframework.org/](https://luckyframework.org/)

It looks quite promising, but as others (including core team members) have
noted, development on Crystal seems to be losing steam. It's tempting but
seems like a bit of a gamble to pick Crystal for anything serious, especially
with great new languages like Elixir and Go gaining traction.

~~~
rubyfan
Surprised this is the only mention of Lucky.

Seems to have a lot of promise. I wrote off Crystal some time ago but Lucky
has my interest piqued and I’ve been building a few things with Lucky
recently.

------
sdogruyol
Crystal is a Ruby inspired compiled language, allowing it to run blazingly
fast with a very low memory footprint. It uses LLVM for emitting native code,
thus making use of all the optimisations built into the toolchain.

Website: [https://crystal-lang.org/](https://crystal-lang.org/) Github:
[https://github.com/crystal-lang/crystal](https://github.com/crystal-
lang/crystal)

~~~
pjmlp
For me Crystal is what Ruby might have turned out to be, if its designers
cared to take some inspiration from Dylan.

~~~
byroot
That makes no sense to me. Most of what makes Crystal different from Ruby
results from the former being a static language and the later being dynamic.

I understand that dynamic languages are not popular these days on HN, but it's
silly to suggest they should become static languages. They just offer
different tradeoffs, a bit like screws and nails.

~~~
pjmlp
Dylan is a Lisp (thus dynamic) with Algol-like syntax.

Dylan supports AOT compilation like Crystal, and had optional type checking,
so one could make it into Crystal if all variable declarations happened to be
annotated.

Don't forget Dylan was intended to be used as Newton systems programming
language and the team managed to create their own OS, even after C++ was
decided to take Dylan's role.

Personally dynamic languages without AOT or JIT support were never popular
with me beyond shell scripting tasks.

~~~
seanmcdirmid
I thought NewtonScript took Dylan’s place in Newton development?

~~~
pjmlp
No, Dylan was supposed to be a systems language in the spirit of Lisp
Machines.

But internal politics and battling between teams spoiled it.

Check the comments from mikelevins and wrs.

[https://news.ycombinator.com/item?id=15106802](https://news.ycombinator.com/item?id=15106802)

------
pritambarhate
I really want a nice OO language with Garbage Collector / ARC that compiles to
native code on Windows, Mac and Linux. Swift is good, but Windows story is
weak.

I am personally waiting for Kotlin Native to mature. Until that time Go it is.

~~~
shakna
Red [0] has a fantastic cross-compilation story, is a tiny compiler, and is a
kind of Lispy version of Object-Oriented. Includes GUI support in the native
runtime. It's meant to be a sort of "better Rebol".

[0] [http://www.red-lang.org/p/getting-started.html](http://www.red-
lang.org/p/getting-started.html)

~~~
Shoothe
Red (and Rebol) are fantastic but unfortunately the learning curve is very
steep for people that don't know it. I spent a month reading everything on the
internet about Rebol, then Red was obvious but before that it's really hard to
get into that world. IMHO Red should have something like a definitive book
covering all aspects in one place (like [0]) because it has a vast array
powerful features (URI, money, time literals, parse and other dialects) etc.
Without concise but a complete guide the language appears to be just a weird
"let's use [ ] instead of { }" construct.

[0]:
[http://shop.oreilly.com/product/0636920040385.do](http://shop.oreilly.com/product/0636920040385.do)

~~~
k__
how can it have a learning curve for people already know it?

~~~
Shoothe
Because "already know it" is not a single defined point on that curve but
rather a region. It's easy to prove by negative, if "already know X" would be
so easy to pinpoint the entire recruiting industry would cease to exist.

------
skocznymroczny
Does it support Windows yet?

~~~
sdogruyol
Windows support is still WIP, recently we are making some good progress
[https://github.com/crystal-
lang/crystal/pull/5339](https://github.com/crystal-lang/crystal/pull/5339)

------
isaiahg
Ruby like syntax huh. Man I wish the Python syntax would catch on more. Most
clean and readable code I've ever laid my eyes on. Wish I could use it but
it's just too slow for the stuff I do. What would I give for a language at
least the speed Java but with a Python like syntax.

~~~
isaiahg
\+ and strongly typed.

~~~
_raul
Nim is the closest language to what you're describing that I've found so far
[https://nim-lang.org/](https://nim-lang.org/)

~~~
arc776
Definitely fits the bill:

* Python-like syntax

* Compiles to C/C++/JS/Object-C

* Supports Windows, Linux and Mac.

* Multithreading

* Extensive metaprogramming

* VERY fast compiler

* Dead code elimination

* Very strongly typed, with related features (eg distinct types)

* Type inference

* Excellent structural generics, type classes, and compile-time concepts

Basically looks like python, runs like C. Because it compiles to C, you can
run it anywhere you have a C compiler (which is almost anywhere).

------
cyber1
Nice language. Is someone use it in production?

~~~
sdogruyol
We have a dedicated wiki page for Crystal production users :)
[https://github.com/crystal-lang/crystal/wiki/Used-in-
product...](https://github.com/crystal-lang/crystal/wiki/Used-in-production)

------
didibus
I don't know why, but off all languages I've tried, Ruby's syntax I just hate.
I can't do it, dunno why. That's what turns me off of crystal also.

~~~
izietto
I guess you are a Java enthusiast (in my experience Java coders just tilt with
Ruby). Anyway you should try Elixir, it is Ruby "The right way" in my opinion.

~~~
dudul
Please let's stop spreading this "elixir is like fast/better ruby". The syntax
is not even that similar, and the runtime is completely different, the
patterns and tools available not the same at all.

I know it's probably a hill on which I'm gonna die and get a lot of downvotes,
but we should really try to not force Elixir into being a new, fast ruby and
let it evolve and solve problems in its own ways.

~~~
regulation_d
"elixir is like fast/better ruby" is simplistic but it's also not entirely
untrue. When I first started playing with Phoenix I found it palpably similar
to Rails, but also faster and better in a lot of ways, especially the
WebSockets story.

When I started writing Elixir I didn't know how great it was nor did I
understand how different it was from Ruby. The BEAM is a challenging thing to
grok. As I used it more and more, I did learn and appreciate those things. But
at no point, did I feel deceived about how similar Elixir and Ruby were
supposed to have been. I was surprised and relieved by how many of the things
I had to worry about in Ruby, I didn't have to worry about in Elixir.

At the end of the day, Elixir's similarity to Ruby is part of what gets a lot
of people like me in the door. It's a hook and I think it's a good one. I
mean, sure, we're going to have to explain to people why they don't need
something like Sidekiq, and we're going to do it many, many times. But that's
what we do as a welcoming community.

I guess it's a balance. If we have a lot of people trying out Elixir and
leaving because they feel they were misinformed, that's definitely relevant.
But I don't hear much of that. On the other hand, if we can use this
similarity to get OO people to try out this crazy, awesome FP language that
uses the actor model, that could really help grow the language.

You're on point that Elixir really is a completely different paradigm, but I
don't know if I agree that it really matters from a marketing perspective,
particularly when marketing to Rubyists.

~~~
nicoburns
> when I first started playing with Phoenix I found it palpably similar to
> Rails, but also faster and better in a lot of ways, especially the
> WebSockets story.

Thing is virtually every language that is used for webdev has a framework that
is similar to rails. So that's not much of a discriminatory when comparing
languages...

~~~
regulation_d
The number of languages that do WebSockets well include what would be a small
subset of "virtually every language that is used for webdev [sic] has a
framework that is similar to rails".

But that wasn't really the point of the comment. The point, for those who
didn't feel the need to read all the way through, is that Elixir's surface
level similarity to Ruby is enough to make Rubyists, or at least this Rubyist,
feel reasonably comfortable, reasonably quickly. Making the Elixir/Ruby
comparisons may have some annoying side effects, but they're probably good for
the growth of the language.

------
nnq
> In Crystal, as in Ruby, everything is an object. [...] When you write
> Crystal code, most of the time, you write classes.

Why, God, why?! Really, OOP is a great way of structuring lots of types of
code (not all!). But I don't think it really helps anyone to treat everything
as an object. Some _things_ are not _objects_ they just are whatever they are.
A _function_ is just that, a _function_. If I have to call a `.call` method on
a "function" as in ruby, then that's simply not a function anymore. And... _it
's not an object either semantically,_ because objects are about things that
can receive and send multiple messages and sometimes encapsulate state... and
that's not how _anyone_ thinks about _functions!_

By making _everything_ be an object, you actually f up the concept of "object"
itself...

I like Ruby's elegance, but every time I see the "OOP at the core" part, I
suddenly get more love for Python and Javascript for at least getting this
right.

~~~
joaodlf
I have never used Crystal before, but I don't understand how you can be
against "everything is an object" and then say Python and Javascript are
different... Pretty much everything in Python and JS is an object... So
really, what does fundamentally differ?

~~~
Shoothe
> Pretty much everything in (...) JS is an object

Except primitives that are not objects but (some) can be autoboxed to behave
like objects.

A riddle:

    
    
      var a = 2;
      a.b = 3;
      console.log(a.b);

