[rurounijones]

Maybe but depending on what you are doing they are minor considerations.

I am porting a relatively simple ruby app to Crystal to see how it is and most of it is copy/paste and then some fixing and adding type definitions where needed. The only issues I have had are where I am using a rubygem that doesn't have a crystal counterpart.

For example a pretty simple Gem that connects to a socket and parses incoming data was exceedingly easy to port, including tests.

* https://gitlab.com/overlord-bot/tacview-ruby-client

* https://gitlab.com/overlord-bot/tacview-crystal-client

For a more specific example these two files are almost identical:

* https://gitlab.com/overlord-bot/tacview-ruby-client/blob/mas...

* https://gitlab.com/overlord-bot/tacview-crystal-client/blob/...

The only thing not done was CRC hash calculating for a password because there was no crystal shard for it and it was low priority so I didn't write one.

[chrisseaton]

If its so simple to port Ruby code to Crystal, then how come nobody has gotten around to porting Rails to Crystal yet?

[rurounijones]

Please re-read what I said. I never claimed it was easy to port in every situation.

I merely pointed out that "depending on what you are doing they (semantic differences) are minor considerations." and then gave an example where that was the case with a simple application I was working.

If you want a more complicted library that was ported from Ruby to Crystal then you can also look at Sidekiq ( https://www.mikeperham.com/2016/05/25/sidekiq-for-crystal/ )

[chrisseaton]

But when this doesn't apply to even basic parts of the Ruby ecosystem, like Active Support, these 'minor differences in some cases' are fundamental showstoppers for a company like Shopify, which was the context.

The original comment said 'without needing to really think in a whole different programming experience'. Ruby without #send and #eval is a very much a whole different programming experience for a company like Shopify.