Hacker News Reader

Comment by em77 | Hacker News Reader

I'm getting the impression of a running pattern of argument when talking about Crystal:

Crystalist: "Crystal is very Ruby-inspired. Welcome Ruby devs! What makes Crystal great is it's as fast as alternatives to Ruby, without sacrificing Ruby syntax and functionality! Port over your Ruby code! Crystal is Ruby on steroids!"

Rubyist: "Why does Crystal diverge from Ruby here, here, and here unnecessarily if the goal is to be similar to Ruby and allow porting more easily?"

Crystalist: "Crystal is not Ruby. Crystal has no goal of being similar to Ruby. Any similarity to other languages is purely coincidental. What's Ruby?"

View on HN

Firstly I'd like to mention that our messaging probably isn't consistent because it doesn't come from only one person. Crystal is a community and we all say slightly different things.

The message we want to get across about the Crystal is that it is very Ruby-inspired, and that Ruby devs will feel at home. Crystal is often compared to Rust and Go, and the level of abstraction you will see when writing Crystal code will feel much more at home compared to Go and especially Rust. That being said, Crystal isn't Ruby, and you'll have more success writing a project from scratch for Crystal than attempting to port any >10k LOC codebase. Crystal isn't designed to make porting Ruby easy, and it hasn't been for a while. Crystal's goal is to make you as a Ruby developer feel at home, not your code. A lot of people have ported codebases from Ruby and talked about it, but you probably see only the successes, not the failures.

In short, we want you to use Crystal not because it's faster and easy to port to, but because it's simply a better, more robust, modern language.

Yes, it feels a bit like a bait and switch to me. I can understand that - I've been tempted to go down the same route myself... But the messaging around it is all over the place.

On one hand, when they explicitly state that the goal is not for Crystal to be as close to Ruby as possible, that makes me more sympathetic.

At the same time it also makes me less likely to use it anytime soon. Not out of ill will - it's an interesting project and I hope they do well - but hardly any of my Ruby code is CPU constrained, so I have little reason to switch for speed. Had they aimed as close as possible, I might have tried anyway, but every little extra difference makes it less worthwhile.

Of course that's very different for people that actually write code where speed is a major concern and that e.g. haven't been able to use Ruby for that reason.

> but hardly any of my Ruby code is CPU constrained,

All of the IO in crystal is async, so even if you're IO bound, crystal is probably a lot more efficient.

I don't know what you mean.

In Ruby, MRI multiplexes over async IO if you use sync IO primitives, and using async IO directly is not a problem.

In any case, most of my code wait on external events (clients, databases) so it's very rare for the Ruby part to be worth optimising. I spend a lot more time doing things like optimising database indexes and the like.

Of course there are plenty of areas where the balance there would be very different.

Reply on news.ycombinator.com