
Crystal 0.24.1 released - wulfklaue
https://github.com/crystal-lang/crystal/releases/tag/v0.24.1
======
skrebbel
I really like initiatives like Crystal and Nim, in that they appeal to users
of popular languages like Ruby and Python yet are much faster.

But I fear that the problem they solve isn't big enough. For desktop/mobile
apps, they need a UI framework so I suppose they're targeted at web or
network/system programming mostly. However, "Faster Ruby" or "Faster Python"
is, in practice, solved by faster hardware as well. At the same time, for web
apps to truly scale you need more than just a constant factor increase in
speed - you need to handle parallelism better. This is what Go and
Erlang/Elixir do with green threads, or Rust with its borrow checker.

This is why I've been surprised that a well thought out and polished
initiative like Crystal doesn't do anything in this area, and makes me fear
that its popularity might not last. Nim was all over HN a few years ago and
now not seen that much anymore - Crystal is obviously different from Nim but
they tackle many of the same problems in similar enough ways.

I fear/hope that, because of this, languages like Pony[0] will stick around
longer - it seems to combine the best ideas from Crystal, Erlang and Rust in
an ergonomic way.

[0] [https://playground.ponylang.org/](https://playground.ponylang.org/)

~~~
dom96
Disclaimer: I'm a core Nim dev.

To be honest I am unsure what Pony provides that Nim doesn't. Perhaps I just
haven't looked closely enough at it.

One thing I do know is that from my years of using Nim I never had any trouble
with parallelism. There are no green threads, but there is a solid thread pool
implementation[1] and a mechanism that ensures memory isn't shared between
threads without a lock or a channel (GC safety)[2].

Maybe you could give me a TL;DR of what Pony does better? :)

1 - [https://nim-lang.org/docs/threadpool.html](https://nim-
lang.org/docs/threadpool.html)

2 - [https://nim-lang.org/docs/manual.html#threads-gc-safety](https://nim-
lang.org/docs/manual.html#threads-gc-safety)

~~~
jitl
Pony has an Actor as a language-level concept, which significantly reduces the
amount of “thinking about mechanism” that a programmer needs to do to build
safe, highly-concurrent programs.

Quick read:
[https://tutorial.ponylang.org/types/actors.html](https://tutorial.ponylang.org/types/actors.html)

I think one could implement a similar system in Nim using the primitives that
you posted, plus some kind of channel, but:

1\. Such a system is not included in the standard library (?)

2\. Even if a package containing such a system outside the stdlib were
available, it would not receive the same application and usage by the Nim
community, as Pony actors will in the Pony community

3\. So, Pony is better suited to foster a community for highly concurrent
programming

~~~
djsumdog
Does an actor system need to be part of the language? In the Scala world,
there's the akka library to provide actors (but of course you could use a
totally different actor system instead). Alternatively in Elixir, actors
(Processes) with their send/receive functionality is built into the language
and each module can essentially be an actor.

I guess the trade off is that if it's a part of the language, you get it
standard and built in as a language construct. But if it's in an external
library, you can use different actor systems and benchmark them accordingly.

~~~
abiox
one benefit is that you can effectively embed the concept directly into the
type system, allowing for ergonomic expression of actor model code. i'm not
sure to what extent pony does this, though i believe it's capability typing
was designed with actors in mind.

------
samuell
Crystal stacks up pretty nicely in our crowd-sourced feature table, for
statically compiled languages:

[https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n...](https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__nzbCSFnnHicWrjxpW5l6-O3w/edit#gid=0)

... providing light-weight threads, and possibly going to support M:N
coroutine:thread multiplexing(?). Let's hope.

------
drallison
Crystal is a programming language. [https://crystal-
lang.org/](https://crystal-lang.org/) Crystal’s syntax is heavily inspired by
Ruby’s, so it feels natural to read and easy to write, and has the added
benefit of a lower learning curve for experienced Ruby devs.

------
nws
I feel like Crystal has been alpha for 4 years.

~~~
deedubaya
That may be, but it's really quite stable for pre-1.0. I have Crystal apps
running in production without problems and great success. I'd say, in some
scenarios, Crystal is more stable in alpha than some post-alpha language
releases I've worked with in the past.

------
paulscoder
I think Crystal follows the Ruby path too tightly. Ruby also never found its
place in the UI framework world. The popularity of web apps during the rise of
current rich interfaces and the boom of SaaS consumer products didn't give
Ruby and reason for its contributor base to expand successfully. Times have
changed again and we are back to being interested in standalone apps. I really
like Crystal and hope some of the UI focused community from Rust will bleed
over.

------
ricardobeat
Great to see progress, and exciting news on the possibility of swapping the
GC. Thank you to all maintainers and contributors, here's to a big multi-
threaded 2018! :)

