
Crystal: Fast as C, Slick as Ruby - yranadive
https://blog.codeship.com/an-introduction-to-crystal-fast-as-c-slick-as-ruby/
======
anp
From this post, Crystal appears to have some of the things many people have
been lusting after in Rust: sophisticated metaprogramming, fewer sigils, a
bigger standard library, fibers/coroutines/whatever-they're-called-now.

But it still has a GC :(. Rust has completely spoiled me with making it easy
to minimize dynamic memory allocation and copies, and to know (almost always)
deterministically when something will go away.

EDIT: I should also say that if you want to bash on Rust's lack of these
things, 3 out of the 4 items I cited have solutions being actively worked on
(either at planning, RFC, or implementation phase). I don't think Rust's
sigils are going away any time soon, but I have no idea how you'd do that and
preserve semantics anyway.

~~~
thinkpad20
Manual or deterministic memory management might be a must-have for certain
usage domains, but for any domain in which one would be using ruby, this seems
unlikely, and presumably one could FFI into C when this is the case. There are
hardly any languages commonly used in industry which don't have GC
(essentially just C/C++). And many of these garbage-collected languages are
capable of blazingly fast code with a small memory footprint.

Regardless, for a language which is meant to operate in the same domain as
ruby and be as easy and declarative, not having a GC would be a puzzling
decision.

As a side note, I'm curious what areas you are programming in where the
presence of a GC is such a downside. Having written almost exclusively in
garbage-collected languages over the last few years, it's something I almost
never think about (and happy not to). Of course I don't deny that stricter
memory control is sometimes necessary.

~~~
fauigerzigerk
Crystal seems to be targeted at a domain where ruby is not fast enough. That
includes domains where GC is a problem.

A tracing GC means that you either have to deal with potentially long GC
pauses or you need a lot of extra free memory at all times to give the GC time
to catch up before running out of memory [1].

Go says it can achieve 10ms max pause time using 20% of your CPU cores
provided you give it 100% extra memory. In other words, memory utilisation
must be kept below 50%.

Cloud/VPS prices scale roughly linearily with memory usage. So using a tracing
GC doubles your hardeware costs. Whether or not that is cheap depends entirely
on what share of your costs is hardware cost and how much productivity gain
you expect from using a tracing GC.

I would be very interested in learning how much CPU and memory overhead
Swift's reference counting has, because in terms of productivity Swift is
certainly competitive compared to languages using a tracing GC.

[1] Azul can do pauseless, but I don't know exactly what tradeoffs their
approach makes. Their price is too high for me to even care.

~~~
Taek
If you are on a server do you need 10ms max pause time? For most applications
running go on a remote machine, 25ms should be in the realm of acceptable.

~~~
sitkack
[http://latencytipoftheday.blogspot.com/2014/06/latencytipoft...](http://latencytipoftheday.blogspot.com/2014/06/latencytipoftheday-
most-page-loads.html)

------
Athas
The claim is "fast as C", so I was surprised that the performance comparison
was with Ruby, not with C. On my machine, the Ruby Fibonacci program executes
in 47.5s, while a corresponding C program executes in 0.88s - that's a factor
54 difference, while the article reports a factor 35 for Crystal. That's good,
but what causes the difference? This benchmark is pretty much all function
call overhead, so I doubt it's representative of real performance-sensitive
code.

The Crystal website itself makes a more modest claim than "fast as C" under
its language goals: "Compile to efficient native code", which it clearly does.

~~~
bluetomcat
All of these "fast as C" claims about modern, high-level Python-like languages
(be they statically typed and natively compiled) are missing the point. It is
mostly the minimalistic and terse programming style that C encourages that
makes C programs performant. You avoid allocations wherever possible, you
write your own custom allocators and memory pools for frequently allocated
objects, you avoid copying stuff as much as possible. You craft your own data
structures suited for the problem at hand, rather than using the standard "one
size fits all" ones. Compare that to the "new this, new that" style of
programming that's prevalent today.

~~~
progman
There actually is one high-level Python-like language that really is almost
"as fast as C".

[http://nim-lang.org](http://nim-lang.org)

I am using it for years already, and it is really performant, somewhere
between C and Rust. I am still wondering why so few people use it.

Benchmark:
[https://github.com/kostya/benchmarks](https://github.com/kostya/benchmarks)

Nim vs Rust: [http://arthurtw.github.io/2015/01/12/quick-comparison-nim-
vs...](http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs-rust.html)

Performance discussion: [http://forum.nim-lang.org/t/2261](http://forum.nim-
lang.org/t/2261)

Embedded Nim: [https://hookrace.net/blog/nim-binary-
size/](https://hookrace.net/blog/nim-binary-size/)

Nim on LLVM:
[https://github.com/arnetheduck/nlvm](https://github.com/arnetheduck/nlvm)

~~~
def-
> I am still wondering why so few people use it.

While Nim is my favorite language, I can understand that it has a small
userbase, for these reasons:

1\. No major backer like Google for Go or Mozilla for Rust

2\. No killer feature like "memory safety and performance without GC" for
Rust, instead a mix of all the reasonable down-to-earth features I want in a
programming language

3\. Some unique decisions instead of what you're used to from other languages,
for example partial case sensitivity

~~~
valarauca1
4\. The fact that operator order is changed by the amount of white space
between symbols

    
    
                    2+2 * 5 = 20
                    2 + 2 * 5 = 12

~~~
progman
I am a strong proponent of Nim but this is probably the worst idea I have ever
encountered in language development. Honestly!

Partial case sensitivity and the special underscore case are features I can
live with. Unfortunately this has actually become a stumbling block for a
wider adoption of Nim.

All strange special features should be optional, not default.

~~~
dom96
What makes you think this is default? It most certainly is not and will be
removed completely in the future.

Edit: here is a source: [http://nim-lang.org/docs/manual.html#syntax-strong-
spaces](http://nim-lang.org/docs/manual.html#syntax-strong-spaces) ("... if
the experimental parser directive #?strongSpaces is used..."). The last time
this was discussed I said that it would be removed completely, and I still
believe it will be. It's simply not a priority for us right now.

~~~
progman
> What makes you think this is default?

Some of those features are default in Nim, some (strongspaces) are not. I say
that _all_ such weird features should be optional in general so that newcomers
don't get scared off.

Also case and underscore should work like in C per default since Nim
interoperates with C seamlessly anyway. Case insensitivity and ignoring
underscore are ok if optional.

------
clessg
Looks very nice. I hope it gains momentum.

For now, if you want a fast language with the beauty and productivity of Ruby,
check out Elixir [0] and its web framework, Phoenix [1]. I've been using
Phoenix for a year, and it's the first framework that I've actually liked
_more_ over time. And I've been a web developer for a decade. With its recent
1.0 release, Phoenix is gaining a lot of momentum.

If you want some idea of the performance differences between Phoenix and
Rails, see [2] and [3].

[0] [http://elixir-lang.org/](http://elixir-lang.org/)

[1] [http://www.phoenixframework.org/](http://www.phoenixframework.org/)

[2] [https://github.com/mroth/phoenix-
showdown/blob/master/RESULT...](https://github.com/mroth/phoenix-
showdown/blob/master/RESULTS_v3.md)

[3] [http://www.phoenixframework.org/blog/the-road-
to-2-million-w...](http://www.phoenixframework.org/blog/the-road-to-2-million-
websocket-connections)

~~~
acangiano
Elixir is not a fast language. Not even close. Yes, it handles concurrency and
parallelism beautifully which in turn enable distributed applications to
perform quite well. But the language itself is significantly slower than
Crystal / Rust / Go / Swift. It's not in the same category at all.

That said, it's a great language worth recommending.

~~~
rdtsc
> Elixir is not a fast language.

Depends what we mean by fast. I have seen Erlang VM handle 100k requests per
second on a distributed cluster. That's plenty fast. Moreover, because of
fault tolerance, it means ability to have a better uptime, with less people
on-call. "Fast" can also be measured to include that, if system goes 200k
requests per second, but crashes at midnight and stays down for a few hours,
the average "speed" can be quite low. In a laptop demo that's not visible, but
in practice that's money and customers lost.

But if fast means, "let's multiple some matrices", then yeah can probably use
Rust or C for that. It all depends on the problem domain.

~~~
Scarbutt
_I have seen Erlang VM handle 100k requests per second on a distributed
cluster_

A single JVM server can do that load, scaling and providing fault tolerance
for a server that just accepts requests is trivial these days, also, if your
requests do computationally intensive stuff you are going to have a very bad
time with Erlang.

 _It all depends on the problem domain._

Exactly, and the domain for Elixir/Erlang is way more niche and specialized
than applicable domains of other languages.

I don't have anything against Elixir but part of its crowd just advertises it
as the best thing for everything.

~~~
ken47
The Erlang VM (modified) has supported over 2M concurrent connections:
[https://blog.whatsapp.com/196/1-million-is-
so-2011](https://blog.whatsapp.com/196/1-million-is-so-2011)?

Furthermore, assuming each request is mapped to an Erlang process, each of
them get their own VM -- no stop-the-world.

~~~
ken47
Correction: I meant to say each of them get their own GC, not VM.

------
Svenskunganka
I'd like to put out there that Crystal is absolutely awesome. The language
itself is Crystal clear, but the language documentation and API documentation
- oh my!

I had never worked with compiled languages before I tried Crystal, but had
always had a huge interest in getting into that. When I wanted to learn the
compiled ecosystem I looked at languages like Go and Rust, but the learning
curve for those was a bit overwhelming for a newbie. A while later I found
Crystal, and much thanks to the simple syntax of the language I learned a ton
of new things about compiled languages very quickly. The absolutely best part
of the language is that it is written in plain Crystal, and I've been looking
at their own implementations for various things a lot - something I've never
done before, having worked mostly with Node, Lua and PHP before.

Nowadays I can delve into Go documentation, packages are clear to me and I
just understand how things should and should not be implemented to achieve a
good efficiency and performance level. The Little Go Book makes sense, the I/O
package is simple and this is probably all thanks to the syntax of Crystal,
the amazing language & standard library documentation but most importantly the
source of Crystal being written in Crystal.

I'm currently working on building a business using Go, because I absolutely
need Windows target support - something which Crystal does not yet have. But
the second it gets that, I'm moving back. Don't get me wrong, Go is really
great and nice to work with - but Crystal is my mentor. Please note that I
have not worked with Ruby before, so the whole language was new to me.

To summarize; even if you only wish to learn, Crystal is in my personal
opinion the best choice to go with.

~~~
kristianp
Maybe the makers of Crystal need to take a leaf out of Go's book. Despite the
Go creators not being windows users (AFAIK), they support Windows as a primary
target, to help adoption, I assume.

Of course the Crystal people probably don't have the same number of developers
working on it as Go did even early on.

Edit: Go took a little while to support windows, not until around July 2010.
See this question from November 2009:
[http://stackoverflow.com/questions/1717652/can-go-
compiler-b...](http://stackoverflow.com/questions/1717652/can-go-compiler-be-
installed-on-windows)

~~~
RX14
The plan is to support windows before 1.0, although the core devs are
reluctant to "open up" to the large amount of developers windows support would
bring before they are finished making breaking changes.

~~~
rogerdpack
I don't think they're afraid of it, more like haven't gotten around to it
would be my guess...

------
boyter
The Fibonacci comparison is a poor example of performance gains because Ruby
is using large number data types to ensure the correct result. This is
according to the crystal language website itself.

"However, Crystal might give incorrect results, while Ruby makes sure to
always give the correct result."

[https://crystal-lang.org/2016/07/15/fibonacci-
benchmark.html](https://crystal-lang.org/2016/07/15/fibonacci-benchmark.html)

~~~
coltonv
i actually think it's a good example for just that reason. Ruby will
automatically use those big number types on production applications as well as
the fibonacci application, so it's demonstrating that difference and the
effect that it has.

~~~
djur
This isn't true. Ruby uses native integers when possible and then switches to
bignums when the integer gets big enough.

~~~
coltonv
Yeah and that behavior of automatically switching has overhead, and should be
taken into account when comparing languages.

------
willlll
I recently gave a quick 10 minute talk on Crystal if anyone wants a video
introduction
[https://www.youtube.com/watch?v=oC9IknG40po](https://www.youtube.com/watch?v=oC9IknG40po)

~~~
mokkol
Thanks! Interesting talk!

------
erez
First thing I look for whenever I run across another "C competitor" is to look
which language it is implemented in. Usually that's C, or C++, but this time,
it does look like Crystal is implemented in Crystal, which is, to me, a very
good indication that this is a "real" system language.

I believe Rust is also implemented in Rust and Go, after a few years of being
implemented in C has now a compiler written in Go.

~~~
ethagnawl
> ... which is, to me, a very good indication that this is a "real" system
> language.

Could you expound upon that point a bit? What's the difference, in your mind?

~~~
erez
The rationale is, that once you have a programming language that is
implemented in itself (usually that means that the compiler/interpreter is
written in that language), then it means that your language has tackled and
can deal with many issues that "system languages" deal with. Mainly dealing
with the OS in a lower level, dealing with CPU/RAM, etc.

This is a large problem space that you can glean over by using C as a layer of
interaction between your language and the underlying machine, but it makes
your language a: not truly a "system language" and b: it also ties you to C
philosophy, API/ABI, calling conventions and so on.

------
transfire
I've done some coding Crystal when I have Ruby scripts I really need to run
faster. I generally see about a 5x performance over Ruby.

It certainly is great to be able to jump right into Crystal coming from Ruby.
It isn't very hard to convert most Ruby code to Crystal -- you just have to go
through and "typify" everything. A few methods have different names and of
course some don't exist but most of it is there.

My one grip with Crystal however, and why I haven't adopted it more generally,
is that much of the "Lisp-like" features of Ruby are all but lost. Crystal
makes up for some of this with macros, but it doesn't quite cut it. For
example, you can't splat an array into a lambda in Crystal. Arguments have to
be tuples which are compile-time bound. Little things like this feel very
limiting to an experienced Ruby developer.

~~~
yxhuvud
You may want to revisit that splat issue. Asterite did some changes regarding
splats a few months back that was pretty impressive.

~~~
transfire
Cool. I'll have to see if I can get my Clik library working now. Thanks.

------
mshenfield
Crystal doesn't support a REPL yet because inferred static typing complicates
incremental compilation.

Blog: [https://crystal-lang.org/2014/12/06/another-
language.html](https://crystal-lang.org/2014/12/06/another-language.html)
Github Issue: [https://github.com/crystal-
lang/crystal/issues/681](https://github.com/crystal-lang/crystal/issues/681)

~~~
twblalock
Scala has type inference with strong static typing, and a useful REPL. A
Crystal REPL should be doable, unless Crystal's creators made some bad choices
in the design of the type system that Scala's creators did not.

~~~
mshenfield
My intuition is also that a Crystal REPL is technically possible. But FTR, the
two languages implement subtly different type restrictions.

Scala has type _inference_ , Crystal has _optional_ typing. In Scala, there
are certain situations when the type is discernible by the compiler, and can
be omitted. For example

    
    
      val x = 1 + 2 + 3
    

the compiler infers that x is an Integer. However, omitting type information
in Scala is the exception not the rule. Methods and functions, for example,
must have type annotations.

In practice, Crystal also infers type. But in Crystal you can omit almost any
type annotation, including method and function definition. This probably poses
a different challenge for the compiler authors. The Type Restrictions sections
provides some more examples [https://crystal-
lang.org/docs/syntax_and_semantics/type_rest...](https://crystal-
lang.org/docs/syntax_and_semantics/type_restrictions.html)

------
westoque
Was wondering how many companies actually use Crystal in production.

I was interested in Crystal but the lack of apps using it in production and
proof of concept on the field is making me doubt its usefulness.

~~~
sdogruyol
I'm the author of Kemal(kemalcr.com), a simple, fast and modern web framework
for Crystal.

We've been using Crystal in production(at Protel) for more than 6 months for
some heavy load APIs (100-200 req/s). We've replaced our Rails API with 64
unicorns to just 1 Kemal process and it's not even breaking any sweat while
consuming nearly 100x less resource and 30x less CPU.

You can ask me about our experience.

~~~
coltonv
My biggest concern if i were to try to use Crystal in production would be the
lack of "googleability". I'm guessing your team is very familiar with the
language, so it's not as much of a problem that you can't Google a problem
when it happens. Do you feel that this is a major roadblock for people new to
crystal, or are the majority of errors very intuitive? the second thing is
that according to the site crystal is in alpha and making breaking changes
sometimes. how often do you have to refactor after an update and how difficult
has it been to spot and fix that something is broken by an upgrade? Very
interested in using it myself but can't bring myself to commit an app to it.

~~~
ricardobeat
Chiming in re. "googleability", go has the same problem (despite coming from
Google :D). What you do is always search for 'crystal lang xxx'. It will get
better as adoption increases.

~~~
coltonv
I was more just talking about how as language popularity goes up so does your
likelihood of finding the solution to any given problem on the internet.

------
gtramont
And it already got a port of Sidekiq:
[https://github.com/mperham/sidekiq.cr](https://github.com/mperham/sidekiq.cr)

~~~
jboggan
Whaaat? That's awesome. Now I want to see how Crystal handles ETL pipelines.

~~~
bdcravens
I've found the bottleneck to be the database choking on too many INSERTs, not
the code doing the writes (our Sidekiq job)

------
sdogruyol
For anyone interested in building web applications with Crystal i recently
gave a talk about Kemal at PolyConf [https://www.youtube.com/watch?v=KJB-
nAoRSr8](https://www.youtube.com/watch?v=KJB-nAoRSr8)

------
z3t4
scoped includes are a deal breaker for me when looking at new programming
languages.

ex: non-scoped (everything in foo is added to the global scope)

    
    
      inport foo
      {
        bar.do()
      }
    

ex: scoped (everything in foo is added to the local scope, and assigned a
name-space)

    
    
      {
        bar = inport foo
        bar.do()
      }
      
    

I find it much easier to manage programs where there are no "hidden" global
variables. It's especially hard when the included files also can include
files, witch all adds to the global scope.

~~~
rogerdpack
bring it up on the mailing list, seems like an interesting feature to me :)

------
AstroChimpHam
So, this is like Ruby's answer to cython?

~~~
yxhuvud
No, not in any way whatsoever.

~~~
AstroChimpHam
Cython looks like typed Python. Crystal looks like typed Ruby. Both are
compiled, and both are not quite as fast as C, but much faster than the
language they're based off of. The point of both is to be able to write
something that looks like a clean scripting language while getting close to
the speed of C. Was that unclear, or are you just trolling?

------
jheriko
cool.

can you make it faster than C though please? (seriously) i think it might even
happen by accident in some cases already though. the places where C can be
beaten for performance are, in my experience, from design choices in the C
standards, users not understanding or leveraging those things for performance
and the architecture of the compilation-unit/link process.

things like the struct layout rules - instead of the compiler organising
things to be optimal it follows those rules for memory layout, or the calling
conventions - you often have to use funky extensions to get efficient function
calls.

other things are the lack of ability to hint the compiler that e.g.
mathematical structures underly types that can be leveraged for optimisation.
that const or functional purity can be trusted... etc.

~~~
jbbarth
Not the answer you would expect but still: it can also happen on large
projects where the refactoring or the paradigm change is just too costly in C.
The pure, raw ability to make C faster is nice, but if it takes you months of
development you don't have, it's pretty useless.

One typical example of this was a few years ago (if I'm not mistaken) in the
monitoring world, when Shinken released a Nagios-compatible engine in Python,
and, basically the reactions in the Nagios community was that the
modifications involved in Nagios (C) were just too important to be worth it.

------
api
Why couldn't Swift be this?

~~~
jimbokun
In other words, if Apple had taken the RubyMotion path, but added type
inference and better performance.

------
catnaroek
The really important questions in any modern language:

(0) Does Crystal have a lot of undefined behavior like C?

(1) Does understanding Crystal programs require a lot of trial and error just
like in Ruby?

(2) How good a job does Crystal do at preventing me from shooting myself in
the foot?

A language isn't to be judged just by the amazing programs you can write in
it. (Turing-completeness and I/O facilities have that covered.) Far more
important are the totally stupid programs that you _can 't_ write in it.

~~~
pw
I'd love for you to elaborate on (2). I don't think that's a criticism of Ruby
I've heard before.

~~~
catnaroek
(2) wasn't particularly aimed at Ruby, although some “creative” uses of
metaprogramming can be very hard to debug. But languages designed for systems
programming typically have features that, when used wrong, result in totally
catastrophic modes of failure.

~~~
yxhuvud
Well, you don't have runtime eval or send in Crystal, so some variants of
metaprogramming can be ruled out.

However, there _are_ compile time versions of method_missing, delegates and
instance_exec available (usually with slightly different naming due to not
having the exact same semantics as the ruby counterparts), so it is still
possible to do some magic.

------
smallbag
Can someone comments the differences between Nim (old mimrod) and Crystal?
Which one do you prefer and why. Thanks.

~~~
costajob
Apart for different syntax:

Plus of NIM:

* powerful compiler can produce C, C++, JS, ObjectiveC code

* GC can be completely removed to adapt to the program

* support parallelism via threading

Plus of Crystal:

* use of types union permit to mix types in almost every data structure, let you pondering if the langugae is really strong typed

* so similar to Ruby that porting a 100-lines library (with no fancy-metaprogramming) to Crystal is often a matter of few hours

* use of green threads suits very nicely with HTTP request/response cycle (like GO and Erlang), where using threads/processes is more memory/CPU consuming

What Crystal still lacks is parallelism, but core team are working on that.

Said that both are modern, fast, elegant languages, with a good standard
library and a vibrant community.

------
continuational
I think the macro system looks really interesting. The main ideas seem to be
that meta programming can be done anywhere and that everything is quoted by
default in macros. What are thes kind of macros called, and where do they come
from?

------
kimshibal
crystal on rails. i want this.

~~~
_raul
This may be the closest alternative right now:
[https://github.com/ysbaddaden/frost](https://github.com/ysbaddaden/frost)

~~~
fuzzythinker
Kemal is the most actively developed.
[https://github.com/sdogruyol/kemal](https://github.com/sdogruyol/kemal)

------
jalopy
Great stuff. I love Ruby. Any idea when this will be production worthy, or at
least stable enough to trust on internal projects? Will the language change
much going forward?

~~~
sdogruyol
Actually it's been stable for the last 6 months. No more expected major syntax
e.g changes upwards. (apart from parallelism and gc which will be at compiler)

~~~
coltonv
They should really mention that on the website for crystal. I think a lot of
people are scared off by seeing the words alpha and breaking changes. Changing
those to "beta" and "stable" on the site would help a lot IMO. At the very
least calling it stable would be huge.

------
happywolf
What advantages Crystal has compared to other more modern languages that aim
to compete with C? For example D and Rust.

~~~
erelde
Its similarity with Ruby? It doesn't _feel_ like I would have to learn
completely new paradigms

~~~
wmoxam
It's somewhat similar, but in Crystal you need to be explicit with types, and
you'll likely miss 'send'.

Also Crystal has macros

------
VT_Drew
Neat, I will check this out. Although, if I am honest I really wish there was
"Crystal for python".

~~~
binki89
Nim ([http://nim-lang.org/](http://nim-lang.org/)) is really as close as
you're going to find.

------
ksec
For anyone familiar with Crystal, are there any plan to add pattern matching
into Crystal?

~~~
binki89
Good question about pattern matching in Crystal. I found this reply by
asterite (the creator of Crystal) to a similar question that is worth reading:

[https://crystal-
lang.org/2014/06/19/crystal-0.1.0-released.h...](https://crystal-
lang.org/2014/06/19/crystal-0.1.0-released.html)

The question was asked in the comments as with the reply. I'm sorry that I
can't link to it directly but it's the seventh comment from the top.

------
wtbob
> Have you ever dreamed of a programming language as beautiful as Ruby but as
> fast as C?

Yeah, I discovered Common Lisp back in 2006 and have been using it ever since
…

I discovered Go back in 2009 and have been using it ever since, too.

What does Crystal get me that these two don't?

~~~
rogerdpack
ruby like syntax that I miss when using go :|

------
kusmi
Does it have any benefit in particular over lua/luaJIT?

~~~
untothebreach
off the top of my head, I would say it's similarity to Ruby means that Ruby
devs would have an easier time learning the language than learning an entirely
new one. Crystal also seems to have an extensive standard lib, which lua does
not. (that's not a criticism of lua, just an observation. I know luarocks has
made the lack of a large stdlib much less of a pain point for lua)

------
ksec
Someday, someone should write a Ruby VM in Crystal.

------
libman
Crystal isn't fit to carry Nim's jockstrap as far as I'm concerned. Ruby's
syntax is verbose and illogical compared to Python's. Plus Crystal has a much
more restrictive license.

------
welder
Stopped reading when I saw the `end` keyword... the most annoying part of
Ruby.

Edit: I'm getting hella downvoted but I'm leaving this here. Ruby fanboys
can't silence me!!! ;)

~~~
exDM69
The syntax of a language is about the least interesting thing about them. I
don't care about curly braces, end keywords or semicolons as long as it is
consistent (and fairly easy to parse, so there can be good tooling). The
interesting parts are in the semantics, type systems and runtime features.

Choosing a programming language based on the syntax is like choosing your
significant other based on looks alone. You're going to be spending a lot of
time together, what's inside is what counts.

~~~
paxcoder
I've heard this said numerous times, so I'm going to disagree on the record. I
think syntax of a programming language is a very important characteristic.

A language with a nice syntax is easier to learn, easier to read and
understand, and delightful to write.

Crystal's syntax is a great differentiator between it and its statically
typed, garbage-collecting competition.

~~~
welder
Exactly! I guess people used to the Ruby syntax are just desensitized or don't
know how much of a joy programming can be without having to type 'end'
everywhere.

~~~
exDM69
The end keywords is just a minor detail and can be inserted by a smart editor
anyway.

Things like list comprehensions and do notation are examples of nice syntactic
sugar.

Sensitive whitespace like Python can be nice to write and read, but it's
hard(er) to write a parser for it and that's why Python's tooling hasn't been
great in the past.

That said, Ruby is even harder to parse and I don't like it aesthetically
either.

------
jhoechtl
I seldom whine about blog posts but his one clearly justifies as click-bait.
Not because of it's otherwise good content. But if it takes me a Google search
instead of having within the very first sentences a link to the obvious
target,

[https://crystal-lang.org/](https://crystal-lang.org/)

there is something f~*#ing wrong with the article.

------
quotemstr
If you require the use of a GC, you can never be as "fast as C" in the general
case, since there will always be specific cases where manual memory management
will do something more efficient than what an automatic GC would have done ---
just like a car with an automatic transmission can never be quite as efficient
as a car with a manual transmission used competently.

If you want to talk about efficient GCed languages, you have many choices,
most of which have more tooling and mindshare advantages than you language has
tooling advantages.

Really, GCed languages are commodities these days. A lot of people have put a
lot of work into the fundamental building blocks, and now people are just
combining them in various ways.

