Mike Perham ported some of Sidekiq to Crystal and did brief writeup about it [0]. It'll be interesting to see if this thing really goes somewhere.

[0] http://www.mikeperham.com/2016/05/25/sidekiq-for-crystal/

I agree that compile to binary languages are better for distribution, and has always been a pain point with interpreted languages like Ruby. Ruby actually does this better with its ecosystem (RubyGems, Bundler) than a lot of other mainstream languages.

Just to nitpick, capturing STDOUT is not that hard in Ruby at all. Definitely not as easy as Stdio.capture, but Ruby gives you a variable called $stdout, which you can assign to local variable and treat it like a file. If you would rather not print messages out during the test, then you can just temporarily assign $stdout to nil.

> I agree that compile to binary languages are better for distribution

Personally I think the wide adoption of JVM, CLR, Python, Ruby,..., alongside the demise of languages like Delphi, helped fortify C and C++ place at begining of this century.

For many people, they became the only two languages they knew that were capable of producing binaries, unaware of other options.

Thankfully the tide is turning.

As for Ruby, I always felt the community could have learned from Dylan and implemented a proper AOT compiler, for a while RubyMotion seemed to be that one.

Now we have to bet on Crystal it seems.

> and implemented a proper AOT compiler

Ruby is fundamentally hard to AOT compile efficiently (that's part of the fun I have of trying to compile it...). Part of the challenge is that the moment you allow eval() you have to include a JIT anyway.

Even without it, something as basic as "require" (to load modules/include files) in the typical Ruby install has been overridden by bundler and/or Rubygems to dynamically alter what will get loaded, and e.g. a variety of patterns involve dynamically altering the load path based on directory content.

Something as "simple" as generating a staticaly linked binary out of a Ruby program involves solving the halting problem (e.g. your program could wait for user input to decide which file to load) or making decisions that makes your compiled binary act different to how the interpreter would.

Basically, to statically link Ruby you have pretty much two choices: Make a new language, like Crystal, or determine the minimum set of limitations / changes to Ruby semantics to make it viable to compile with the lowest amount of breakage. I'm trying for the latter, but who knows, something like Crystal might turn out to be the better option. It's certainly a simpler option.

A large part of the problem is that Ruby grew organically based on an interpreter rather than being designed with compilation in mind.

Yes, chrisseaton answered me about it the other day.

I was telling him that from my point of view, given the work done in languages as dynamic, meaning Lisp, Dylan, Smalltalk, that from my naive of view (I know Ruby only superficially) that could be applied to Ruby as well.

He also answered me along those lines, that idiomatic Ruby abuses more the dynamism than those languages.

Chris's work is fantastic - I hope I'll eventually get to the stage of doing the same amount of dirty tricks that he's been doing.

I think we can get there eventually with respect to AOT (and frankly Chris is likely to get there first - as much as I have a general aversion to the JVM, the infrastructure they are getting with Truffle/Graal and now Substrate is impressive), but to solve the issue properly will take a lot of heuristics, coupled with getting some kind of agreement on various minor semantic changes to indicate compile time/runtime split.

I also really badly at some point want to analyze a bunch of Ruby code - as in crawl all the Ruby on Github big - to look for things like use of eval(), redefinitions of core methods, weird code loading tricks etc. to get an indication of how these things are actually used. Delineating what people actually do would be a big step forward in figuring out what to do about it...

I suspect, but don't know for sure, that most of the disaster-scenarios we've thought up involving Ruby sees little enough usage outside of people going "look what insane thing I can do with Ruby" that for some it may be better to just break code and fix it.

Yep, JIT is way more viable (and being done) with Ruby.

JIT doesn't the solve the problems people want AOT for, though, including the require/load path issue I mentioned - you still end up having to ship your entire source tree / gem bundles. Which is part of my motivation for still plodding along with my AOT compiler when I have time (the other motivation is that I've learned more about Ruby trying to compile it than I ever would from just "normal usage")

I probably wasn't being clear about STDOUT on the ruby version. I just didn't do it in this particular project for the ruby version. I just tested that the flags didn't throw anything. I had tests on other production tools and yeah $stdout saving is nice.

Someone mentioned on reddit me about a CLI testing framework that perhaps does a more holistic job of testing STDOUT.

--> https://bitheap.org/cram/

it's written in python but it's not for python projects per se.

If you're a Ruby dev, it's worth your time checking out Crystal. As others have pointed out, it isn't a one-to-one replacement for Ruby, but if you enjoy the Ruby syntax and general way of approaching problems, Crystal is a handy tool.

I've been playing around with it for a a while, and really enjoy it.

That said, if you hate Ruby, keep walking...

There are some other options for this like Travelling Ruby

http://phusion.github.io/traveling-ruby/

Do you know if with Travelling Ruby is possible to create a windows executable with a GUI? I have been using the gem ocra + ruby tk for this.

From Ruby to ES6 or Elixir or Crystal or Golang or even maybe Rust? We need comparison of the target languages among themselves.

For example Crystal vs. Elixir.

Does Crystal have A framework like Phoenix or Rails?

Currently crystal doesn't have a large "standard" framework like Elixir or Ruby. There's Kemal, which is what most people use to create web applications in Crystal, however its quite small in scope compared to the previous two mentioned frameworks.

I'm sure large, opinionated frameworks will appear for Crystal but in the meanwhile Crystal and its community are just finding their feet and experimenting with what feels natural in Crystal and what doesn't. Once that's done, I'm sure that knowledge can be crystallized (heh) into a framework like Rails.

Won't have to learn GoLang or Elxir. Crystal on Rails!

I can't speak for GoLang, but Elixir isn't exactly a straight replacement for Ruby the way Crystal(more or less) is, it makes a lot different promises, and makes different assumptions. It looks familiar, but is paradigmatically quite different. If you are interested in FP, Elixir is a great way to get started.

Crystal seems quite nice though.

Crystal also is not Ruby 2.0. It just feels like Ruby the same way RubyMotion feels just like Ruby. But it is not Ruby per se. Nonetheless Crystal really looks cool!

Interesting, I've really only written like 10 lines of Crystal, so I guess I should take a closer look.

Elixir feels nothing like Ruby to me, except for some superficial similarities in the syntax.

Thanks! I'm so excited for Crystal to hit 1.0 and be production ready. May need to try it out now though. Thanks again

Does Crystal produce static binaries like Go does or do I have to mess with dynamic library hell?

It produces static binaries like Go does yes.

https://github.com/grosser/rubinjam is a super simple way to convert most Ruby gems into a universal binaries. Which is what this whole post was about :)

Is there any library for writing UI for desktop apps available?

There's libui bindings in a shard here: https://github.com/Fusion/libui.cr

Doesn't homebrew require git?

It does. But macOS comes with Git so Homebrew works without any dev setup.

For some reason, I zeroth thought the title meant “Porting MRI to Crystal”, which would have been truly awesome.

> Using rubygems to distribute ruby code is sometimes done but then sometimes it’s frowned upon

Wat? Rails?

The author means as a means to distribute programs and executables, not libraries.

Yeah, that's what I meant. :)

OK... Rails is an executable too. So is Rake... tons of executables are easily installed and managed with Rubygems.

I think of Rake/Rails as dev tools that are executables. In the post, I mentioned passenger because that was using Rubygems as a distribution mechanism and then they stopped doing that. I don't know if it's a hard / fast rule or even who would enforce that rule ... I was just mentioning that maybe it's an anti-pattern?

Development tools often are, but almost never exclusively using ruby gems and it's certainly not a universal practice. ANd of course non-dev tools can't be distributed this way.