Is Ruby Compatibility A Language Goal?

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:

  1. 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).

  1. 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.

  1. 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.

  1. 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.

  1. 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?

2 Likes

FWIW it’s called out in the readme GitHub - crystal-lang/crystal: The Crystal Programming Language

  • Have a syntax similar to Ruby (but compatibility with it is not a goal)
5 Likes

As @Blacksmoke16 said, Ruby compatibility was a goal for like 3 months, then it became clear to us that that was going to be impossible. We also don’t envision that this will change in the future, and divergence from Ruby will be bigger and bigger as the language continues to evolve.

However, Crystal should result familiar to Ruby programmers, but that’s just a side-effect os us liking Ruby and wanting to have something that feels like Ruby.

9 Likes

What drew me to learning and using Crystal, about one year ago now, is that I was looking for a language that compiled to native machine code, be about as powerful as most of the “big” langauges, something like C++ but less fussy on memory management and without the icky syntax, something that nicely absorbed newer features of current languages e.g. lambdas, string interpolation, help with unit testing, lists and arrays “built in” or at least felt that way, and I could go on and on. Rust was interesting, but not sure I wanted to go with it just yet. Walter Bright’s D Language was great, but in some ways just didn’t seem like the final word, still clinging to C++ - like notions, not reaching as far as it could, falling short in some way I can’t articulate, though I still use it. Python is also a good start, but the semantic indentation becomes trouble with large systems and with lots of cut-paste refactoring and experimenting. Julia is a great replacement for Matlab, IDL, R and Python+Numpy, but didn’t seem right for small everyday utilities, or non-numerical non-image-processing work.

I had used Ruby for small projects in the past (none web related, no Rails) and liked the elegance, doing useful things in a few lines without any mystical hoo-hah, the use of blocks, unfamiliar at first but I soon saw the usefulness, and while I tended to use OO only lightly, Ruby was very extremely OO but oddly felt free of OO constraints, doing object oriented things in a very slick, easy, productive way. Matz goes on my list of language design geniuses!

Crystal came up in a search last year, and I tried it, finding that finally, just for once, someone designed a compiling language and system where all the “right” decisions were made. If it had gone for a more Python syntax, or closely followed a widely disliked language like PHP or mushed together several languages the way IDL mushes together BASIC, C, Fortran and apparently Martian, I might have passed it by.

From my point of view on Ruby and Crystal - it’s a good selling point for those who like Ruby, find Ruby effective and pleasant to work with, but exact adherence to Ruby is not necessary. We want the genius of Matz, and to use the tips & tricks we’ve learned, but I don’t care if some small details are different. I expect differences, just because interpreting and compiling to native machine are different things.

For those who need to migrate existing code from Ruby, “plug and play” ability to compile .rb files with no fuss or minimal fuss is a big advantage. I haven’t been in that situation myself, yet. I know there are those who find that a big selling point. Once the switch is made, special features in Crystal but not Ruby could be made use of. Close adherence to Ruby helps with the transition, but long term probably could be dropped.

I can imagine years in the future everyone will hate any baggage dragged along for the sake of compatibility, like the way modern C++17 still has a lot of C in it, making it a troublesome language.

Bottom line: Ruby compatibility is important for some Crystal users in the short term, Ruby resemblance is an attractant to others (for example me), but may not be a wise goal for the very long term.

4 Likes