[andrewzah]

What semantics is crystal lacking? Obviously it's not a 1:1 replacement as the ecosystem is different, gem management (shards) is different, etc. Crystal also has union types and concurrency.

For people who want a syntax like ruby + performance/concurrency, but are willing to deal with a different ecosystem and having to do more stuff by hand, Crystal is a nice choice.

[chrisseaton]

Local variables, method calls, basics like that are basically entirely different. Take the Ruby specification test suite and try to run it on Crystal, even with adding typing and other minor changes, and see how far you get.

(Ruby also has full concurrency, by the way.)

[sethrin]

Your criticism does not seem rigorously considered. Toy programs can often simply be renamed from .rb to .cr and be compiled and run as Crystal code. Crystal is not, however, trying to be a drop-in replacement: among other things, an enforced type system is not a minor change. Compilation is not a minor change to a language either. It's valid to say that you don't like the tradeoffs (and of course ideally you would have a full understanding of what those are), but it's incorrect to suggest that these languages are not extremely similar.

[chrisseaton]

My argument is - if you swapped out the syntax of Crystal to not look like Ruby, would anyone think 'this is like Ruby'. I don't think so. Super fundamental parts of the language semantics, like method dispatch rules, are completely different between Ruby and Crystal.

> Your criticism does not seem rigorously considered.

I'm a major contributor to the Ruby specifcation, and I've got a decade of full-time experience in writing about and implementing Ruby and its semantics, so I'm not just doing a drive-by comment.

[viraptor]

It still has a very similar feel to Ruby. A lot of the standard library is a very close match to Ruby. And the metaprogramming bits are possible to simulate with macros.

I find this discussion often go into the weird "it's static Ruby" / "not almost nothing like Ruby" extremes. I'd go with looks - same, feel - very familiar, inner workings - you can find ways around differences.

[sethrin]

Suffice it to say that I don't think the details of message passing are what most people care about with Ruby. I can see how your experience would lead you to believe otherwise.

[eropple]

I strongly disagree. The message passing semantics are a pretty core part of why you can write pretty complex metaprogramming in Ruby and, without writing a lot of code, make a lot of stuff happen. And even somebody who "doesn't care" about that is critically indebted to it--because that's how Rails happens.

This is not always for the best, of course, but I reach for Ruby pretty consistently when I need to do that sort of thing--often in a dynamic programming context or where I'm binding a lot of state to present a straightforward DSL to an end user (which Sorbet helps with quite a lot, too). Sometimes, for practical reasons, I'll do that sort of work in TypeScript, but the result usually has a lot more sandpaper to it.

Crystal...just isn't that. At all. It's a fine language for what it is; it doesn't just offer anything that Ruby, TypeScript, Kotlin, and Rust don't, so I have no use for it. But it's definitely not Ruby and it doesn't even smell like Ruby.

[chrisseaton]

> because that's how Rails happens

Bingo.

[bb88]

Not sure why you're being downvoted there. But you've made a good point.

[andrewzah]

Crystal has local variables. I didn't mean to imply that ruby & crystal are 1:1 drop-in replacements, but there are a great many similarities. Enough for me as a ruby/rails dev to start on crystal projects with relatively little issue once I learned a bit about the standard library and the ecosystem.

Ruby's way of handling types is abhorrent compared to Crystal, though. Sorbet/RBS are unfortunate systems tacked on after people realized that type systems are actually really good and not really that verbose.

[dragonwriter]

> Crystal also has union types and concurrency.

Ruby has had concurrency forever, and as of 3.x also parallelism via Ractors.

[metadat]

You may be missing the point - Vanilla Ruby is relatively slow and expensive to scale.

That's why I use node.js *grin* /s