
The future of the Crystal language - cylo
http://crystal-lang.org/2015/12/24/the-future-of-crystal.html?hn
======
0xFFC
I don't know it is only me or its apply to others too, My own field is OS and
I love it. But recently I am literally fascinated by whats going on in
"Programming Language" field. Rust, Go, Nim, Julia, Haskell, Ocaml, Racket,
Clojure etc (though these are not scientific research in PL community, but we
can claim these are mostly result of scientific research). I wasn't aware of
crystal . I literally Love them all and if I were going to an abandoned island
for rest of my life , my only wish would have been : "let me play with all of
these for rest of my life"

BTW : I looked at crystal syntax (I am talking about only syntax). Syntax
designed extremely clear. I would say (my opinion, in short time I had to
investigate crystal) maybe clear'er that python.

------
vinceguidry
The real reason they couldn't find anything when Googling the language in the
future is because of the inconvenient naming. Every time I search for Crystal,
I have to pick out the results from SAP Crystal Reports.

I wish more people took this aspect of their projects seriously. You don't
need a short domain name, but your project does at least need to be Googlable.

~~~
arnvald
It's the same with other languages as well: Go, Julia, Ruby (when I searched
for some "Ruby Bangkok" meetups, I found thousands of offers to buy real
rubies in Thailand. Same with frameworks: Phoenix, Sinatra, Iron, Gin.

After some time Google learns and shows you relevant results, but if you use
Startpage or DuckDuckGo, you have to add "lang" or "framework" to search query

~~~
fao_
C is by far the worst...

Side Note: In DDG Lua doesn't need 'lang', you can type in a function name and
it'll give you documentation in the 'instant answers' thing.

------
sdogruyol
If you're a web dev and want to build an API be sure to check out Kemal:
[http://serdardogruyol.com/kemal/](http://serdardogruyol.com/kemal/)

~~~
tremendo
a Sinatra for Crystal. Wonderful. Now if there is a Sequel equivalent… I'll be
sold.

------
13of40
> Note that the above “if” starts with “if instance variables types remain the
> same”. But how can we know that? The problem is that the compiler determines
> their

> type by traversing the program, instantiating methods, and checking what
> gets assigned to them. So we can’t really reuse the cache because we can’t
> know the final

> types until we type the whole program! It’s a chicken and egg problem."

Maybe I'm oversimplifying it, but suppose you compiled a statement like...

a++

...into something like...

if a is an integer (which would presumably be something fast like "CMP
[RAX],123; JNZ NotAnInteger") do "INC [RAX+8]", otherwise do more expensive
stuff to look up the actual type and a function to use as a ++ operator?

As long as the programmer sticks to the same type, the compiled expression
runs fast, and if they switch types midstream, it still runs, albeit with a
performance hit.

~~~
tekacs
You might be interested in deoptimisation: :)

[http://chrisseaton.com/rubytruffle/deoptimizing/](http://chrisseaton.com/rubytruffle/deoptimizing/)

This would have the effect that you describe (actually even faster than what
you're proposing, by essentially trapping on all changes to the target to know
ahead of time that deoptimisation has to occur), but it's not the world's most
trivial feature to implement.

------
dutchbrit
Taken from Github on the "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.

~~~
davexunit
>We love Ruby's efficiency for writing code.

Ruby's syntax is one of the worst parts of Ruby. [0]

>We love C's efficiency for running code.

Many other languages have efficient native code compilers, too. I don't know
why people assume this is only a C thing.

>We want the best of both worlds.

>We want the compiler to understand what we mean without having to specify
types everywhere.

This is good. I much prefer dynamic languages to static ones. Though I don't
know if Crystal supports the best parts of dynamic languages like runtime
program modification AKA live coding.

>We want full OOP.

Single paradigm languages feel very restrictive to me. I like languages that
support many paradigms because different parts of programs call for different
programming techniques. OOP in particular is a paradigm that I feel forced to
use more often than I feel it's the right technique for the task at hand.

[0] [http://programmingisterrible.com/post/42432568185/how-to-
par...](http://programmingisterrible.com/post/42432568185/how-to-parse-ruby)

~~~
arnvald
> Many other languages have efficient native code compilers, too. I don't know
> why people assume this is only a C thing.

I think it's just become very common to show C as the reference to show how
fast are other programming languages, and everyone keeps it this way.

> Ruby's syntax is one of the worst parts of Ruby. [0]

For people who write the language, yes, it's incredibly hard to parse (and
that blog post doesn't mention the new ambiguous things like keywords vs.
hashes)

Yet, for people who use Ruby, it's very convenient and easy to read.

~~~
rayiner
People used to find Perl convenient and easy to read too.

> Similarly, distinguishing puts ([1]).map {|x| x+1} from puts([1]).map {|x|
> x+1} is handled by setting flags after skipping whitespace, and later
> checking these flags to emit an LPAREN or an LPAREN_ARG token. As well as
> semantic whitespace, flags are used for blocks, class definitions and method
> names too.

What the actual fuck.

~~~
matthewmacleod
_What the actual fuck._

That's not particularly unusual, is it?

~~~
rayiner
Significant whitespace, except to separate tokens, is unusual. Significant
whitespace that is used for something other than delineating blocks is
extremely unusual.

------
thomasfl
If I had to optimize parts of a ruby project, I think it would be much better
to port the code to crystal than C or Go.

------
69_years_and
Only just had a quick peep and play and I like it - looking forward to using
Crystal more often on a tooling level.

Nice work to date...

