Crystal in 2020

First of all, happy new year everyone “Crystallers”!

2019 was a great year, and we all wish the best for the language and the community in the following year!

What do you like about 2019 and what’s your hopes for the next year?

  • The most important parts that were improved
  • The biggest lacks that remains to be done

Note: It is a long time we didn’t have a little survey, this would be a perfect time for this :smiley:


What do you like about 2019

We made some headway on Windows support.

and what’s your hopes for the next year?

Full Windows support.

  • The most important parts that were improved

Windows support

  • The biggest lacks that remains to be done

Windows support



Interfaces maybe? I think this is one of the most important feature of every static typed lang. Yeah I know Crystal isn’t full static typed but it could be better to have interfaces


What headway was made?

A love2d like game framework but with Crystal on Windows. Bind imgui (or a pure c gui library) and SDL, and you’ve got a beast of a framework to utilize. However, particle systems, and other complex functionality might be a PITA, and probably not enough use cases to justify dev time.

I love Godot so much, it’s such a joy to use (especially the AnimationPlayer), but if I could code with Crystal on the client and target Windows and Linux… it would be like something from out of this world. Not only for me, but people who love Ruby/Crystal’s syntax and want to make games. Not only games, but performant desktop apps as well.

Lua is amazing and love2d is already a powerhouse, but I swear, Crystal’s OOP and syntax is a perfect fit for game programming. Unless there are performance issues I’m not aware of, I think it could be huge.

With all this said, take my post with a grain of salt, I have no idea what I’m talking about anymore.


Crystal already has interfaces, they’re just called module. Or do you mean something else?

1 Like

I meant real interface like we have on java or typescript :D

Something like

interface IWrite
write(str : String)

  • Reduce extra dependencies in the standard library
  • Feature/Syntax enhancements, such as support for Ruby-like pattern matching
  • The entire community is working together to promote the development of a Web/ORM framework, having a killer framework for the internet is great for language promotion. Just like Elixir and Phonenix/Ecto
  • Better build tools to support custom tasks
  • Better multi-threaded parallel scheduling (intelligent allocation of fibers based on thread load)
  • A REPL

How’s that any different?

module Write
  abstract def write(str : String)

intellij ide support.


Main thing I’d like to see is the backlog getting cleaned up. There’s many PRs that are started and then just left dead. I’ll see 2 core member approvals, but so much time passes that things become out of date, or concepts and goals change. I think revisiting some of the oldest issues and seeing some “spring cleaning” as far as prioritizing, labeling, closing, or merging those would be great.

To help the community with these, having someone in charge of housekeeping might be nice. A simple tag added to PRs that says “this concept is good, just needs to be finished”. Then just closing out PRs that aren’t viable.

(and windows support, of course).


My only hope is that the Crystal team is able to maintain the pace in 2020 and beyond. :star_struck:

I understand the appeal of native windows (desktop) support, but I’m also pretty happy being able to use Crystal from Windows 10 WSL (windows subsystem linux). On Debian and using the apt repo it takes literally about 30 seconds to install and start using.

Happy New Year

Most liked in the current: Awesome standard library, incredibly helpful community.
future wishes: Simple gui toolkit, cross platform if at all possible.


Wanted in 2020 for me: require type annotations in all method signatures, introduce an import system, allow the compiler to compile single files on their own (modular compilation), remove enum autocasting, let case be exhaustive, remove Symbol type, remove splats and double splats (or make them use Array behind the scene, not Tuple), remove NamedTuple, introduce interfaces, remove macro run, macro finished, macro hooks and macro type introspection.


Can you elaborate a bit on import system? Is it about explicit imports or something it this vein? I had a thought that maybe explicit imports would make Crystal more… hm… usable. Sure, we have private types so situation with module/class names is a bit better than in Ruby, but not by much.


1 Like

Interesting… I’ll just write a few things that come to mind, feel free to reply or not

introduce an import system

This good I think, very much wanted on my side!

allow the compiler to compile single files on their own (modular compilation)

This is going to be great, but maybe not at file level… I think it would be better at shard-level or “package” level (whatever that is) similar to golang

let case be exhaustive
remove Symbol type


require type annotations in all method signature

Yes? would be interesting to see how that plays out!

remove splats and double splats (or make them use Array behind the scene, not Tuple)

Oh god… please no (removal or using Array instead) This is likely to generate a lot of discussion if you really intend to to that

remove NamedTuple

I’d be interested to know why…

remove macro run, macro finished, macro hooks and macro type introspection

These macro crazyness are such a wonderful things in Crystal, this would be pretty bad to remove them I think…
I agree there’s a lot of corner cases and things that are hard to work with, but I believe we could improve the implementation of macros in general and maybe restrict this crazyness to be used in very specific stages of the compilation so that is enables safer/predictable/modular-compilation-compatible crazy modifications of the types… (discussion to be continued I guess!)


What I want for 2020? Progress in the structured concurrency github issue, and with that, the deprecation of the spawn keyword.

1 Like

I feel like this would remove a major feature of crystal, especially when generics are involved.
If I want to combine two Enumerables I don’t care if that’s an Array of Strings and a Set of Strings or Array of Int32s and an Array of Int32s. The compiler deals with that complexity.
Macros and type inspection are also super useful.

In fact all of the things we’ve built with crystal would not work without those two features and would drag crystal a lot closer to being a slightly more pretty version of C++, way less productive than Ruby which we’ve moved from.

In my opinion the current type system and compile time introspection hits the perfect balance and is what makes the language amazing. Please don’t break this.


Maybe it could it be like that?

def combine(a : Enumerable(A), b : Enumerable(B)) : Array({A, B}) forall A, B