I’ve seen little discussions about this topic around the forum (and in other channels, like in Gitter and Github issues), but I don’t think I’ve seen anything definitive. So far it’s seemed up to each individual, and that’s the right way to go. That said, I think there should be an explicit posture that the core team adopts.
So, to state the question/issue clearly:
Is Ruby compatibility a goal in the current and future development of Crystal?
Here are several possible positions that the core team could take:
- Ruby compatibility is a goal for Crystal development. As such, useful features in Ruby that are not yet in Crystal should be added (or heavily considered), and future syntax and naming for language and standard library features that exist in Ruby should heavily prefer the same syntax and naming as in Ruby.
The development of Crystal that I have seen does not seem to stem from this mindset, and it’s possible that no active member of our community holds exactly this position (though they may hold “stronger” Ruby compat positions similar to this one).
- Ruby compatibility should hold no weight in discussions of current and future language and standard library features in Crystal.
Similarly, this is a very strong position that seems unusual. Crystal’s development was heavily influenced by Ruby’s syntax, and the Ruby standard library is much more mature than Crystal’s, so there are many parts of it that could be useful in Crystal.
- Ruby compatibility does not need to be a primary goal in current and future Crystal development, but the practical element of reducing the difficulty for Ruby developers to start in Crystal (and port code) means that Ruby compatibility should be considered important when deciding on syntax and naming and when prioritizing additions to the standard library.
This is a position largely in favor of Ruby compatibility which is probably more widely-held than (1). I think this is close to the position that @jzakiya takes, and his consistency in that position is one of the reasons I felt this thread would be useful.
- Ruby compatibility is nice-to-have, and it should be considered as one among many reasons why a syntax/name/feature would be good, but it is not inherently important. It certainly should not be considered a primary factor or goal in Crystal development.
This is my position (as a non-Rubyist), which I think isn’t unusual. Note that the wording actively opposes Ruby compatibility as a goal for Crystal.
- The core team does not need an official position on Ruby compatibility. The community is welcome to discuss it, and individuals may choose whether they consider it important when proposing or considering language features and changes just like with any issue of personal preference in code.
This probably isn’t a position that any individual would take, but it seems reasonable to leave the option open for the core team to decide that an official position on this isn’t important.
There’s a lot of room for nuance here, so obviously the above positions are not exhaustive. However, I hope they can provide enough of a starting point to have a good discussion about what people think is the right way to approach Ruby compatibility in Crystal.
So, what do you think?