You seem to make the assumption that crystal's purpose is to be for ruby developers, and as soon as it deviates from ruby, you've switched gears and might as well use Java or C.
I don't think that's the case. Crystal takes its syntax from ruby because it's easy to write, easy to read, and familiar, it doesn't have to be the same as ruby in semantics. In fact that's impossible because it's statically typed (which I personally prefer to ruby).
If you're going to resort to Java or c for speed, why not use crystal? Crystal beats Java and c on expressivity of type system, expressivity of code (less boilerplate) and performance per unit effort (at least on common tasks). So the question is why Java or c? They both certainly have larger and more mature ecosystems, and if you have compute-heavy workloads they'll probably win out on performance, but why do you instantly make the leap from crystal != ruby to "might as well use java/c"?
Actually, I'll expand on that and say that crystal isn't "static typing for rubyists", its more like "the best bits of ruby applied to static typing". There's a big difference in that the bits of ruby that crystal chooses to take may not be the parts that are most familiar to rubyists. That it is so similar to ruby is a huge complement to ruby in that there was so much that the team wanted to take.
The hardest part of learning crystal for rubyists is unlearning their ruby habits when working on crystal. Once you're over that hill you might find crystal a wonderful language in its own right.
I agree and that's my original point, in order to use Crystal I need to unlearn things. I guess I'm lazy enough that the performance benefit isn't a big enough benefit for me to trade off the flexibility of Ruby.
Nothing against Crystal, I think it's great but it would almost have been better coming to Crystal from something other than Ruby.
You replied downstream of me, but: being non-Ruby in terms of semantics is a pretty big minus for me, to be honest. If it looks like Ruby, I expect it to act like Ruby and the cognitive load of dealing with such similar syntax without having similar semantics is more than I want to deal with without getting a big win. And Crystal is not a big win to me; my choices aren't Java or C, my choices are Kotlin-or-Scala, C#, and C++ rather than C. And the next step for me would be Rust, which I think does a good job of taking lessons from Ruby rather than imitating it.
It's not a bad language. (I would rather see it than Go in just about any situation.) But I don't see a positive value prop, for me, as I don't particularly value syntax (I can write anything; even if syntax was a big pain point for me, this is why I use IntelliJ and ReSharper/ReSharper C++) and I do value ecosystem and tooling. Maybe if it was JVM-targeted or CLR-targeted, to piggyback off those ecosystems, but even then the value prop is muddy.
I don't think that's the case. Crystal takes its syntax from ruby because it's easy to write, easy to read, and familiar, it doesn't have to be the same as ruby in semantics. In fact that's impossible because it's statically typed (which I personally prefer to ruby).
If you're going to resort to Java or c for speed, why not use crystal? Crystal beats Java and c on expressivity of type system, expressivity of code (less boilerplate) and performance per unit effort (at least on common tasks). So the question is why Java or c? They both certainly have larger and more mature ecosystems, and if you have compute-heavy workloads they'll probably win out on performance, but why do you instantly make the leap from crystal != ruby to "might as well use java/c"?