3 ms·

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

by pkd 10y ago

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.

pjmlp 10y ago
> 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.
- vidarh 10y ago
  > 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.
  - ehsanu1 10y ago
    Yep, JIT is way more viable (and being done) with Ruby.
    - vidarh 10y ago
      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")
  - pjmlp 10y ago
    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.
    - vidarh 10y ago
      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.
squar1sm 10y ago
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/ https://bitheap.org/cram/ it's written in python but it's not for python projects per se.

by pkd 10y ago

pjmlp 10y ago

> 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.

vidarh 10y ago
> 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.
- ehsanu1 10y ago
  Yep, JIT is way more viable (and being done) with Ruby.
  - vidarh 10y ago
    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")
- pjmlp 10y ago
  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.
  - vidarh 10y ago
    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.

squar1sm 10y ago

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/ https://bitheap.org/cram/ it's written in python but it's not for python projects per se.