docs: adds RATIONALE.md with section on why TinyGo

[codefromthecrypt]

What type of PR is this?

/kind documentation

What this PR does / why we need it:

This reverse documents a decision we made about TinyGo.

Which issue(s) this PR fixes:

NONE

Special notes for your reviewer:

documents the most important part of #6

Does this PR introduce a user-facing change?

NONE

What are the benchmark results of this change?

N/A

[codefromthecrypt]

ps you may wonder why have RATIONALE.md vs a separate website etc. For a fast moving project, it is more coherent to have changes self-contained. For example, a decision and its rationale in the same commit ideally. When things settle down, we can easily harvest these docs to a separate web page, if it is required to host them externally. Meanwhile, it encourages documentation of decisions otherwise left to PR comments because the follow-up overhead penalty adds friction and work.

[ffromani]

/cc

[sanposhiho]

Great, they are very worthwhile to know.

/lgtm
/assign @kerthcet

[codefromthecrypt]

once this is in, I'll rebase #25 and add the rationale for nottinygc as that is also not intuitive unless you had our experiences.

[kerthcet]

part of #14

[kerthcet]

Can't quite understand the difference of subprocess model with above the go runtime and memory needs to be recreated per request, can you explain more about this @codefromthecrypt thanks.

[codefromthecrypt]

so the webassembly analogy for a subprocess model (fork a normal OS binary), is instantiating a new module per request.

First wazero needs to create an instance of the wasm binary and there is overhead for that including setting up functions and allocating a new slice of memory (minimally 128KB for tinygo).

Then, what tinygo compiled the go runtime as needs to happen (the part before main is called). Also anything after main returns needs to happen. So all that overhead around the actual function is what the subprocess model implies.

To illustrate this, I have a simple cat program that writes a small file to stdout. The part highlighted in grey box is the actual critical code, though some functions to the left could be argued as critical (lazy initialization happening of filesystem stuff). Everything else is setup/teardown overhead of a go executable compiled to wasm/wasi.

[kerthcet]

/lgtm
/approve
/label tide/merge-method-squash
Thanks @codefromthecrypt

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: codefromthecrypt, kerthcet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [kerthcet]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment