setup-ruby VS spec

Digression: Try head/debug versions of setup-ruby

It's no mystery why this keeps coming up, this is what the documentation of the setup-ruby action recommended until about 10 months ago and provided as examples, and what most of the examples you'd find on the internet would do.

ruby/setup-ruby is an action that you can use to install a particular Ruby programming language version. It allows you to cache Ruby gems based on your Gemfile.lock out of the box.

This post describes how to setup Ruby on Github Actions to cache Ruby gems for Rails project by using actions/cache and ruby/setup-ruby

ruby/setup-ruby - it's a solution to install a specific Ruby version and cache Ruby gems with bundler. Two features in one action.

You may define that Ruby is "CRuby" (MRI), the full-fledged implementation of the Ruby programming language specification (https://github.com/ruby/spec/).

Testing: Interestingly, most of the work was figuring out how to test the library reliably. Grizzly-rb is proudly tested against the ruby/spec repository using Mspec and Rubocop. Special thank you to the person recommending Rubocop in a previous post.  The tests cover Enumerable, Array, Enumerator and Enumerator::Lazy classes.

Ruby interpreter is a complex program, so it naturally has bugs, and Ruby interpreter developers are taking various countermeasures against them. For example, we write tests and check them in CI environment (This is the result of daily maintenance of the test environment, such as RubyCI, chkbuild, ruby/spec: The Ruby Spec Suite aka ruby/spec and machines).

I can't find the link to the official announcement, but many years ago they published an official ISO for Ruby, however at the time the ISO was based off of 1.8.7 syntax/semantics. Other than that, you have the RubySpec project which is a series of tests that validate how Ruby should work.

Java could have been a good example, but Sun had a rather strict validation process for calling something Java.

Furthermore, there are big difference in philosophy with C:

1. IB and UB are not considered normal parts of specifications, meaning there's way less opportunity for originality in the interpretation of the specifications

2. there tends to be an ur-implementation, and notable divergences from that tends to be interpreted as either a bug in the other implementation(s) or a lack of specification to be resolved between all implementations

Rust only has UB in unsafe (AFAIK), which greatly limits implementation flexibility in terms of observable behaviour; and the reference implementation would very much be considered the reference implementation, so I expect e.g. rust-gcc will be sticking close to the reference implementation and behavioural divergence will either be fixed to match, or will lead to more precise specification and both implementations converging.

Probably eventually with, if not a Sun-style validation suite, a Ruby-style Spec Suite (https://github.com/ruby/spec).

Ruby: https://github.com/ruby/spec Yes, it is not a word document, but it is a spec nonetheless. It is an authoritative source. TypeScript has nothing like this; no, unit tests aren't the same.

Opal is simply a Ruby to JavaScript compiler. While it may be someday possible to run Rails on it, as you can run Rails on JRuby, the primary focus of this project is to allow you to write frontend code in Ruby and possibly share some code between your frontend and backend. It's possible to compile entire Ruby libraries to JavaScript (with little changes needed due to some caveats). Opal supports a Ruby 3.0 level of features (regardless of your backend Ruby version), often surpassing MRuby in terms of compatibility. It is being actively tested for regressions against Ruby Spec and is self-hosting, ie. can compile itself (see: TryRuby).