spec VS Protobuf

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

protobuf: go get -u google.golang.org/protobuf/proto

It's because they changed the versioning format: https://github.com/protocolbuffers/protobuf/releases?page=5

But I suppose old version still receive bugfixes.

For at least 4 years protobuf has had decent support for self-describing messages (very similar to avro) as well as reflection

https://github.com/protocolbuffers/protobuf/blob/main/src/go...

Xgooglers trying to make do on the cheap will just create a Union of all their messages and include the message def in a self-describing message pattern. Super-sensitive network I/O can elide the message def (empty buffer) and any for RecordIO clone well file compression takes care of the definition.

Definitely useful to be able to dig out old defs but protobuf maintainers have surprisingly added useful features so you don’t have to.

Bonus points tho for extracting the protobuf defs that e.g. Apple bakes into their binaries.

gRPC Gateway is a protoc plugin that reads gRPC service definitions and generates a reverse proxy server that translates a RESTful JSON API into gRPC.

To use more recent versions of protoc in future applications, you can download them from the Protobuf repository.

Use the Protobuf CLI protoc and the plugin protoc-gen-tonic.

> didn’t find any standard for separating protobuf messages

The fact that protobufs are not self-delimiting is an endless source of frustration, but I know of 2 standards:

- SerializeDelimited* is part of the protobuf library: https://github.com/protocolbuffers/protobuf/blob/main/src/go...

- Riegeli is "a file format for storing a sequence of string records, typically serialized protocol buffers. It supports dense compression, fast decoding, seeking, detection and optional skipping of data corruption, filtering of proto message fields for even faster decoding, and parallel encoding": https://github.com/google/riegeli

It looks like it is in fact universal. Just glancing at the code here, it looks like the tool searches any arbitrary file for bytes that look like encoded protobuf descriptors, specifically looking for bytes that are plausibly the beginning of a FileDescriptorProto message defined here:

https://github.com/protocolbuffers/protobuf/blob/main/src/go...

This takes advantage of the fact that such descriptors are commonly compiled into programs that use protobuf. The descriptors are usually embedded as constant byte arrays. That said, not all protobuf implementations embed the descriptors and those that do often have an option to inhibit such embedding (at the expense of losing some dynamic introspection features).