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
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.
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)
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.
My only hope is that the Crystal team is able to maintain the pace in 2020 and beyond.
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.
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.
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
YES!!!
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!)
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.