Wouldn't Crystal fit the bill for a fast compiled language explicitly designed to emulate Ruby's syntax? (I don't have any significant Ruby or Crystal experience, so if there are reasons why that doesn't fit the bill, I'm sorry)

So I do have a lot of Ruby experience, and I have used Crystal, and I've found that Crystal being Ruby-ish in syntax doesn't help with the fact that it isn't Ruby and doesn't work like Ruby. Nor does Rust, of course, though I do appreciate how Rust has liberally taken after Ruby in a lot of other ways. But I find Crystal mostly frustrating in many ways related to how it looks and presents itself. It wants to look like Ruby and it wants to court Ruby developers--by not being Ruby, but also not providing enough reason to use it over other languages.

There are tons of uses for non-Ruby languages. These days I'm primarily in TypeScript and Kotlin, even though I really, really like Ruby; as-is it doesn't scale, from the perspective of somebody who likes manageable code, as well as I'd like it to. But when I want a non-Ruby language, I am not tied to Ruby syntax (and I kind of think that Ruby's syntax works almost exclusively for Ruby? I think a lot of the expressivity of the Ruby language loses something when you don't have its dynamic approach to the world) in a way that makes Crystal, with its lack of libraries or maturity, not an appealing choice of tooling.

(I also feel similarly about Elixir, though in Elixir's case there are also some interesting things around BEAM that I might like to leverage. And I think that a typed Elixir would get my attention right quick.)

> And I think that a typed Elixir would get my attention right quick.

Elixir _is_ statically typed, it just uses strong type inference so you rarely have to explicitly type things out.

A key difference between Crystal and Elixir is that Crystal tries to replicate ruby syntax in a more performant language, whereas Elixir tries to apply the sensibilities of Ruby and the Ruby community to the Erlang VM.

I was using "typed" as shorthand for "statically typed", but Elixir is not statically typed. Typespecs aren't static typing and IMO they get messy when you want to do more than specify primitives.

https://elixir-lang.org/getting-started/typespecs-and-behavi...

Dialyzer is indeed a pain in the ass, but what is not a pain in the ass is vscode's elixir_ls plugin which incrementally dialyzes and gently nudges you into making static type declarations (your code shows up uglier when you don't do it).

Life changing. It's stopped me from pushing runtime errors probably about 20 times now, in the last few weeks that i've been using it. At this point I'd say that it's strong enough to close 95% of the difference between static and dynamic typing.

Elixir's (maybe going to be merged into the standard library) property checking semantics (ExUnitProperty and StreamData) are quite amazing and super easy[0], and will catch whole classes of things that your compiler won't so I would strongly suggest checking out Elixir now.

[0] today I implemented in an hour a property check that makes me confident that a mathematical algorithm that I implemented for a fuzzer is ok (my first attempt was wrong), and then a property check that demonstrated that that algorithm applied to a stateful set of events doesn't violate critical invariants.

Also, you will almost certainly never get a statically typed Elixir, because it makes a lot of things like hot updates hard or inelegant. Sending interprocess/internode messages is something could be extremely intolerant to a static type system, because, in a way you're breaching the purity of the functional paradigm (it's the BEAM language's "one big lie"). Go struggles with this a lot in its channel semantic, and it's why there is a ton of boilerplate in gRPC (and almost no boiler plate in erlang RPC).

Also gently breaching the type system is incredibly useful in mock tests - for example, in my current project I do about 60 high-load end-to-end tests in parallel with clones of my central scheduling algorithm - this is possible because my test suite reaches into the main body, dynamically creates a new scheduler, and appends that information into an HTTP request, which is passed into a "plain old map" and intercepted only in test environment. This not only greatly accelerates the end-to-end tests (I run the full suite as a matter of course before each commit) but it also gives me confidence that my system will run under a load that is greater than I can manually trigger.

I use typespecs in both Elm and with Dialyzer in Elixir and I haven't found either to be cumbersome, even when using complex data types.

I used to do a lot of programming in C# and Java, but I didn't miss static typing at all when I moved over to Ruby and Python. I'm sure others have differing opinions, but the absolutely last thing I worry about when selecting a language is whether or not it is statically typed.

I've only given Crystal a cursory look in the past and I think I'd enjoy working with it but can't speak to whether I'd feel as comfortable and productive as with Ruby (maybe I would). But what I do know is that you would not have the vast amount of Ruby gems available to your project, so if you feel the need for those as I often do then you might find it a bit more slow-going.

For me, Elixir fits the bill as a Ruby replacement better than Crystal does. Elixir is more mature and its community and tools are similar to Ruby, making the upgrade path easier, I think. At least that was the case for me after trying both. I also have come to love the functional aspect of Elixir over Crystal's (and Ruby's) focus on OOP.

I think we've arrived at that future. With languages like Crystal, Rust, Groovy, and Elixir, you can get some of the same powers that Ruby bestows upon you in other environments like a statically compiled binary, the JVM, or the Erlang runtime (with it's lovely OTP framework). I even see JavaScript taking on some Ruby-like characteristics these days.

Those languages each target one of those platforms only, i.e. Crystal and Rust for a statically compiled binary, Apache Groovy for the JVM, and Elixir for the Erlang runtime.

Why not use a language that targets many platforms? E.g. Kotlin targets the JVM, Android, and Javascript, as well as is natively compiled. Now that's the real future. Better than using, say Groovy, to target the JVM, then rewriting it all when you want it to run on Android.

Agreed. I feel that ES6 is very ruby-like with the functional programming parts. I'm also very happy about Groovy, Elixir, and other languages that are Ruby-inspired.

Check out Crystal - Its statically typed, compiled, and a near one to one implementation of Ruby. https://crystal-lang.org

> a near one to one implementation of Ruby

This isn't the case at all. It has completely different semantics (for good reasons).

I do not agree that it "has completely different semantics". It has far more in common than not. Its close enough that I, as a long time Ruby developer, had no issues being productive with it in a very short amount of time. The syntax and API are similar enough that most Rubyists are going to be very happy and comfortable. Then when they see the benchmarks they will be even happier!

It also has different semantics for bad reasons. For example, Ruby’s if ... then ... else (single-line) has been deliberately removed because the devs have a mild preference against it. For someone like me who’s been writing that since BASIC in 1981 or so, that’s a surprisingly big PITA.

I like Crystal, but there are a few too many needless gotchas for it to be comfortable.

Is it backwards compatible with Ruby?

No. And it varies wildly - some Ruby files may run with just a couple characters (or even none) being different, and other may require a total rewrite.

To jump onto the other reply. No, it's not and while Crystal has syntax similar to Ruby, it is different enough that you cannot approach it like Ruby.

It looks like a duck, but it does not quack like a duck. This is not a diss. Crystal is good.

No but the syntax is almost identical which makes it reality easy to pick up for small use cases, at least last time I looked at it

*really

I read about Ruby, indeed it's quite elegant but if it's "fast enough" for you then any language is fast enough for you.. /S