opal-rails VS spec

Opal itself aims just at creating a Ruby runtime and a couple of life improvements, but there exist a couple of helper gems, for instance Opal-Browser (for an idiomatic API to interact with DOM and other browser APIs), Opal-Rails (for integrating with a Sprockets pipeline of Rails), Opal-RSpec (to test your frontend application). There exist a number of libraries and bindings to JS libraries for Opal.

For Rails integration we provide opal-rails, a Gem, that after inclusion will transparently handle .rb files in your JavaScript asset directory (via Sprockets). To interface with a web browser, you would also need to use opal-browser. As an alternative you can use Hyperstack, which deeply integrates React, Rails and Opal.

Opal itself is a low-level thing, not depending on Rails whatsoever. We provide an official Gem for integration with Rails that integrates everything nicely and allows you to have .rb files in your JavaScript assets directory. Unlike Rails, Opal is not opinionated, to interface with web browser APIs properly you need to either use a library that wraps DOM directly, use a similar one that wraps jQuery or use Hyperstack, a fully-fledged Rails-integrated framework based on React that also allows you to share your models between frontend and backend. It's also possible to not use any of those and interface JavaScript APIs directly using an API that looks like this: $$[:document][:location].replace("https://opalrb.com/") or simply embed JavaScript with a backtick notation: `document.location.replace(#{@url})`.

There's a full blown test suite for Ruby which the various implementations use: https://github.com/ruby/spec

At one point there was an open source project to formally specify Ruby, but I don’t know if it’s still alive: https://github.com/ruby/spec

Hmm, it seems to be alive, but based more on behavior than syntax.

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.